jcxz

А если прочитать предыдущие посты этой темы?

Не надо придумывать чего нет. Нет там бесконечного.

Что именно? Вангую это обрывок фразы: "чудовищно здорово!"

int err; while (1) { занятие_ресурсов err = код_ошибки1; break; ... err = код_ошибки2; break; ... } обработка_ошибки: освобождение_ресурсов PS: Я никого не призываю так делать и не агитирую. Просто отметил, что так тоже бывает.

За ~20 лет профессионального писания на си как для embedded, так и для ПК, я не написал ни одного(!) goto. Ну так примените. Коли есть. И объясните. Так расскажите нам - КАК? Раз "реализована". И какая разница - какое ядро? Или PIC умеет на аппаратном уровне организовывать несколько вычислительных потоков?

Если не Ваш, то откуда у Вас исходники? Внимание вопрос: Если в таком суперлупе например HTTP-серверу (или FTP или ещё кому) пришёл большой объект данных, который нужно обработать как единый объект (например: выполнить текстовый парсинг с разбором типа JSON-сообщения или выполнить его декодирование (AES, аппаратной криптографии в МК нет) или посчитать хеш или сделать упаковку/распаковку если сжато). А если и то и другое и третье подряд? И при этом необходима быстрая реакция на какие-то короткие простые команды по другим интерфейсам: UART, UDP, да хотя-бы даже - клавиатура (например там у вас энкодер опрашивается), или скажем - необходимо быстро отреагировать на превышение какого-то порога по токовому датчику. Как будете выкручиваться из такой ситуации? А если ещё нужно на LCD-индикаторе большие картинки рисовать в это же время. Другой вопрос: Вот нужно например какому-то из этих процессов (HTTP, FTP и т.п.) выплюнуть в лог приличный объём данных, скажем - пришёл некий бинарный объект, размером с пару КБ, нужно его содержимое распечатать в текст (получится уже например около 10-20КБ) и выплюнуть в канал лога (UART). И опять-же - при этом не положить остальные процессы и не сожрать для одной этой элементарной операции >10КБ ОЗУ. Сам процесс при этом не очень интерактивный, юзеру не нужно получить результат за миллисекунды - может подождать.

DSP для обработки реал-тайм событий и алгоритмов управления "вермишельного" типа?? Выбор - хуже не придумаешь. Даже хуже чем использовать его для работы в режиме memcpy-only...

"Блокирующий I/O" в отличие от "неблокирующего I/O" - это когда функция API возвращает управление в вызывающую процедуру после завершении I/O-операции. При неблокирующем I/O управление может быть возвращено в вызывающую процедуру до завершения всех I/O-операций, а сигнализация о завершении I/O-операций производится дополнительным механизмом (при помощи семафоров и т.п.). Неблокирующий доступ позволяет не задерживать работу задачи на время выполнения I/O-операций. Но он сложнее. Блокирующий доступ конечно проще, но требует выделения в отдельную задачу ОС, если нужно чтобы выполнение других функций не тормозилось I/O-операциями. В некоторых API есть как блокирующий так и неблокирующий механизмы работы. Например - в WinAPI, неблокирующий доступ называется "overlapped I/O", а блокирующий так и называется. Насчёт FatFS: насколько я знаю она имеет только блокирующий API. Хотя ТС так и не прояснил с помощью какого middleware он работает с SD. Остаётся только гадать. Если он использовал блокирующий механизм, то естественно в работе вызывающей задачи будут задержки на время выполнения каких-то операций (типа ожидания завершения записи или стирания). Вообще-то такой вариант я и предлагал ещё в том сообщении, на которое вы отвечали. Это и получается, что на прерываниях (таймера или чего другого) будет реализована псевдозадача. Т.е. - будет аналог работы 2-х задач в РТОС. Для задачи ТС-а и его МК какие-то накладные расходы связанные с РТОС настолько несущественны, что ими можно пренебречь. На Cortex-M на частотах в десятки МГц и выше, накладные расходы РТОС - доли процента. Зато когда окажется, что ему вдруг например: нужно выводить отладочные логи из одной задачи и из другой одновременно в один UART и чтобы другу-другу не мешали, вот тогда окажется, что с РТОС это решается за 5 минут штатными механизмами (семафорами и т.п.). А если он то же самое попытается сделать из псевдозадачи на ISR-ах, то скорей всего сядет в лужу. Ну или в лучшем - потратит в разы больше времени на реализацию такого механизма. Вы посмотрите на МК который у ТС. Это не 8-битный AVR. Каждый байт тут экономить нужды нету. Экономить и оптимизировать нужно только там где это реально нужно.

"Она" - это кто? О ком речь? Middleware реализующая работу с ФС? Есть неблокирующая? Расскажите тогда нам о такой. Я думаю - многим будет полезно узнать о таком. Чем именно усложнит? Имхо - реализация более-менее сложного автомата состояний внутри ISR для новичка будет гораздо сложнее РТОС. А Вы уверены, что сможете разобраться в межъядерной синхронизации, если даже межзадачная синхронизация (в пределах одного ядра) у вас вызывает страх? Межъядерная синхронизация заведомо сложнее межзадачной. Да и смысла никакого нет тащить ещё и второе ядро для такой простой задачи. Точно так же застрянете при передаче его между ядрами. А там ещё сложнее передавать. PS: Изучайте многозадачную работу и средства межзадачной синхронизации! PPS: Не понимаю - откуда такая боязнь РТОС у множества здешних писателей?

Не настолько, чтобы не справиться с задачей, работающей на примитивном PIC-е, у которого стек глубиной всего 2 уровня. Вообще - я на STM8S (который даже слабее чем STM8L) BLDC-движок крутил. При частоте ШИМа 10кГц и работающем одновременно пользовательском интерфейсе управления/отображения состояния через терминалку. А у ТС-а вроде как вообще простейшая задача.

Вопрос к тем, кто реализовывал работу по HTTPS (или подтягивал готовое решение) в своих девайсах. Главным образом интересует исполнение на ARM-ядрах. Каковы примерно требования по быстродействию к CPU при работе с потоком данных через HTTPS (скачивание в устройство одного большого файлового потока, без открытий/закрытий TCP-сокета; исходящий поток - минимален или вообще отсутствует)? При условии того, что в МК нет аппаратного модуля криптографии (программная реализация криптографии). Т.е. - сколько нужно МИПСов на 1 кБ/с потока? Как это зависит от опций HTTPS (я так понимаю - в нём могут использоваться разные протоколы шифрования)? Интересуют самые актуальные на данный момент протоколы шифрования (экзотические/устаревшие - мимо кассы) используемые в HTTPS.

STM8L в таком же корпусе. Заменять на такое простейший PIC - это из пушки по воробьям.

Ну да, только забыли сущий пустяк: ТС наверняка работает с SD через файловую систему. И использует для этого какое-то готовое middleware (типа FatFS). Которое тоже почти наверняка работает в блокирующем режиме. Так что 6-м (и самым главным!) пунктом будет - переписать это самое middleware в неблокирующий режим. Да ещё как-то скрестить его с этим самым двойным буфером. А эта задача и профессионалу не всякому по плечу будет, и главное, что по сложности она в разы превысит все остальные пункты вместе взятые. А в блокирующем режиме на сколько частей не делите буфер DMA или вообще без DMA - один фиг будут паузы в суперлупе. Так как Вы описываете, будет работать только если без ФС. Но "без ФС" я думаю, что и вообще SD-карта не нужна, а удобнее использовать какой-либо чип SPI FLASH. PS: Так что - или крестик сними или трусы надень или делим суперлуп на задачи или избавляемся от ФС. PPS: При желании "задачу" работы с АЦП можно сделать в виде псевдозадачи, на прерываниях и автомате состояний внутри. А работу с ФС - в фоновом цикле. И формально обойтись без РТОС. Но для начинающего это, имхо, будет сложнее, чем разобраться в работе из под РТОС. Да и смысла особого нет для такой примитивной задачи как у ТС.

Наконец-то доползли до сути проблемы. Забываем о суперлупе, переделываем всю работу под любую РТОС. На две задачи: 1) работа с АЦП; 2) работа с файловой системой на SD-карте. Приоритет 2-й задачи ниже чем у 1-й. И проблема решается. Можно даже без DMA и на одном ядре.

А если у ТС-а процессор в thread-mode работает?