Миро,ти харесваш SAM7S на Атмел. Е той е в пъти по недоклатен И аз имам добри впечатления за STM-a. Само за мен съм си правил устройства,но ми харесва организацията.

Може да се каже, че сме почти на едно мнение... само леко се разминаваме кой е "той"

Иначе, аз че се оплаквам като стара свекърва - признавам си... На всички им намирам недостатъци. При Атмел се дразня, че са на един косъм разстояние да бъдат перфектни като дизайн. Но са допуснали някои дребни трески. Примерно всяка периферия има ДМА, всяко ДМА е на офсет 0х100 и на практика имат еднакви регистри на тоя офсет, обаче не са съвсем еднакви. Ако бяха щеше да може с една функция да се обслужват всички периферии, само подаваш като параметър периферията и толкоз. Да, ама тъй като не са съвсем еднакви се налага за всяка периферия да пишеш различен код, като разликите са смешни. Всъщност може и да стане и с универсален код, ако се подадат допълнитени параметри за наредбата на регистрите, но бързината е по-важна и не съм се мъчил.
Сега тия неща ме дразнят, но истината е, че по никакъв начин не могат да ти провалят хардуера или софтуера. Специално 7-ците имаха и по-сериозни проблеми. Примерно I2C контролера беше зле, без ДМА и ако се забавиш с прекъсвнията брейкваше. Последното е недомислица, но няма проблем да му сложиш достатъчно висок приоритет на прекъсването, все пак е само една периферия с такъв проблем. Смяната на клоците също беше приключение, но с повечко усилия/код си бачкаше. Хубавото е, че Атмел ги изчистиха тия проблеми при прехода от АРМ7/9 към куртекс. За съжаление обаче не изчистиха недомислиците с ДМА-тата дето казах в началото, така че все още не са перфектни.
Като цяло обаче няма по-изчистен и по-добър дизайн от тоя Атмел. Няма и подвеждане. Ако ти трябват някакви периферии и ги има в даден атмелски чип, то може да бъдеш 100% сигурен че няма проблем да ги ползваш и то да ги ползваш на 100% натоварване.
При другите не е така - чипа има периферии, ама като почнеш да ги нареждаш по пинове се оказва, че няма нареждане. Ако ползваш това, не може да ползваш онова..
Специално ST кусурите му са безброй. Като се почне от мапинга на F1 (добре че в другите фамилии са го оправили). Това да нямаш прекъсване на всяко GPIO е също е уникално решение от годините на 8051. Уарт да няма receive timeout също не си спомням от много години. То и при Атмел има една такава периферия ама изрично не я броят за Уарт а за дебъг порт. SPI да няма променлива дължина също. ДМА2 пък като се пусне повече от 1 канал може да се омаже, айде това е бъг но си го има и на Ф4. Сис-тика има някакви нестандартни делители, а в дебъг режим не спира и ме побърква. Кучето пък като се пусне няма спиране, което също усложнява дебъга, щото спираш, рестартираш и докато се флашва гърми. Айде с това се живее, ама кофти лази по нервите...

Ами остави ги тогава тия ST-та и пробвай следващите - примерно фрискейлските кортекси. Любопитно ми е как ще ги наредиш и тях.

То и на мен ми е любопитно, ама ново търсене на чеп, нови чаршафи (дето трябва да внимавам как чета), нова схема, нова платка, нови драйвери за ОС...
Всичко това е време! И пари...

Хубаво де, аз пак не разбрах, що ти трябваше да сменяш Атмела с STM32 в такъв случай?

вече го казах - за конкретния проект решението го взехме миналата година и тогава Атмел все още нямаше куртекси с толкова RAM, че да търкалят етернети, графики и т.н.

Освен това целта ни е да имаме вариант "Б" ако се окаже, че основният производител спре доставките. А точно преди година поняш какви слухове се носеха за Атмел...

а вярно, че спомена паметта...

Абе незнам, но тука във форма всички сме или на СТ или на Атмел. Луминари ги избягваме ясно защо, ама май никой не e заложил тежко на NXP.... аз ги ползвах навремето до ARM7 и после даже незнам каво имат като куртекси... Може и да не са зле, а?

Луминари бяха голяма боза, то не бяха пачове във флаша, специални ресет процедури и други глупости. Но в последните ревизии тия проблеми са изчистени. Като периферии са прилични. Предимството е, че всичко е фифо базирано и работи правилно в дебъг режим. Може да си дебъгваш спокойно без да се притеснясаш, че като спреш на брейкпойнг ще изпуснеш байтове. ДМА-то обаче е грозно, ама аз не го ползвам, фифо-тата са ми достатъчни.
Версиите с етернет също са супер, заради вграденото пфи... и цената им е много прилична. С две думи стават да се ползват за много неща. Не стават обаче за ниска консумация. Поне тия чепове дето ползвам най-ниската им консумация е 10ма в слийп, ебати слийпа...
NXP ги гледах като излезе 43-та серия. Имат много интересни идеи като SGPIO, обаче като се опитах да скалъпя една схема се оказа че не мога да ползвам половина периферия. Освен това имаше доста сериозна errata, малък избор на памети и с две думи се отказах...

Това, което много ми хареса на пръв поглед са Energymicro. Наистина с удоволствие бих ги тествал, само да падне подходящ проект.

Някакви впечатления от Cortex M на Freescale? Питам само за обща култура.

Тях още никой не ги е виждал на живо .
Аз имам един кит с най-якия Кинетис, ама все не ми остава време да се побъзикам с него, та и аз чакам първо някой друг да се "опари" и да разправя тук ..

Някой да е виждал двойно буфериране на ендпоинтите на OTG-а на STM-a ?

На старите F1 споменават за двойно буфериране (ако ендпоинта се ползва само в една посока), ама мен ме интересуват новите, т.е. от F2 нагоре...

тия STM са прозто върха... с ударение върху "з"-то

Това с двойното буфериране при пращане по USB-то няма как да стане, заради "уникалния" им дизайн. Ще го преживея.

Получаването обаче е направо върха на сладоледа. Всички пакети се блъскат в едно общо ФИФО. Кой ли болен мозък му е хрумнала тая гениална идея...

Цял ден си блъскам главата как да го направя. Проблемът е, че от едната страна имам клиенти дето могат да искат четене произволен брой байтове от произволен ендпоинт. От друга страна идват пакети с произволен брой байтове за произволни ендпоинти.
Когато дойде пакет и има клиент дето го иска - ясно. Но кво да го правя като нямам клиент? Ако не го извадя от фифото утрепвам цялото USB. Ако тръгна да вадя пък само проблеми.
Първо може да стане неефективно, особено ако клиента чете на малки парчета, така остатъка от пакетите ще се претаква винаги през разни буфери.
Второ, няма смисъл да вадя само един пакет, ако не мога да извадя и останалите от същия ендпоинт дето чакат. Да, ама за да гарантирам това трябва за всеки ендпоинт да направят толкова голям буфер, колкото е за хардуерния за всички ендпоинти. Демек ако USB-то има 1к общо за получаване, аз трябва да имам поне по 1к за всеки ендпоинт.
Трето, каквито и буфери да имам, ако не спра хоста да ми тъпче по тоя ендпоинт файда няма. Да, ама включването на NAK-ването е живо приключение. Първо трябва да спра абсолютно всички ендпоинтове. После да чакам да се спрат... После да изключа тоя дето не ме кефи, после да чакам да се изключи... После да включа останалите. Ебати филма..

Лошото е, че ако се вкарам в тоя филм с тия изчаквания и глупости скоростта направо ще отиде в киреча. Почвам да си мисля дали не е по-добре да блокирам всичко. То обикновено клиентите ми не се отвяват, ама знам ли в някои от usb класовете дали няма да си докарам deadlock така...

Копаш в неорана земя, братче. Освен съчуствие, друго няма какво да ти предложим. Незнам дали STM са засрали пейзжа, щото самата идея да пиша USB стек за каквото и да е желязо ме втриса.

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

Във всеки случай както е оригналната библиотека не ме устройва (мажат по паметта)

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