Flexz

Ну вот и я добрался до железа с HS USB :) Результаты очень даже радуют. На рам-диске (в озу контроллера) в режиме Mass-Storage сходу получилось 30МБ/с, с zero copy - уже 35, это без файловой системы, прямой доступ к диску. После устранения оверхеда в лице mass-storage, удалось раскачать до 42МБ/с, правда этот вариант несколько искусственный, т.к. проц просто непрерывно передает большие блоки, но для оценки максимальной достижимой производительности - сойдет. Еще что интересно - на таких скоростях похоже уже начинает оказывать влияние контроллер хоста. Указанные выше цифры были получены при подключении к USB 3.0 порту компа, в 2.0 портах скорость на 3-6 МБ/с ниже. Понятное дело, что HS/SS ни при чем, дело либо в организации самого контроллера, либо производительности шины на которой он сидит.

загляните в misc.c NVIC это часть ядра, и описана так же как, например, система команд в Cortex M3 reference manual

Кто ж ему помешает-то? 16 клоков нужны только для надежного обнаружения стартового бита ака ресинхронизации, так они на месте - меньще 0x10 в BRR писать нельзя.

Вообще-то "дробные" частоты получить очень просто: если записать в BRR 0x33, то UART на один бит отмолотит 3 целых 16 тактовых интервала, а потом еще 3 такта Fbus (всего 51). Т.е. если считать базовой частоту Fbus/16, то делитель действительно можно называть дробным (в данном случае 3.1875). А если базовой взять Fbus то никаких дробей нет, делитель просто считает от 0 до BRR, т.е. делитель - 51.

Дык у F1 у UART1 потолок 4.5Мбит, у 2 и 3 - 2.25МБит 36000000/16 (при единичке в BRR) и будет 2.25, откуда 10? PS 10МБит достижимо для F4 только

Да, можно программно сгенерить, есть специальный регистр для этого - EXTI_SWIER. А вообще, контроллер прерываний вроде бы позволяет программно генерировать любое прерывание, хотя сам я этим не пользовался никогда. Так что выбор большой :)

Если высокочастотное прерывание идет от внешнего источника, то завести его на таймер, который считает до N и дергает второе прерывание. Если же оно внутреннее, то как уже сказали выше - использовать софтовые прерывания, в stm32 это можно сделать через EXTI, например.

В мануале про EXTI_PR написано Reset value: undefined, так что очищать обязательно. А вообще есть хорошее правило - всегда сбрасывать любые статусы, перед тем как разрешать соответствующее им прерывание, помогает избежать трудно-уловимых глюков.

Не скажу за все конроллеры, но STM32 стартовым битом считает единицу за которой следует ноль, аналогично at91sam7. В ином случае такой медод начала кадра не будет работать. Что касается начального символа, то при таком подходе одинаково подойдут и FF и 00.

Можно поинтересоваться, а это как вообще? Чего можно ждать от растяжек? Ну держат линию в "единице", но как на этом можно протокол строить? Вероятно, имелось ввиду, что делают это не одновременно, а сначала включают передатчик, ждут немного (например, чуть больше байтового интервала), потом только начинают передавать.

См. мануал: Figure 1. System architecture и Figure 22. System implementation of two DMA controllers. DMA1 не имеет связи с AHB1, а GPIO как раз там.

Вы проводили замеры производительности при запуске кода из SRAM/FLASH? У меня вот получилось весьма неожиданно, что код из sram выполняется даже медленнее чем из flash, с включенным акселератором, естественно. Поэтому на размещение кода в ОЗУ на данном проце как-то сразу забил. А по теме - стоит задействовать раздельную структуру ОЗУ в F4. У меня вот переменные и стек по умолчанию идут в CCM, а если какой-то буфер нужно сделать доступным, например, для DMA - он явно кладется в секцию SRAM1 или 2. Непосредственно по оверлеям ничего советовать не буду - никогда их не реализовывал.

Какая разница когда он включится? Все равно в итоге получится гарантированный фрейм эррор на первом idle интервале и засинхронизируется на следом идущем стартовом бите (а если ошибки нет - значит синхронизация сразу была успешной) У вас что приемник в рандомные моменты времени включается/выключается, не дожидаясь получения достоверных данных?

Ну как же.. Партия сказала "Надо!", комсомол ответил "Есть!" :) Не пачка единиц, а "молчание" на линии - даст 100% гарантию синхронизации на следующем стартовом бите.

Вообще говоря ситуация когда UART включается "посреди" слова вполне нормальная, ведь никто не гарантирует, что в неком абстрактном устройстве приемник включится раньше передатчика и будет готов ловить первый фронт первого стартового бита. Такая ситуация разруливается несколькими средствами: во-первых в конце слова идет стоповый бит (единица), если его нет - это frame error, во-вторых в поток включаются idle слова - единица удерживается на линии в течении времени достаточного для приема целого слова (т.е. словив frame error на idle слове следующий стартовый бит будет гарантированно верным). Дополнительно поток можно разбивать на кадры, в начале кадра вставляется синхропосылка (одно или более предопределенных слов), а в конце кадра контрольная сумма.

Сразу говорю - в криптографии не силен, так что может поясните: почему? На мой дилетантский взгляд: допустим сначала данные подгоняются под первый хеш, потом сохраняя подгон под первый, подгоняются под второй, так? Так при втором подгоне портится первый хеш. Тогда сложности не складываются, а перемножаются. Или при подделке двойного хеша логика работы другая?

Визуальная оболочка для буста это сильно :) Вообще-то там нет ничего, что можно было бы визуализировать. Это большущий набор библиотек, которые могут здорово упростить жизнь плюсовому программисту, но задачу разработки GUI он не решает. Если MFC не устраивает (или что там нынче у майкрософта кроме .NET имеется?) можно посмотреть в строну Qt, например. PS Чем тут Моно поможет? Все равно за собой фреймворк тащит, не один так другой.

Нынче - хз, у меня старенькая 4.5.2, да и CodeSourcery больше нет, их же Mentor купил. А с тех пор как купил - что-то там перекорячили на радостях, да так что старые проекты не компиляются. То ли ключи какие-то поменяли, то ли еще что, у меня так руки и не дошли разобраться с ним.

А MAC - не плавучка? Не понимаю, по какому принципу вы их разделяете? Вот список инструкций доступный в M4 (DSP instruction set внизу), это то что вам нужно или мы о разных вещах говорим?

Наверное, все-таки не datasheet а reference manual, не? И назовите-таки полное название процессора, stm32 это на данный момент большущее семейство, например моя цитата взята из RM на STM32F2.

Интересно, а почему ж тогда в мануале пишут ?

Ну в идеале - да. Но вот конкретно под stm32f4 на CodeSourcery gcc мне не удалось ничего с hard скопмилить - валится на линковке. hard в отличии от softfp разрешает компилятору передавать в функции параметры в FP регистрах, а так - там и там сопроцессор используется одинаково.

В Cortex-M4 есть только базовая арифметика с плавающей запятой, при компиляции gcc нужно добавить ключи -mfloat-abi=softfp -mfpu=fpv4-sp-d16

"В лоб" stm32 так не могут, но можно представиться карточкой не поддерживающей 4-битный режим, тогда SDIO сведется к двум линиям полудуплексного синхронного последовательного канала. Тут уже можно попробовать прилепить USART или SPI, но скорость будет небольшой. upd: или другой вариант - поставить между процом и фотиком плиску, которая будет во-первых сама сливать данные во флешку, во-вторых передавать их процессору в том формате, который удобен.

про сдшки в обоих мануалах (на 2 и 4) написано ровно одно и тоже Чем вызвано ограничение для SD - непонятно.