Перейти к содержанию
    

Как делить программу на объекты?

Классы на периферию приведут к усложнению менеджмента ресурсов.
Классы обезличены и легко станет возможным  попытаться сделать лишний порт или скопировать класс порта и размножить объекты работающие с одним и тем же портом. Профайлинг также станет труднее. 
В mbed все классы периферии вынуждены наследовать специального предка предотвращающего копирование периферии, настолько это распространенная ошибка.   

Периферия  должна оставаться глобальной, А лучше ее вовсе не трогать. 
Наступают времена HAL-ов. Да и кольцевые буферы устарели. Современные UART-ы работают на 5 и больше мегабит.
Делать прерывание на каждый символ - это очень не гибко и не рационально.
 
Например в Renesas S7G2 есть  модуль  DOC, он сравнивает идентификаторы пакетов, потом дает событие в модуль DTC, тот читает длину пакета, и дает событие в модуль DMA, тот читает весь оставшийся пакет в память задачи и в модуль CRC.    
Все без участия процессора. Прерывание возникает только когда весь пакет в нужном месте.  Обмен хоть на 10 мегабит возможен.    
Задействовано как минимум 4-е ( или 5-ть если с таймаутом) модулей периферии. Эт ювелирная работа. Никакой C++ здесь не поможет. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 минут назад, AlexandrY сказал:

Периферия  должна оставаться глобальной, А лучше ее вовсе не трогать. 
Наступают времена HAL-ов. Да и кольцевые буферы устарели. Современные UART-ы работают на 5 и больше мегабит.
Делать прерывание на каждый символ - это очень не гибко и не рационально.

У ТС, я так полагаю, разовые команды. Потому вполне рационально.

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

Другое дело, если бы в МК периферия DMA была достаточно умной для того, чтобы на лету анализировать данные и выдавать прерывание по встрече символа-ограничителя. Либо вовсе аппаратный байт-стаффинг - отправили шифрованную посылку, приняли и аппаратно декодировали в поток готовых байт - было бы очень здорово. Планирую как раз в одном ZYNQ-шном проекте так сделать, раз уж лапки UART на ПЛИС заведены.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 minutes ago, Arlleex said:

 Планирую как раз в одном ZYNQ-шном проекте так сделать, раз уж лапки UART на ПЛИС заведены.

А вот это то, что называют велосипедом. Т.е. ни смысла, ни славы. 
Все нужные интерфейсы в микроконтроллерах уже есть, надо только правильно их применять.  На ПЛИС-ах теперь только G5 делать.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 минут назад, AlexandrY сказал:

А вот это то, что называют велосипедом. Т.е. ни смысла, ни славы. 
Все нужные интерфейсы в микроконтроллерах уже есть, надо только правильно их применять.  На ПЛИС-ах теперь только G5 делать.  

Да при чем тут велосипеды? У меня 4 оптики, полтора десятка ARINC429 плюс нексолько десятков МКИО, полсотни дискретных сигналов, Ethernet, SPI, I2C, UART, и нужно было еще UART подцепить один отдельный, но лапки на SoC закончились. Ни смысла, ни славы, да?:blum:

Поэтому и завели на ПЛИС, она мне сразу аппаратно байт-стаффинг делать будет, и для процессора это будет выглядеть как UART с аппаратным фрейм-разделителем. Ну разве не красота?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, Arlleex said:

У меня 4 оптики, полтора десятка ARINC429 плюс нексолько десятков МКИО, полсотни дискретных сигналов, Ethernet, SPI, I2C, UART, и нужно было еще UART подцепить один отдельный, но лапки на SoC закончились. Ни смысла, ни славы, да?:blum:

Поэтому и завели на ПЛИС, она мне сразу аппаратно байт-стаффинг делать будет, и для процессора это будет выглядеть как UART с аппаратным фрейм-разделителем. Ну разве не красота?

К чему эта вся лабуда?  
ARINC429 - примитивнейший протокол с физикой подобной UART-у. Че там у вас за оптика непонятно, тож скорее всего примитивная физика. 
Ethernet идет в любом самом мелком микроконтроллере, про остальную мелочевку молчу, постыдились бы упоминать.
Все это сделать - работа уровня дипломника.  

Вот если б у вас был реализован 802.11ac да с драйверами хотя бы до уровня сокетов вот это было бы сильно. А так просто много велосипедов. 
 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

51 минуту назад, AlexandrY сказал:

К чему эта вся лабуда?

К тому же, к чему и ваша - для решения поставленных задач.

 

51 минуту назад, AlexandrY сказал:

ARINC429 - примитивнейший протокол с физикой подобной UART-у. Че там у вас за оптика непонятно, тож скорее всего примитивная физика. 

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

Оптика конечно примитивная - 1Gb/s нитки с ARINC818. Я, так смотрю, для вас это пару дней работы.

 

51 минуту назад, AlexandrY сказал:

Ethernet идет в любом самом мелком микроконтроллере.

Гигабитный, да?:wacko2:

 

51 минуту назад, AlexandrY сказал:

Все это сделать - работа уровня дипломника.

А где таких дипломников найти, не знаете?

А то институты выпускают специалистов, а там, как оказывается, пни одни...

 

P.S. Разговор-то, в общем, не об этом. А о том, что в силу определенных обстоятельств, аппаратная корректировка интерфейса в виде прослойки ПЛИС иногда очень даже кстати.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

12 hours ago, Arlleex said:

К тому же, к чему и ваша - для решения поставленных задач.

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

Так вот я жду когда вы к логике перейдете.
Что это за сложную логику вы на 1 Gbit потоке умудряетесь делать на процессоре? 
Железо - это ни о чем. Нахватали готовых корок и слепили. Или вообще получили с KIT-ом нахаляву.
Где собственное интеллектуальное вложение?  
Демонстрируете типичную ошибку джуниоров хвастаться железом, хотя самое сложное - софт.   
Обсуждаем здесь, если вы заметили, программные архитектуры. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

43 минуты назад, AlexandrY сказал:

Железо - это ни о чем. Нахватали готовых корок и слепили. Или вообще получили с KIT-ом нахаляву.
Где собственное интеллектуальное вложение?  

Вы это щас серьезно?

Походу это вы готовые корки везде где только можно распихиваете, других к этому делу только не привлекайте. Все корки у нас свои, все реализации протоколов, в том числе видео по ARINC818 - свои, FC-AE-ASM - свои, МКИО, и прочие более медленные интерфейсы естественно свои.

Или вы думаете, что реализации военных авиационных протоколов валяются где только можно и их использует подавляющее большинство аудитории на нашем Форуме, чтобы можно было почерпнуть опыт или "готовые корки"?:wacko2:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 минут назад, Arlleex сказал:

Или вы думаете, что реализации военных авиационных протоколов валяются где только можно и их использует подавляющее большинство аудитории на нашем Форуме

Наши соисполнители для MIL-1553-B использовали готовую корку Gaisler. Но вот во всем остальном вы правы. И при том даже, что было всего 2 мила, 1 RS-232 и немного внутренней дискретной рассыпухи, это работа уж явно не для дипломника на 2 дня. Учитывая еще и специфику остальную.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

. . . вторая страница, а непонятных слов и даже букфф :crazy: становится все больше ! 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

19 minutes ago, k155la3 said:

. . . вторая страница, а непонятных слов и даже букфф :crazy: становится все больше ! 

Когда взрослые дядьки меряются пиписьками, то остальным смотреть на это вовсе необязательно :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Применение ООП в задачах топикстартера - это любовь к искусству, троллинг или обучение?

Лично я как прежде всего железячник не считаю, что мне это ужасно необходимо (хотя немного владею). Профессиональному программисту - возможно, нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

13 минут назад, V_G сказал:

Лично я как прежде всего железячник не считаю, что мне это ужасно необходимо (хотя немного владею). Профессиональному программисту - возможно, нужно.

Профессиональному программисту нужно в первую очередь решать прикладную задачу. А всякие страдания "ООП / не ООП", это уже - кододрочерство и не имеет отношения к профессионализму.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Применение ООП в задачах топикстартера - это любовь к искусству, троллинг или обучение?

Первое и третье.

Отказываюсь от классов. Думаю, может, использовать namespace?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

13 minutes ago, ViKo said:

Отказываюсь от классов. Думаю, может, использовать namespace?

Классы - это лишь инструмент,  namespace - тоже инструмент.

Каждый хорош для своей задачи: отверстия удобнее сверлить дрелью, а гвозди забивать - молотком, но не наоборот ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...