за сега SSL не ме вълнува.
чудото се очаква да работи зад приличен рутер и няма да е на поляната. но все пак трябва да може да се справи с по-малките буламачи, вървящи в корпоративна мрежа с позаспал админ.
най-вече да не обръща внимание на полудели уиндоуси, да не може лесно да се гътне с DоS атаки. малко вероятни са дефрагментирани пакети и аут-оф-оредер, но ако се справя с тях, ще е ОК.
поръчал съм си китовете на атмел, на тях има SDRAM в достатъчно количество, но ако мога да мина с вътрешната памет ще е добре.

стратегията за сега е да нацъкам FreeRTOS конфигурация с техния стек и да пусна моя софт. едва след това ще имам виждане какво ще ми трябва като ресурс по-нататък.
надявам се техния дебъгер на платката да може поне да издупчи флаша и да извади някакъв трейс. ще видим.

демек ти трябват няколко мем-менаджера kernel/user( heap_5 ) да не фрагментираш (user e проблемен, зависи какво ще алокваш)
LWIP-то си фрагментва на 1 MTU пакети
иначе за "непознато MCU" проблема ти е порт за ОС-а, HAL за периферия, драйвер за мрежата

ама за тоя двер дето го мъдриш бая оптимизация ще иска

ще го измъдря... стига готовия софт да не го е писала някоя булка с мъде.
но понеже задачката не е особено тривиална, по-големите топки (м7) ще са предимство. то и елхичка се аранжира по-бързо с големи играчки

пакети над MTU просто ще се дропват още на ниво МАС. джъмбо-фреймове не се предвиждат (за сега).
хардуерна поддръжка на няколко етертайпа (плюс съпътстващите опашки) ще е супер.
но това е на етапа реализация и оптимизация.

за начало искам само да тествам колко са зле RTOS-а и нет-стека, за да придобия представа къде сме, без много телодвижения.
с нашия софт на голем интел не може да се прецени нищо като бързодействие. за дежелопване е удобно - логове, асерти, цяла UNIX е под теб. ама на кортексче дали ще е 100 пъти по-бавно или 1000?

'user space' ще е статичен по проект, дали ще се наложи да се пуска алокатор - ще видим в последствие.
то и микро-кърнъл всичко извън него е 'user space' та ще видим какви са мотиките и с неговия HAL/драйвери. във всеки случай, в дребна въшка без MMU тези термини са твърде условни.
да стигнем до там.

Преди две години си играх с https://www.st.com/en/evaluation-tools/ ... overy.html, по спомени подкарах всичко, включително и мрежата доста бързо, използвайки техния инструмент за конфигуриране и код генерация.
Напрактика след малко цъкане по конфигуратора имаш пингваща се платка... Ако пък не ти се занимава с това, предполагам мога да изнамеря проекта на сорсове та той да ти е стартова точка за експерименти, имай предвид че е беър метъл, т.е. един лууп в мейна без ОС, ама работи.

Останали са ми платки, ако искаш ще ти ги дам да си тестваш.

П.С. Тезата ми е че с СТ бързо им се подкарват нещата, незнам NXP, Atmel как са.

На конфигуратора за ST си има чекче и за FreeRTOS, но последно преди няколко месеца като го пробвах, генерираше бълвоч, който дори и не се компилираше. За модификация на готов проект (за тула) и дума да не става - тула гърми яко. Все пак има и хубави страни - без FreeRTOS поне се компилира безпроблемно. Може да генерира код за няколко IDE-та и включително за Makefile.
Има и примери и демонстрационни проекти в препозиторито (локално на ПЦ) на STM32CubeMX за дадената серия контролери.

За ST има много лесни варианти - освен споменатите можем да добавим и mbed. Но атмел не се поддържа там (има и фрискейл и nxp). Но те атмела нали си имат подобно конфигураторче в тяхното студио.
Опции са разните ртос-и - чиби, зефир, нутх и т.н. Напоследък излязоха доста - има едно alios което е на алибаба - колкото и стряскащо да звучи си е доста смислено.

Да бъркам, колко да бъркам?
Не са по 16к малко повече са...



Това са само буферите... отделно в ssl_handshake_init() са още обслужващи структури, отделно един куп шифъри като всеки си има бифер+дигест... С две думи си трябват едни 40-50к (поне) за да отвориш сокет с мбета. В това не включвам паметта за tcp/ip, където ако MAC-а и стека са при теб ти си решаваш колко памет ще ти се откъсне от сърцето, ама си е редно поне по няколко пакетчета да можеш да буферираш във всяка посока.
А ония 4-5к са за приложението - там ако ти си пишеш http-то може и без буфери, само трябва да обработваш байт по байт

Просто който иска да подкара tcp стек и SSL е добре да има повечко памет, не се надявайте на чудеса със стандартните библиотечки. Има и нестандартни като моята, където паметта се пести ама за сметка на повечко обработки. Та пак няма безплатен обяд

Това е user настройка....

https://github.com/Wiz-IO/PIC32-FreeRTO ... asic.h#L62

Ако съм нацелил линията...

реално encript/decript - 1 MTU пакет = 1500

https://tls.mbed.org/kb/how-to/reduce-m ... -footprint

Реално криптирането и MTU-тата нямат нищо общо. Комуникацията става на записи. Един запис (record) може да съдържа едно или повече съобщения (message). Някои съобщения са само 1 байт, но пък тия със сертификатите може да са доста килобайти. Въпросът е, че докато нямаш цял запис трудно ще криптираш или каквото там искаш да правиш.
Ако контролираш и сървър и клиент - да може да си вкарваш всякакви ограничения. Но това е безумие. Ти ако контролираш двете страни просто си криптирай данните и не използвай изобщо TLS протокола. Проблемът както казах е заложен в самия протокол - не е мислен като за ембедед изобщо. Даже доста сървъри умишлено "оптимизират" комуникацията като наблъскват всички съобщения от хендшейка в един запис. В момента точно се боря с един такъв сървър. Принципно това за компютър е логично, защото няма смисъл да превключваш процеси/нишки. Дърпаш само началото да видиш колко е голям записа, после чакаш да дойде целия и тогава накуп обработваш.
За съжаление обаче си трябва памет за тоя номер... и лошото е, че не ти решаваш как да ти пакетира другата страна.

От практически наблюдения повечето сървъри се "вмъкват" в 4-5к. Говоря за хендшейка. След като мине той вече зависи от приложението. Така че 6к буфер мисля че ще работи за повечето. Но това е с уговорката, че винаги могат да те изненадат неприятно с по-голям запис. По стандарт е 16к....

Дедо искаше нещо бързо и лесно, оптимизациите сигурно ще ги остави след като стисне парите
И двамата сте прави - ако има рам е много по-лесно да се реализира с големи буфери, ако няма рам с клизма може да слезе до мту-то.

Какво значи няма RAM? Нали за това се е насочил към M7, там чеповете масово са с по 512К / 1М, дето се вика и линукс може вътрешночипно да търкаля.

Аз просто обръщам внимание, че козата си сака пръч... секюритита ядат много памет. Особено ако се наложи да има по няколко отворени конекции изненадата може да е много неприятна. Свиването на буферите е някакво решение, но си е бомба със закъснител. Аз съм преработил TLS-а поне да не заема повече, отколкото е нужно. Но и това не е панацея щото пак като ми пратят голям запис ще заема памет. Правя го заради повечето конекции с надеждата, че няма всички по едно и също време да правят хендшейк. А и се надявам да подкарам кеша на сесиите, т.е. да не се налага при всяко вдигане да правя хендшейк.
Абе най си е добре да си има повечко памет. И за tcp стека също е нужно да се предвидят повечко пакетчета, ако се гони скорост или повечко трафик или конекции... Няма как с малък фрейм да се постига скорост просто.
Сега верно че има контролери и със сравнително "много" РАМ. Въпросът е да се предвиди използването му, щото тоя сорт приложения също искат памет и лесно може да се забрави че за тъпия трансфер може да са нужни десетки или стотици килобайти.

Дедо, до къде я докара с тоз ми ти Cortex?! Гледам, че са пуснали и с мотор контрол на по 300МХз и се чудя дали да не направя опит. Така и така ще правя нов дизайн...

до никъде, практически.
теоретично изчетох няколко (дестки) хиляди страници, ефекта е основно обогатяване на моите познания, но не и визия как практически да получиш нещо работещо.

вчера имаше семинар, NXP облъчваха за RT палтформата, втора серия. която беше като първата, май пред друга публика.

чудеха се защо народа е толкова незаинтересован. казах им моето мнение:
човек му хрумва идея/натрисат му проект.
рови малко в нета и си харесва (тяхното) желязо, щото видимо има всичкия хардуер, който би му потрябвал, че и с излишък.
купува си дев. борд, сваля няколко гиги SDK, среда, компилатори.
взема някой примерен проект, който се доближава до неговия, пуска го на дев. борда и почва да го ръчка, да си добавя неговата функционалност. очакванията са за няколко седмици да го добута до нещо работещо като софтуер, след което да си направи платка и да си шлифова софтуера, къде с по-едра, къде с по-финна шкурка.

но никой няма да вложи месеци в нагаждане към някакви безумия, да си пише негова ОС, драйвери или стекове. ако тези неща ги няма 'на една ръка разстояние', хардуера, колкото и да е примамлив, ще си остане без клиенти. защото нашата работа е да измислим и продаваме нашите устройства, а не техните чипове. и ако искат второто да се случи, да се напънат малко по-сериозно.

аз се пробвах с NXP, Atmel и ST (за М7).
нищо от горните неща не е доклатено и при трите производителя. кашата е толкова потресаваща, че дори не ми се иска да почвам да пиша. и това важи и за трите базови компонента - ОС, драйвери и стекове.

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

с горното не искам да натрапвам мението, че въпросните чипове и софтуер са напълно неизползваеми. просто на мен ми трябваше М7 с външна памет, мрежа и ТСР стек, който да не е с един крак и едно око, като ръцете трябва да си ги измислям. хардуера има потенциал, дори в излишък. с подходящ софтуер ще 'фърчи като пушка', силикона е на много добра цена, платките са правят относително тривиално. просто в текущия момент софтуера въобще не е на равнището на хардуера и, в случая, е много по-сложен.

та - ако ти трябва управление за мотор, няма да имаш USB или ТСР, препоръчам да си избереш някой от наточените за мотори М4 (NXP/ST), да си свалиш средата, да си качиш SDK-то за матори и с неговия визард да си конфигурираш баш точно твоя случай на мотор. имам впечатления само от NXP, става относително лесно и работи. стига да не искаш нещо на границата на метафизиката, като BLDC с векторно управление, без обратни връзки (енкодер) и на ниско напрежение.