klen

а вот интересно, оно живое спустя только лет? я не сидел сложа лапки 🙂

мумукался с этой проблемкой, пришлось еще глубже понять как оно (cortex-m + freertos) рабоиает. вроде разобраля, если нужно распишу суть и код дам. туда сюда не прыгал, но физика одна, поэтому наверно будет работать универсально. есть еше засада, оказалось что и не удивительно. если сброс не использовать - будем считать это костыльным решением, новая жизнь, т.е . прилагуха чувствительна к состоянию озу и переферии, оч. внимательно и ВСЕ нужно инитить после загрузчика. . такам обращом задачу прыжка нужно решать в два этапа а) состояние проца + состояние структур freertos б) решить хвосты по инициализации в прилагухе, .bss .data компиллер Вам поможет привести к исходному состоянию, авот что на стеках будет .... мусор от загрузчика, про переферию тоже понятно -к этому моменту она уже живет какойто прошлой жизнью. тут как обычно нужно правильно писать код..

коллега с сахары обнаружил косяг, просба не качать. поправлю отпишусь.

свежак KGP собрано работв в linux64: http://www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20190519_LUPINE.tar.7z собрано для win64 http://www.klen.org/Files/DevTools/x86_64-kgp-mingw32/arm-kgp-eabi_@_x86_64-kgp-mingw32_20190519_LUPINE.7z (к сожалению тестировать неначем, просьба при обнаружении косяков сообщить [email protected] ) имеем binutils 2.32.51.20190518 gcc 10.0.0 20190518 с моими допилами и подкрученным мультилибом в линуксовом дистре также openocd 0.10.0+dev-00867-g2b78f65 (2019-05-18-19:51) dfu-util 0.9 , под linux сборка протестена на рабочих проектах - все жужжит, масдайный неначем тестить. 10 версия компилятора используюет новуй версию LTO формата хранения данных в объектниках. скорее всего скоро можно будет с LTO даже отлаживатся.

спасибо, попробую отпишусь что получится. какой то детский косяк поймать не могу.

Здравсвуйте. в чем может быть косяг? код потока продолжает выполнятся, флаги прерываний периферией выставляются...

коллеги с сахары попросили для cortex-r4 сделать сборку. хост - линукс64 комбинации мультилиба собрано в тестовых целях, только для -mcpu=cortex-r4 1) - / -O2 / -Os / -Ofast 2) - / -mfloat-abi=hard -mfpu=vfpv3-d16 3) - / -flto http://klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi-cortex-r4-20181212_URTICA.tar.7z

да... символ 'nan' линкером не находится.. так и есть. поправил беду.. http://klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20181209_PLANTAGO.7z теперь должно полегчать. еще раз убедился - пока мы(то есть Вы) будем использовать С при кодировании и пресобранные либы (типа libc, libm? libgcc ... итд) хорошего выходного кода мы не получим - и понятно почему. суть трабла на который налетел господин Terminator: 1. сначала собирается комплятор - собираются таргет-либа libgcc.a - в ней всевозможные процедуры работы с стандартными типами С. 2. далее собирается newlib - это реализация стандартных функций libc.a, тут же libm.a что я сделал - я собрал все это барахло с LTO - мои ожидания в том что не только пользовательской код но и ibgcc.a, libc.a, libm.a покроется на круг LTO оптимизатором. не тут то было! при компиляции newlib те функции которые современный GCC 9.0.0 считает встроенными (например в данном случае double __builtin_nan (const char *str) ) он безжалостно выкидывает и наверно думает - "нехрен это складывать в либу - я и так на лету всуну в код нужный код когда С/С++-код пользователя попросит! и линковать ненадо, правдв здорово!". в итоге в libm.a функции log10f есть вызов nan(), а в объектнике который вышел из исходника sf_nan.c - его нет (тупо вырезано). в итоге много неразрешенных ссылок.... пикантность придает то что если системные либы не собирать с lto - все идет как по маслу и ничего не выбрасывается. в итоге мы имеем линковку собранных без lto системных библиотек с lto-"окученных" объектников прилагухи пользователя. кажется что мы что то теряем..... возможно но не факт. буду дополнительно исследовать. я же для себя выбрал иной путь - вся програмка это набор C++ кода, все либы суть есть хидеры в которых inline-имплементация нужyных функций и классов, и как можно шире шаблоны.... так уже реализована часть libc в виде хидеров... в моем наборе тулсов после сборки я я жеско выпиливаю все что связано с newlib., вместо libc libm - это тупо пустые либы затычки - реализации берутся из хидеров. получается вся прога компиляется из исходников... в таком подходе lto не дает сбоев - у него полная и наисвежайшая информация об символаи и коде. ЗЫ. для тех кому интересно сколько встроенных функций есть в gcc https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

ничего страшного. починим. проверю почему так. libm не использую, .. надо будет сделать набор тестов.

Свежак! наконец то починили заливку на сервак! какая всетаки гадость эта ваша рыба за... WebDAV по сравнению с старым добрым FTP..... хост linux64 http://klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_PLANTAGO.7z на этот раз релизный gcc 8.2.0 + мои муки на предмет оптимизации мультилиба и выпиливания исключений из libgcc(как обычно) собрал тулсы без использования avx инструкций хоста - предыдущий билд(собранный с avx) заработал не у всех из-за старых процессоров в компах. таргет - косяков не обнаружил, месяц все рабочие проекты собираются и работают. в ближайщее время планирую всунуть в мультилиб отдельно cortex-m0 с его вариациями (./+/small/fast multiply). предполагается изготовить девайс на stm32l011 - после беглого прочтения программинг маниакала сделал вывод что у этой серии микросхем ядро - cortex-m0+ fast multiply. то есть целочисленный умножитель параллельный 1 такт (НЕ последовательный как в ядрах cortex-m0+ small multiply), правильно? основанием считать я принял https://www.st.com/content/ccc/resource/technical/document/programming_manucoal/18/b4/a2/d9/87/cd/4f/18/DM00104451.pdf/files/DM00104451.pdf/jcr:content/translations/en.DM00104451.pdf PM0223 страница 10/10 ... providing high-end processing hardware including a single-cycle multiplier для масдая собранный из репозитория сегодняшняя ревизия host mingw64 http://klen.org/Files/DevTools/x86_64-kgp-mingw32/arm-kgp-eabi_@_x86_64-kgp-mingw32_20181201_PLANTAGO.7z я его не проверял - нечем. традиционно нет машины с масдаем.

hart вродебы подходит. еще 1-wire ds2480b рассматриваю. как то все равно либо дорого либо сложно либо с костыликами.., коряво. нет изящного красивого решения. нужно попробывать! спасибо.

хотелось бы питание +5...+12 вольт. если датчик имеет потребление порядка 0.1...0.3 мА в пассивном режиме - то можно продумать постоянный подзаряд питающего конденсатора и активная фаза ответа на запрос датчика при его срабатывании, тогда линии по 5вольтам может хватить (я так предполагаю) все таки меня не питание а схема сигнального интерфейса интересует, техасовские документы читал, но там все больше в сторону 220V/50HZ уклон (PoE) еслиьы не 7мм габарит платки датчика - то наверно проблем небыло бы особых - развязывающие трансформаторы....

здравствуйте! необходимо србрать датчики на двухпроводную линию до 500м. особеннось задачи - питать нужно от самой линии и всунуть в узкую 7 мм плату длинной порядкм 70мм. на ум приходять два дросселя и два конденсатора для фильтрации питания и сигнальных токов rs485. но это еще попробуй втиснуть.. может есть уже какие прверенные идеи, можно и не rs485.

по первому вопросу знаю почему так- собрал с поддежкой ivybridge + avx, поэтому и падает на младших процах, соберал для generic x86_64, выложу на днях, правда ровно в два раза медленне компиляция и линковка... ро второму тоже понятно, библиотеки криво разложил... опять же выложу потестите, косяг организационный... UPDATE пересобрал для generic x86_64 и ivybridge+avx...... потестил по отдельности (это как показывает практика - ничего не значит, у автора всегда все работает :)) FTP сдох - починю выложу на тестироване.

В общем отвечаю на собственный вопрос, возможно кому то пригодится. 1. девайс так делать можно. конвеер вн. ADC->DCMI->DMA->обработка буффера->MACDMA->PHY прекрасно работают. 2. скорость удалось по выходу ETHMAC получить 82MBit/s 3. удалось формировать длинный ( более 1500 байтов MTU ) и передавать буффер одним UDP пакетом ацп не прикручено - едет с маузера, но код думает что ацп висит на входах DCMI - то есть конвеер работает как будто АЦП нули выдает использовал Nucleo144-767zi, немного допилилил FreeRTOS-TCP в режиме с нулевым копированием (есть идеи как его немного поускорить). как докорячу интерфейс ETHMAC - выложу проект чтобы кто еще сеть не подымал - мог бы ее на этой плате хоть увидеть работающуу и потом переделывать под свое - ибо сделать работающий пример из CubaMX не удалось - пришлось чесно ручками много времени потратить.

да! накидал макет примерно такой же штуковины. ltc2206-14, работать буду на 50МГц . предварительная фильтрация/предобработка и выталкивание через ETH MAC - с выдачей непрерывного потока UDP пакетами. удалось протащить (правда без фильтрации - сырые данные с АЦП) в ETH MAC на скорости 82MBit/s что соответствует 82MBit/s/(16бит-размер слова АЦП) = 5MГц АЦП - получается типа сетевого AЦП реального времени,. Пинг правда перестает работать но тестовая прилагуха на РС принимает UDP пакеты c данными исправно. давно была у меня идея внешний АЦП через DCMI прикрутить - Ваш опыт показал что можно была сразу делать и не раздумывать.

здравствуйте! есть давняя покрытая мхом эротическая фантазия попробывать сделать датчик ( 14 битный АЦП 50Mгц -> DCMI -> DMA в буффер -> предобработка кадра -> ethernet UDP out ). кадр не видеоизображение, поэтому кадр маленикий. как бы предобработку допустим я успеваю делать пока свежий кадр набивается в память. А вот с ethernetom ничего не делал. если отрезать все лишнее и не нужное - тупо слепое устройство выплевывающее UDP пакеты - какую скорость можно получить на выходе?

здравсвуйте! а частота семплирования ацп какая?

SDIO может эмбеддедуу и ненужен, он нужен заказчику который мне этот эмбеддед заказал! нужно писать телеметрию изделия, а потом когда что то пекосо....лось в нутри оного изделия и оно со звуком ящика с гвоздямт стукнолось об землю - обосновано назначать виновптого :laughing: как я говорил, теперь попробую eMMC микросхемку запустить вместо сокет+карта. так выглядеть поприличнее будет, как мне кажется. у меня все заработало, но есть один вопрос - я в своем драйвере при выполнении обмена смотрю один блок или более одного нужно протолкнуть, если один то подаю команду одиночного обмена, иначе мультиблочного. пробывал мультиблочным один блок проталкивать - работает, при мультиблочном обмене по завершении необходимо подать команду терминирования обмена, в одноблочном этого не нужно. пробывал в мультиблочном эту команду не подавать, тоже работает. номера команд на память не помню, сорри.Почему оно одинаково работает, и зачем тогда два отдельных отдельных метода?

Здравствуйте! собственно сабж. почемуто у меня не работает ни в каких вариантах, наверно чтото не так делаю. с stm32f4 проблем нет.

дело в том что платы летают+вибрируют, и иногда с сильно ударяются об земную поверхность. опыт показал что sd-сокет на стационарных приборах допустим, а на перемещающейся в пространстве нет. на вибростенде проверяли - нарушение электрического контакта при вибрации. к тому же все надо покрыть лаком - и что? сокет проливать ? еще качество у сокетов от партии к партии разное.... я сам не видел, но коллеги говорят что часто встречают тупо припаянные sd-карты к платам без сокетов в девайсах подобного толка.

здравcтуйте. с помощью такой то матери дописал sdio->sdcard драйвер ( взамен НАL и libopencm3, т.к. использую свой самодельный SDK) попробывал выжать скорость чтения/запись. блоки читаются через DMA до максимального размера позволяющего эти модулем - 256к. stm32f405rgt6 168MHz шина sdio модуля включена на максимальноую скорость - делитель клока = 0 при записи на карту источником является флеш (т.е делается дамп прошивки и кладется на карту с последующей проверкой на большой машине правильности работы записи) с чтением посложнее - нет линейного куска памяти на запись размером 1M поэтому максимальый блок 96k - то что в своей тестовой програмке удалось отжать от системного стека, кучи и статических переменных карта Кингстон 16G class 10 UHS1 чтение SAMSUN 32G EVO Plus UHS1 какой то noname промаркированный class 4 выводы которые я сделал пока карячился с написанием драйвера. а) нужно обрабатывать все сотояния SDIO модуля и статусы SD карты, иначе можно залететь в куданибудь и зависнуть. SDIO стейт-машина ... б) как Вы видте при чтении и записи большими кусками все упирается в SDIO модуль - сорт карты не влияет на пиковую скорость, разница возникает толькана маленьких, но тут както нужно отделять время кода драйвера. с) FatFS дробит запросы на чтение и запись кратным 32 блокам(32*512 = 16k) поэтому она тоже ограничивает скорость (это согласовалось с результатами сырых измерений скорости довольно точно соответсвует 16к - тоесть FatFS выдал при линейной записи порядка 7-8Mb/s, а запись 6-7Mb/s) тут также нужно сказать что код самого FatFS при длинных линейных операциях практически не влият на скорость - что хорошо ( но на вид код у Чана - сплjшные макароны.... у нас за такое убили бы, закопали и табличку написали:)) д) FatFS можно поковырять на предмет увеличения батча записи/чтения более 32 блоков - вплоть до 512 ( 256k - то на что способна DMA со своим гребанным 16-битным NDTR недосчетчиком) е) кому надо наипобыстрей - писать руками в сектора без файловых систем - 10Mb/s как бы реальность. ё) провел "грязные игры с клоком" - клок шинного интерфейс sdio модуля тот же что и usb (48MHz) в доке написано что можно до 50.. попробывал потихоньку гнать множителем rcc.q - результат - скорость обмена пропорционально увеличилась, работает свплоть до множителя rcc.q=5 , при таком множетеле и раскачегаренном системном клоке в 240МГц скорость обмена на чтение достигла 20Мb/s, на запись ~15Mb/s. тут еще флешка наверно должна быть хорошей чтобы проканало как у меня. ... теперь будем плавно пробовать прикручивать eMMC микросхему - жизнь показала что sd-сокеты это для "бытовой" аппрптуры, разваливается и не контачит...

костыль.. модуль RCC специально для Вас имеет регистр в котором указан источник сброса, как раз для таких случаев.

спасибо! вроде заработало. тестировался на шести 2ГБ файлах на 16ГБ SanDISC uSD, читал начало и конец файла. использую крайний FatFS свой самописный драйвер (SDIO+DMA)->SDCARD как было сказано нужно обращать внимание на адресацию. в моем коде был косяг с умножением индекса блока на размер блока (512), до тех пор пока 32 бит хватало - работает, если файл лежал далеко за 2 ГБ все естественно читалось и писалось в неправильные блоки. еще нужно обратить внимание, что если не включать опцию FF_USE_EXFAT тип аргумента f_lseek - uint32_t и по большому файлу не полазишm даже если он есть. если FF_FS_EXFAT=1 то указатель позиции uint64_t ff.h: ... /* Type of file size variables */ #if FF_FS_EXFAT typedef QWORD FSIZE_t; #else typedef DWORD FSIZE_t; #endif ... настоятельно рекомендую использовать фичу FF_USE_FASTSEEK=1, без карты индексов FatFS итерациями в цикле индексы блокв индексирует. на маленьких файлах это не заметно. на больших все замедляется. http://elm-chan.org/fsw/ff/doc/lseek.html

Здравсвуйте! с флехами размером 4 гигабайта работает все хорошою с большими 16/32 и тд начинаются глюки. при отладке выловил в функции clst2sect что индекс сектора становится выше диапазона и FatFS вываливается с ошибкой FR_INT_ERR это я что то не так делаю или это не только у меня?