KnightIgor

Да, эта pdf-ка лежит у меня на диске. Ею я и руководствовался, когда разбирался с RL-FileSystem. Но там ничего нет (и быть не может) о stdio.

Спасибо за ссылку, но мы о разных вещах говорим. Там речь о "перенаправлении" в смысле поддержки новых (на тот момент, 2007) Cortex-M3 процессоров. Я это все знаю. Меня же интересовало внутреннее построение аппаратно-независимой библиотеки stdio и rtl, чтобы разобраться, почему вывод через _sys_write() странно обрабатывает строки с '\r', а также понять, как взаимосвязаны различные функции.

Сизифов - это когда несколько раз на одни грабли. Ссылочку бы... Это в том доке, по которому ныне на сайте ARM вкось написано серыми большими буквами "Superceded"?

Решение (но не глубинное понимание) найдено. Если кому интересно, слушайте сюда. Итак, хотим файловую систему RL-FlashFS из KEIL и вывод на терминал (в данном случае - через UART) по printf(). Вариант 1) - классический: 1.1) вносим в проект (возможно, предварительно скопировав их в каталог проекта) файлы File_Config.c и retarget.c из RL-FlashFS. 1.2) подключаем к проекту библиотеку FS_CM3.LIB (Cortex) или FS-ARM.LIB (ARM7). 1.3) имплементируем функции sendchar (и, возможно, getkey()), объявленные в retarget.c, реализуя передачу (и прием) символов через UART. 1.4) имплементируем функции доступа к носителю. Для SD карты через SPI, например, - это четыре функции, как описано здесь. 1.5) смотрим в помощь к RL-FlashFS и пользуем ее функции инициализации, ввода/вывода и другие. 1.6) пользуемся printf() для вывода через UART чего бы ни было на терминал. Все прекрасно за одним исключением: подсистема вывода на терминал странно обрабатывает строки, заканчивающиеся на '\r': в итоге строки-то выводятся, но с запозданием, словно подсистема выплевывает буфер либо только при наличии '\n', либо при переполнении. Применяем вариант 2) - модифицированный: 1.7) ко всему вышенаписанному в файл retarget.c добавляем: extern int $Super$$fputc(int c, FILE *f); // Original library function int $Sub$$fputc(int c, FILE *f) { // Patch if (f == stdout) return sendchar(c); else return $Super$$fputc(c, f); } Что такое "подкуп долларами", можно почитать здесь: Using $Super$$ and $Sub$$ to patch symbol definitions Что сделали? Переписали функцию fputc, отловили там вывод на терминал, но перенаправили все остальное в библиотечную функцию. Все работает как надо.

А, кстати о массовости: довольны STM32F? Какова статистика?

Вы с коллегой над одним и тем же экземпляром процессора измывались? Если нет, моя версия - STM32F103R8 на самом деле был STM32F103RB. Я сам пару раз накалывался, т.к., если процессор не свежаком из трубы, а из коробки с образцами, на маркировке "8" и "B" почти невозможно отличить друг от друга!

Привет форумчанам. Итак, имеем STM32F103RB, хотя в данном случае не принципиально, т.к. вопрос о функциях поддержки ввода-вывода (ключевое слово printf()) на консоль с одновременным использованием файловой системы FlashFS из RL-ARM 4.12 от ARM/KEIL. Чтобы дойти до сути вопроса, надо немного рассказать о предыстории и моем понимании понятия retarget. Информация черпалась из помощи, прилагаемой к uVision4 с ARM Tool Chain, и отсюда: RL-ARM Итак, хотим выводить на Hyperterminal с микроконтроллера. Для этого подсоединяем его UART к COM-порту компа, а в программе микроконтроллера используем printf(). Поскольку библиотека ARM не зависит о периферии конкретного камня, надо бы рассказать ей, что хотим посылать символы, "генерируемые" в недрах printf(), через, скажем, UART1. Для этого, как описывается в помощи и примерах, необходимо реализовать/перехватить функцию fputc(). Как правило, такой "перехват" помещается в retarget.c, а кто хочет стройный код, выделяет все, что касается UART, отдельно в файл serial.c. Примерно так: RETARGET.C ... #include <stdio.h> #pragma import(__use_no_semihosting_swi) // // To be implemented elsewhere (here - in Serial.c): // extern int sendchar(int c); extern int getkey(void); // ... struct __FILE { int handle; // Add whatever you need here }; FILE __stdout; void _sys_exit(int return_code) { while (1); // endless loop } // -------------------------------------------- // Reimplementation for printf() // int fputc(int c, FILE *f) { sendchar(c); } В SERIAL.C будет имплементирован sendchar(), который работает с железом UART1. Все получилось и работает, хотя вся эта муть с #pragma import(__use_no_semihosting_swi) и struct __FILE {...} мне до конца не понятна. Это был бы первый подвопрос. Теперь наступает следующий этап: хотим пользовать RL-ARM FlashFS конкретно с SD-картой на SPI. Смотрим RL-ARM и видим, что, якобы, все просто: 1). Копируем File_Config.* в свой проект, настраиваем File_Config.С 2). Используем SPI_STM32F103.c или пишем что-то свое для реализации функции spi_init (), spi_ss(), spi_hi_speed() и spi_send() (по сути аналог serial.c для UART1) 3). Подстыковываем библиотеку FS_CM3.lib 4). В коде вызываем finit(), когда SD-карточка вставлена, после чего... 5). пользуем файловую систему. Так вот, пока ограничивался finit(), ffind() и ffree() для посмотреть каталог SD-карточки и количества свободного места, все транслировалось, компоновалось и работало. Как только захотел что-то читать, то есть ввел в код обращения к fopen(), fread() и fclose(), компоновщик заголосил: Error: L6915E: Library reports error: __use_no_semihosting_swi was requested, but _sys_open was referenced А если взять из примера, приданого к RL-ARM FlashFS, реализацию этой самой функции со всеми там для нее важными определениями и заголовками, то компоновщику уже слишком много: Error: L6200E: Symbol _sys_open multiply defined (by sys_io.o and retarget.o). Хотя нигде sys_io.o в чистом виде не наблюдается, видать, в какой-то библиотеке сидит. Прошу совета и разъяснения. Заранее благодарен. Игорь.

Успокойтесь, - работали. Цыплят, как говорят, по осени считают, а результат - на лице. Если бы все было в шоколаде и без фейерверков, сюда бы не писали. Или? Кстати, об эффекте latch up слыхивать не приходилось? Это по поводу правильных состояний на выходах.

Как бы STM32 не был "заточен", он остается устройством с непредсказуемым поведением (жертва гибкости) и с перепрограммируемой периферией (неопределенность состояний). CSS лишь только сообщает о пропадании внешнего такта, после чего управление передается по немаскируемому вектору. Это если до этого дойдет вообще. Более вероятно, что ядро при воздействии помехи прыгает в никуда, и начинается непредсказуемая котовасия внутри и фейерверк снаружи. Механизм распознавания ситуаций, близких к критическим, предполагает незыблемость исполняемой программы и быстродействие на порядок выше помехи. Поэтому святая вера в "заточенность" микроконтроллера бесполезна, т.к. результат - фейерверк - был достигнут. Безусловно, включить механизм раннего распознавания критических ситуаций будет полезно. Хотя бы с точки зрения последующего анализа и протокола. И это сработает в 9 случаях из 10. Но я убежден, что существенное повышение надежности возможно лишь привнесением в систему компонентов с меньшей гибкостью и большей предсказуемостью (жесткая логика), что я и предложил ранее.

Кстати, еще идея: может быть макетке не хватало напряжения? Не знаю, как JTAG организован в Вашей системе, то есть, предусмотрено ли питание и от него наряду с "основным". Если основное питание сбойнуло, в какой-то момент USB порт мог уйти в ограничение тока (в правильных материнках и хабах на выходе стоят специальные схемы), и питание просело. Типичное проявление - не "флэшится", идут сбои, и т.п. Мой проф. в институте говорил в свое время: "вся дрянь - от источников питания". Применяю - спасает.

Совершенно согласен. Микроконтроллеры общего назначения не подходят для прямого и безопасного управления (предположительно) H-мостами, т.к. выходы портов могут принимать самые непредсказуемые значения, поскольку все конфигурируется программно. Необходимо вставлять жесткую логику перед мостами с блокировкой в ней нелицеприятных состояний. Не знаю, о каких напряжениях идет речь, но есть целый ряд HV драйверов (например, от IRF.COM или ST.COM), которые справляются с задачей, внося даже deadtime.

Наблюдал от случая к случаю подобное и у себя. С другим процем (STM32F или SILABS ) и другими USB JTAG/С2 адаптерами. Пересоединением USB приводилось в норму.

Глянул и обнаружил, что уже 9 скачиваний архива с поддержкой календаря. Работает?

Я тут под впечатлением этой темы покрутил свою отладочную MCBSTM32 и накропал поддержку календаря с использованием счетчика RTC. У меня проблем с годом нет. Аппаратно-независимая часть выделена мной в HAL_Calender.*, что и прилагаю. Разработано с использованием time.h из RTL библиотеки KEIL. Ориентировано на немецкие дни недели и европейский счет дней с понедельника. Установить #define LOCALE_US, чтобы полагать, что первый день недели - это воскресенье, или можно переработать нафиг всё под свой вкус. Calender.zip

Присоединяюсь к Fktrctg по поводу обнуления регистров периферии перед инициализацией. Для того и есть функции DeInit в библиотеке.

Чтобы мне сюда не повторяться, глянь сообщение в другой ветке. Может поможет. 1. Организовать обработчик прерывания от DMA по окончании передачи (по биту ххх_IT_TCn). Там ЗАПРЕТИТЬ канал DMA. 2. Как только назреет очередная порция, вновь загрузить в канал DMA регистр адрес указателя на источник данных и счетчик и РАЗРЕШИТЬ DMA. Он и рванет по-новой. В коде у меня это выглядит примерно так (речь у меня об SPI, потому DMA1_IT_TC3, но и в UART работает аналогично): //обработчик прерывания от готовности DMA DMA_ClearITPendingBit(DMA1_IT_TC3); DMA_Cmd(SPI_DMA, DISABLE); ... //конец прерывания ... //запуск очередной передачи SPI_DMA->CMAR = (uint32_t)src; SPI_DMA->CNDTR = cnt; DMA_Cmd(SPI_DMA, ENABLE); // понеслась... Если ты передаешь байты через UART (а не 9-ти битные полуслова, к примеру), то зачем тратить память на массив из слов, если в таковых только байт и используется?Или имеется что другое в виду?

Ключевое слово: "под отладчиком". В STM32F по умолчанию периферия продолжает "тикать" в реальном времени, пока происходит останов под отладчиком или пошаговые прохождения по программе. Чтобы остановить периферию (в твоем случае - Таймер), необходимо установить при инициализации системы нужный бит в узле отладки, что можно сделать либо библиотечной функцией: DBGMCU_Config (DBGMCU_TIM3_STOP, ENABLE); // stop timer3 while debugging либо на "регистровом" уровне программирования: DBGMCU->CR |= DBGMCU_TIM3_STOP; Конечно, внешний измеряемый сигнал остановить нельзя, но под отладчиком, по крайней мере, не будет выбега таймера.

Основные производители Cortex-M3: NXP TI/Luminary ST ATMEL Energy Micro У всех есть селекторы с фильтрами по тем или иным параметрам. У кого внешняя шина EBI :07: называется, у кого еще как. Это надо смотреть, и прежде всего на корпуса от 100 ножек и более.

Спасибо, Sujan, получил! За чем я, собственно, охочусь: мне нужна поддержка симуляции F5xx серии (F531A в частности) контроллеров Silabs. Однако и присланая версия еще не поддерживает эту серию, хотя датирована 2009 годом. Кстати, что DLL поддерживает, легко установить, и не запуская Keil: достаточно поискать в файле строки типа CYGF300, и т.п., то есть те ключи, которые задаются в настройках проекта в закладке Отладка, в строке параметра диалоговой DLL. Я уже и на форуме Keil пошерстил: тишина. Конечно, Silabs'ы и на железе отлаживать удобно благодаря C2 интерфейсу, но хочется и быстро прогнать алгоритмы на симуляции, без железа. Прошу еще раз всех владельцев Keil глянуть в свой подкаталог \keil\c51\bin на наличие DCYG.dll версии старше 2.66 и прислать мне файл на мыло coldweather at mail.ru. Заранее благодарен!

Я тут с разными Cortex-M3 вожусь, и не могут вспомнить, касалось ли это LPC17xx, но где-то было предостережение об использовании JTAG ног в пользовательской программе в качестве портов: нарушает работу JTAG, возникают проблемы соединения...

Под отладчиком смотрел, какие значения и куда грузятся: все красиво.

Про Украину не скажу, но и на Западе напряг с микроконтроллерами, да и вообще со всеми компонентами: последствия кризиса. conrad.de сообщает, что ATSAM3S4CA-AU QFP 100 будет поставляться с 05.01.2011 (CONRAD.DE - SAM3S). Ой ли...

Привет всем! DCYG.DLL используется для симуляции микроконтроллеров SiLabs С8051Fxxx под оболочкой KEIL (uVision 3). У меня версия 2.64 этой DLL, и нигде не могу найти более актуальную, ни на сайте Silabs, ни у КЛИНА (KEIL в переводе - клин B)). Может кто поделится мне своей на сюда: coldweather AT mail.ru?

Вопрос я себе тоже задал, но нигде не нашел упоминания о запрете доступа для PDC (PDC - это DMA, жестко связаный в SAM3x с той или иной периферией) к той или иной памяти. Пробовал указывать на буфер как во Flash, так и RAM. Результат тот же: выплевываются только нули.