[tonyk_av 36]

2 hours ago, Arlleex said:

Профессоры обычно только и печатали книжки, не имея ни малейшего представления о реальном коде.

Прикольно. Это вы о профессоре Кнутте, создавшего TeX и Metafont? Ну-ну.

2 hours ago, Arlleex said:

Я вроде о ней даже не говорил.

Наверно, не в ту строчку глянули.

 

8 hours ago, juvf said:

8 hours ago, tonyk_av said:

128 байт- это не много.

а с какой цифры начинается много? лично для меня и 128 бит много. Нужно массив в 10 байт - выделяем 128. 👍 

А потом почему-то памяти для какого нибудь регистратора не хватает или канал передачи в 1 Gb не прокачивает.  

 

[amaora 22]

9 hours ago, juvf said:

а с какой цифры начинается много? лично для меня и 128 бит много. Нужно массив в 10 байт - выделяем 128. 👍 

При использовании DMA обычно выравнивать надо и кэш отключать, размер становится больше. Да и 10 байт я бы и без DMA вероятно заменил на 16.

 

3 hours ago, Arlleex said:

Посмотрел цитаты великого цитируемого (с моими скромными комментами)

Нормальные цитаты, вполне могу понять и представить контекст в котором это было уместно сказать.

[Obam 33]

Вирта не вспоминаете, а мэтр 1 янв с.г. умер.

[juvf 11]

В 17.04.2024 в 17:00, tonyk_av сказал:

Смотрите процент, которые составляют эти 128 байт от всего ОЗУ.

 

смотрю....

В 16.04.2024 в 23:55, Arlleex сказал:

static u8 RxPacketMemory[1024]; // статически выделенная память для создания "гибких" структур

12,5%.

Это во первых, во вторых - А сколько будет в ОЗУ этих ваших RxPacketMemory? один? два? или 700 по 1024 байт?. В третих -  дело не только в ОЗУ. Вот сейчас у меня задача регистрировать пакеты в флешь/фрам. Или я там сохраню мелких пакетов за год, или  жирных за час? В третих... ну поставите вы вместо какого нить МК мелким ОЗУ пушку, с 1 Gb ОЗУ.... напишите код... а в этой системе есть датчик на мелком PIC. И? Для PIC будете новый код писать? и т.д. и т.п.

 

В 17.04.2024 в 17:00, tonyk_av сказал:

Вот когда не будет хватать памяти, тогда и будете думать, что делать

Так вот этим и занимаемся.

[Arlleex 136]

15 часов назад, amaora сказал:

При использовании DMA обычно выравнивать надо и кэш отключать, размер становится больше.

Отключать то зачем? Скорее, просто следить за когерентностью данных и вовремя их флушить/инвалидировать.

Цитата

Нормальные цитаты, вполне могу понять и представить контекст в котором это было уместно сказать.

Я тоже могу представить контекст, в котором эти сентенции уместны. Но они точно не уместны при тезисном описании в википедиях и тем более не применимы в технических дискуссиях за свод нерушимых правил, преклоняясь перед авторитетом дяди в очках с задней обложки книжки.
 

5 часов назад, juvf сказал:

Это во первых, во вторых - А сколько будет в ОЗУ этих ваших RxPacketMemory?

На всякий случай, повторюсь🙂 Я цифру 1024 написал от балды, это лишь для примера было. На самом деле у меня отправляемые пакеты создаются по мере необходимости к отправке, т.е. на стеке. А вот под принимаемые пакеты как раз статически выделяется буфер-агрегатор (в виде Си-шного union) под самый длинный возможный пакет. Т.е. если максимально возможный принимаемый пакет будет, например, 1000 байт - будет создан буфер на 1000 байт или чуть больше для локальных требований к выравниванию и т.д.

В особых случаях, когда памяти почти нет (ОЗУ), а линия связи позволяет отправлять данные порционно - то можно так и делать. Например, тот же SLIP по UART-у можно не кодировать предварительно, а кодировать по мере отправки очередного символа. С тем же езернетом так не получится - внутри одного езернет-кадра будь добр подготовить все нужные данные сразу.

[juvf 11]

В 18.04.2024 в 10:50, Arlleex сказал:

На всякий случай, повторюсь🙂 Я цифру 1024 написал от балды, это лишь для примера было.

на всякий случай, я цифру 128 написал от балды, это лишь для примера было.

[Сергей Борщ 123]

2 часа назад, Arlleex сказал:

На самом деле у меня отправляемые пакеты создаются по мере необходимости к отправке, т.е. на стеке

Тут есть опасность. Если передача идет с использованием ПДП - вызвали функцию отправки, она зарядила ПДП и вернула управление. И пошли дальше по программе, либо выйдя из той функции, на стеке которой был отправляемый пакет (и место на стеке освобождено, ничего не мешает порушить оставшийся там не до конца отправленный пакет), либо продолжив исполнять функцию - но компилятор видит, что это место на стеке дальше в этой функции не используется и имеет полное право занять его чем-то другим.

[Arlleex 136]

1 час назад, Сергей Борщ сказал:

Тут есть опасность. Если передача идет с использованием ПДП...

Есть, конечно)) Но эта ошибка из разряда "вернуть адрес локальной переменной из функции" - т.е. бывалым разработчиком не допустится🙂

Операции с DMA либо блокирующие (костыль, не делаю так никогда), либо функция отправки пишет в буфер, из которого DMA спокойно будет отправлять, а из той функции можно смело выходить.

Я стремлюсь всегда разделять уровни кода, поэтому все очень просто становится читать и поддерживать. Вот так выглядит интерфейс чтения/записи в UART

#ifndef _UART_HPP_
#define _UART_HPP_


#include "macros.h"


namespace nsUART {
  void init();
  
  u32  readRxFIFO (u8 dst[], u32 len);
  s32  writeTxFIFO(u8 src[], u32 len);
}

#endif

И совершенно не важно, что передача и прием реализованы как кольцевой буфер с задействованным DMA как на прием, так и на передачу.

Задача (или цикл) парсера вызывает readRxFIFO() и разгребает входящий поток байтов: если нащупала что-то осмысленное - вызывает функцию разбора пакетов.

Если хотим отправить данные - вызываем соотв. функцию и передаем ей эти данные, она их кодирует, обрамляет как надо и вызывает writeTxFIFO().

[tonyk_av 36]

6 hours ago, juvf said:

ну поставите вы вместо какого нить МК мелким ОЗУ пушку, с 1 Gb ОЗУ

Во-первых, глубина архива должна быть прописана в ТЗ, поэтому необходимый объём памяти определяется на этапе выбора технического решения и элементной базы.

Во-вторых, можно ведь и внешнее ОЗУ на SPI поставить.

[juvf 11]

В 18.04.2024 в 14:30, tonyk_av сказал:

Во-первых, глубина архива должна быть прописана в ТЗ, поэтому необходимый объём памяти определяется на этапе выбора технического решения и элементной базы.

Во-вторых, можно ведь и внешнее ОЗУ на SPI поставить.

вы вообще о чем говорите? какое внешнее ОЗУ SPI? Есть железо собранное. Есть задача - написать ПО для этого железа. Выделяйте для 10 байт - массив в 128 байт. По другому не умеете - делайте как умеете.

[razrab83 19]

ps вообще не понятно, почему в разделе программирование предлагают решить вопрос заменой железа? Это же ПРОГРАМИРОВАНИЕ, а не проектирование. Кто-то разработал железку, кто-то закупил РЭК, кто-то собрал - Прошли годы.... попало это всё на стол программисту. За частую, железо разработано и собрано ещё до того, как программиста приняли на работу. Начал прогер ваять - столкнулся с проблемой по ПРОГРАММИРОВАНИЮ, не по ТЗ, не по выбору элементной базы, а по программированию. "Как создать тип данных для структуры с переменным размером?", приходит "советчик" и советует учит по мощнее процессор поставить или внешнее ОЗУ на SPI. 🥱

[dimka76 43]

On 4/18/2024 at 1:00 PM, razrab83 said:

 ещё до того, как программиста приняли на работу. 

И оказалось  чтобы реализовать все что в ТЗ не хватает памяти. Даже при самой супер-пупер оптимизации.

 

On 4/18/2024 at 1:00 PM, razrab83 said:

приходит "советчик" и советует учит по мощнее процессор поставить или внешнее ОЗУ на SPI. 🥱

Тут никто никого не учил, а всего лишь приводили абстрактные примеры для иллюстрации своих доводов.

[juvf 11]

В 18.04.2024 в 15:33, dimka76 сказал:

чтобы реализовать все что в ТЗ не хватает памяти.

памяти для ТЗ хватает. кому-то не хватает .... чего-то, поэтому кому-то приходится городить память 12.8 раз больше требуемой задачи.

[tonyk_av 36]

1 hour ago, juvf said:

Есть железо собранное. Есть задача - написать ПО для этого железа.

Прикольно. Сначала сделали "железо", а потом стали пытаться приспособить его к задаче.

1 hour ago, juvf said:

Выделяйте для 10 байт - массив в 128 байт.

Сами выделяйте, вам же надо, а не мне.

1 hour ago, juvf said:

по другому не умеете - делайте как умеете.

Конечно, я так не умею. Зато я умею сначала посчитать необходимую память, а уже потом подбирать решение по "железу". Обычно так лучше получается.

1 hour ago, juvf said:

Выделяйте для 10 байт - массив в 128 байт

Кстати, в проекте ПЛК почти  так и делаю, переопределив new-delete для работы с выделенным для этого буфером. Априори не известно, сколько программист создаст запросов по Modbus и I2C. Задался разумным числом и выбрал МК с подходящим объёмом ОЗУ.

[Arlleex 136]

21 минуту назад, tonyk_av сказал:

Прикольно. Сначала сделали "железо", а потом стали пытаться приспособить его к задаче.

Да. Так делают, например, топовые гиганты типа интел/амд/нвидиа.

И да, я не видел ни одной фирмы, где прям по серьезке садились бы считать байты ОЗУ, которые потребуются для задачи, ибо хотя бы найти челвоека, который это умеет и потом будет в случае чего отвечать - та еще задача.

Обычно смотрят по верхушкам - устраивает ли МК/проц по интерфейсам и их скоростям, режимам и т.д. Можно ли его купить в обозримом будущем в тех же объемах, что он продается сейчас.

У инженера обычно в комплекте где-то в районе пятой точки есть чуйка, которая подсказывает ему, хватит ли ему ресурсов или будет маловато. Чуйка обучается опытом а потом подтверждается расчетами.