EugenyAM

Можно подробнее рассказать про это?

Если модуль будет иметь диагностику приколов оператора - это плюс ему. хотелось бы иметь адекватную диагностику ошибок подключения к серверу, разрыва TCP соединения. Самое главное - это быстрое восстановление связи, после устранения проблем в сети. т.е. если проблем в сети оператора нет - устройство всегда на связи. На M10 кроме всего прочего наблюдаются тотальные потери сообщений от сервера через некоторое непостоянное время работы. При этом от модуля на сервер данные доставляются нормально. Может работать сутками нормально, может через несколько минут после соединения не получать ответы. TCP соединение (гарантирующее доставку по определению) при этом остается активным. M10 может выдать CONNECT OK при подключении к физически отключенному серверу. Почему-то к телефонам это не относится... Работают везде и не только с большой тройкой. А что применяется, например, в банкоматах, карточных и платежных терминалах?

Требуется надежный проверенный временем и пространством (SIM, регионы, операторы) модуль для организации канала GPRS. География работы устройств - вся территория России, условия - уличные, стационарные. требуется надежная работа со всеми операторами большой тройки с любыми типами SIM-карт. Модуль должен иметь перспективу выпуска лет на 5... Применяли Telit GM862, сейчас поставки прекращены. Пробуем Quectel M10 - выясняется, что он может вести себя неадекватно с разными SIM-картами в регионах. Работающая "дома" программа в новом регионе преподносит новые сюрпризы. Собирать статистику проблем в каждом регионе нет возможности. Нужно приехать, вставить SIM-карту, включить устройство и убедиться, что оно вышло на связь. т.е. если модуль работает в Омске на МТС, он должен работать точно также в любом регионе России, хотя бы со всеми операторами большой тройки.

скорость 115200 кбит достаточно. Расстояния, в пределах действующих линий ГТС (если абстрагироваться от ADSL, то как всегда, надо покрывать весь город из одной точки) Нужно подключаться к инфраструктуре интернет-провайдера по ADSL, оптики нет и платить за прокладку никто не будет, пока провайдер сам не протянет ее везде и не объявит глобальный переход на нее. (точек в одном городе может быть несколько десятков) Радикально менять инфраструктуру тоже не представляется возможным, конечные точки расположены не в зданиях, платить за помещения для дополнительного абонентского оборудования тоже никто не захочет. сейчас ставят бытовые ADSL-роутеры D-Link, которые зависают в жару, мороз и просто без причин.

Радиоканал, GPRS, Ethernet... в зависимости от финансовых возможностей заказчика и наличия провайдеров с необходимой зоной покрытия

Подскажите, есть ли что-нибудь простое и доступное для организации встраиваемого ADSL-клиента? По аналогии с готовыми модулями GPRS и Ethernet. Интерфейс с МК может быть UART/SPI (если есть встроенный TCP/IP стек) или MII/RMII. Доступность подразумевает возможность приобретения в количествах от сэмпла до сотен штук, отсутствие проблем с документацией и приобретением необходимой обвязки. BGA/QFN не приветствуется.

Все рассуждения верные, как конкретно настроить в кейле не знаю, по аналогии с IAR надо смотреть опции линковщика. Надо изменить начальные адреса FLASH и Intvec на начальный адрес программы. В самой программе не забыть первым действием установить новый адрес таблицы векторов, я про это уже говорил. NVIC_SetVectorTable(NVIC_VectTab_FLASH, USER_PROG_OFFSET);

кстати, в списке легальных VID очень много китайцев... Но вот удивило отсутствие такого "зубра" электроники и музыкальных гаджетов, как Korg... не думаю,что у них все MIDI устройства эмулируют FTDI... Yamaha и Roland в списке присутствуют...

В начале бутлоадера проверяем признак его запуска (это может быть состояние Option Byte или бита в регистре Backup Domain, далее, если не надо его запускать, идем на основную программу с неинициализированной периферией, если надо - инициализируем периферию, пишем прошивку, сбрасываем признак запуска и делаем NVIC_SystemReset(), который выкидывает нас снова на старт, но уже со сброшенным признаком запуска. Если память надо чистить для конфиденциальности или приложение написано на асме, тогда ничего лучше записи чего-нибудь в цикле не придумать. (Может быть DMA?) Если приложение на Си самостоятельное, не является частью проекта бутлоадера, то компилятор пропишет в стартовом коде все инициализации переменных. Глобальные и статические переменные автоматом обнуляются до вызова функции main(), если они явно не инициализированы в программе, поэтому ничего страшного для программы при старте из бутлоадера не должно произойти.

Пример под IAR, компилировал на 6.21. __disable_interrupt() объявлена в intrinsics.h Под другие компиляторы примеры есть в AN2557

Все лежит на сайте ST Описание AN2557 Примеры AN2557

Если приложение скомпилировано для загрузки с адреса 0x8010000, по этому адресу будет размещаться таблица векторов. Вектор Reset находится по смещению +4, но это не точка входа, а указатель на нее. Поэтому нужно достать адрес из таблицы векторов и уже его присвоить указателю на функцию. Смотрим проверенный пример от ST: #define ApplicationAddress 0x08010000 //Начало нашего приложения typedef void (*pFunction)(void); pFunction Jump_To_Application; uint32_t JumpAddress; if (((*(__IO uint32_t*)ApplicationAddress) & 0x2FFE0000 ) == 0x20000000) //Проверяем, есть ли что-нибудь по адресу (там должно лежать значение SP для приложения, его кладет линкер) { JumpAddress = *(__IO uint32_t*) (ApplicationAddress + 4); //Адрес перехода из вектора Reset Jump_To_Application = (pFunction) JumpAddress; //Указатель на функцию перехода __set_MSP(*(__IO uint32_t*) ApplicationAddress); //Устанавливаем SP приложения Jump_To_Application(); //Запускаем приложение } while(1); // Если приложение не записано, Watchdog вернеет нас на начало бутлоадера В приложении переносим таблицу векторов, ведь мы приходим сюда с активной таблицей векторов бутлоадера и первое же прерывание выкинет нас в обработчик бутлоадера, если он определен, а если не определен, то возможен переход неизвестно куда и его следствие - HardFault. void main(void) { __disable_interrupt(); // Запрещаем прерывания NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x10000); //Адрес таблицы относительно начала Flash ... } Ответы на все вопросы лежат в примерах из AN2557

Хочу привести несколько рекомендаций, основываясь на собственном опыте, как не наступить на грабли при написании связки бутлоадер-приложение. 1. Перед переходом на приложение запретите прерывания. 2. Если разрешен Watchdog, задайте его период "с запасом" и перед переходом на приложение вызовите IWDG_ReloadCounter(); 3. Если бутлоадер использует USB, не забудьте выполнить USB_Cable_Config(DISABLE); 4. Отключите устройства, которые не используются приложением, если такие есть. 5. В приложении первым действием задайте новый адрес таблицы векторов, затем проинициализируйте WatchDog и только потом разрешайте прерывания. После Reset, инициированного Watchdog'ом или после прошивки по JTAG, STM32 стартует с текущей таблицей векторов, т.е с начала приложения. Поэтому приложение в общем случае не должно знать о существовании бутлоадера и о том, какая периферия уже была включена и настроена. В приложении лучше сделать все заново. 6. STM32 XL-Density имеют два банка Flash по 512К, расположенные с одного и того же адреса. Какой банк будет подключен после Reset, задается в Option Byte. Этот механизм можно использовать для хранения двух версий прошивки, скомпилированных с одного начального адреса. При этом, бутлоадер нужно продублировать в каждом банке.

В функциях EPx_Callback используются вызовы rtos? Эти функции вызываются из дебрей обработчика прерывания USB. Если используются, лучше, как было сказано скопировать данные в свой буфер или очередь и поставить флаг по приему данных

У STM32F102, STM32F103, STM32L - нет (только через UART) У STM32F105/107, F2xx, F4xx - есть DFU bootloader Подробности тут

Ethernet контроллер STM32F107 + PHY ST802RT1 + LwIP, прямое соединение кабелем с сервером. При переключении сетевой карты сервера в различные режимы наблюдается картина: 100 Mb / Full - обмен есть 100 Mb / Half - обмен есть 10 Mb / Full - обмен есть 10 Mb / Half - обмена нет PHY в режиме автосогласования корректно определяет все режимы, далее производится запись битов FES (FES=1 - 100Mbit) и DM (DM=1 - FullDuplex) в регистр ETH_MACCR по результатам автосогласования. Замечено, что если MAC сконфигурирован на FullDuplex, то обмен нормальный, при любых вариантах Full / Half на сервере при соответствии скорости сервера и MAC. Вопрос - почему так происходит и как с этим бороться?

У STM32 могут быть разные даташиты на МК одного семейства, но с разной density. В свое время были раздельные даташиты на семейство F103 Один документ - STM32F103x4, STM32F103x6. Второй документ - STM32F103x6, STM32F103x8, STM32F103xB. Третий документ - STM32F103xC, STM32F103xD, STM32F103xE. Естественно, что выводы SDIO описаны только в третьем документе. Возможно, что для семейства STM32L151 существует аналогичное разделение даташитов.

В отличие от AVR fuses, у STM8 запись в Option Bytes доступна из программы. Достаточно сделать в своей программе при старте проверку на разрешение Bootloader и если он запрещен, записать в Option bytes нужные значения. Также можно включить и альтернативные функции. Изменения в Option Bytes актуализируются только после Reset. Проверено на STM8S105. У него тоже бутлоадер по умолчанию однократный.

Задача использует для своей работы две области ОЗУ - структуру TCB и стек задачи, а также, собствено функцию задачи ,которая размещается во флеш при компиляции. Указатели на эти три области памяти передаются функции tn_task_create. Теоретически никто не мешает выделить память под TCB и стек динамически перед вызовом функции создания задачи. Если куча находится не на стеке, (в IAR вроде бы она лежит в отдельном сегменте) - все должно сработать. Если речь идет о загрузке кода функции в ОЗУ и объявления его задачей - тоже подводных камней не видно (хотя сам не проверял). В описании функции задачи отсутствуют какие-либо специальные макросы и определения - она не отличается от обычной Си-функции void func(void). Для ее работы должно выполняться два условия - бесконечный цикл и хотя-бы один системный вызов внутри него (например tn_task_sleep или tn_event_wait) - без него программа зависает. В любой момент задачу можно остановить и удалить из списка. Задача может быть остановлена и удалена как другой задачей (tn_task_terminate, tn_task_delete), так и сама собой (tn_task_exit, если нужно, с опцией TN_EXIT_AND_DELETE_TASK). Имхо, все сделано "по взрослому, но без излишеств". Насколько я помню, в uCOS/II задачу можно было остановить только из самой себя.

Когда-то делал на AVR асинхронный обмен по 1-wire через регистры сравнения таймера. Таймер тактировался частотой 1 МГц, что давало разрешение 1 мкс, в первый регистр сравнения записывалась длительность задержки в зависимости от того, что нужно было сделать - передать 0, 1 или прочитать шину, во второй - общая длительность бита. В обработчиках прерываний по совпадениям делались все ногодрыги и переключения режима пина ввод-вывод. Во втором обработчике производился также запуск следующего цикла. Алгоритм строился по принципу конечного автомата. В основной программе достаточно было запустить измерение и дождаться результата. Параллельно опрашивалось 4 датчика. Значения для таймера настроил по осциллографу с учетом времени входа в обработчик прерывания и выполнения команд в нем. Думаю, что для STM32 можно применить такой подход, несколько его модернизировав, в том числе, с использованием для передачи битов режим таймера с аппаратной генерацией ШИМ, или записав в 4 регистра сравнения фиксированные значения (t0, trd, t1, tbit), разрешать соответствующие прерывания в зависимости от состояния конечного автомата. Возможно, что скоро придется это сделать...

Контроллер Ethernet STM32 имеет аппаратную поддержку протокола синхронизации времени по сети IEEE1588. На сайте ST есть пример проекта с демонстрацией этой функции.

Больше года использую TNKernel под ARM7, полгода под Cortex M3. Использовал все фичи, кроме выделения буферов памяти. Граблей пока не обнаружено. Недавно начал писать набор макросов для быстрого создания задач, семафоров, событий с наиболее часто используемым набором параметров. С данными макросами легко можно будет перейти на другую ОС в случае необходимости. На тот момент, когда стояла такая же проблема выбора, у FreeRTOS не было примеров для ARM7 под IAR, у TNKernel они были и запустились сразу и без проблем - это и стало причиной выбора. Под Cortex M3 пришлось немного допилить проект для совместного использования с последней StdPeriferialLibrary и IAR 6.21. Еще где-то на форуме видел бенчмарк по переключению контекста для различных ОС - TNKernel в числе лидеров. TN-Net пока не пробовал, пока экспериментирую с LwIP.

А программа прошивается во Flash? Указанный эффект может наблюдаться, если программа загружена в RAM. Если пользуетесь IAR, проверьте галочку "Use flash loader" в опциях Debugger'а

Успешно использую в проектах на LPC2478 и STM32F103 виртуальный COM из тех самых примеров... Правда все это прикручено под ОС TN-Kernel с использованием очередей. Видимо придется писать статью про то, как с этим работать, учитывая проявляющийся интерес. Под LPC2478 была реализована библиотека последовательных интерфейсов на 4 UART и 1 VCOM, причем обращения из программы унифицированы и все равно с каким портом работать - виртуальным или реальным.

Здесь логика работы похожа на работу с UART по прерываниям, только прерывание нужно обрабатывать не на каждый байт, а на буфер конечной точки из 64 байт. Колбеки - это и есть обработчики прерываний, только "отсортированные" по событиям для удобства пользователя. CDC_BulkOut() - обработчик прерываний приема (Out - относительно хоста) CDC_BulkIn() - обработчик прерываний передачи Запуск передачи производится в функции VCOM_Serial2Usb() вызовом USB_WriteEP(...), после этого, если у нас передается меньше 65 байт, в колбеке CDC_BulkIn() надо остановить передачу установкой признака CDC_DepInEmpty = 1, иначе продолжить передачу. Прием полностью происходит через колбек CDC_BulkOut. Чтобы порт на машине появился, не забываем про инициализацию в начале. USB_Init(); // USB Initialization USB_Connect(TRUE); // USB Connect while (!USB_Configuration); // wait until USB is configured