Comments 63
fillchar(DCB, sizeof(DCB), 0);
DCB.DCBlength := sizeof(DCB);
GetCommState(handle, DCB);
DCB.BaudRate:=speed;
DCB.Parity:=parity;
DCB.ByteSize:=8;
DCB.StopBits:=ONESTOPBIT;
DCB.Flags:=1;
SetCommState(handle, DCB);
"Вам шашечки или ехать?".
Проблемы устаревших интерфейсов, спорной или излишней оптимизации и тд, уже решена на основной работе так:
платится премия за продаваемые изделия, те которые разработал разработчик, до 25% с маржи (надеюсь понимаете, хотя бы это — что это минимум немало), а так же сопровождение клиентов и производства делает сам разработчик, и хоть заоптимизируйся, хоть строй "rocket science", никого не волнует.
Главное чтоб всё работало и не вызывало возвратов оборудования. Шансы повысить зарплату только один — сделать побольше качественных разработок, а как — никого не волнует, и тут уже предпочтение выдаётся тому коду который с 2004ого года стабильно работает везде, даже под вайном кстати ;)
на основной работе: связь, телеком, шлюзы, исдн е1, запись разговоров, оповещатели, STM32 + altera
хобби: умные гаджеты, стильные, стальные, со стеклом, без тормозов, да так чтоб батарейка месяц тянула, плавно интерфейс просто летал, при этом чтоб код без переделок компилировался как под мк и винду так и под веб, т.е. то чего нет даже у аппла, чем действительно стоит гордится и что нереально ахуенно. Но об этом хобби как нибудь потом
Целиком не планируется.
Моя первая статья про шлюз про старую схемотехнику, в ней есть ряд недостатков и ряд "маячков". Это такие закладки которые у специалистов сразу вызвали бы вопросы. Но только у тех кто знаком с темой моей статьи. Таким образом я хотел получить фидбек о том что кто-то знакомый с темой прочитал вдумчиво статью. Но они или не сработали или было им лень. Поэтому и упала мотивация продолжать кому-то, что-то про шлюз рассказывать.
Зато отлично сработал маячок на перфекционистов и прочих любителей придраться не поделу — я просто выложил до ката фотку платы с "топорной" разводкой — ну они и набежали.
В этой же статьи тоже есть "маячки", в том числе такие — это упоминания делфи, винапи, ну и до кучи я натянул манифест заставляющий даунгрейдить интерфейс до винды 98, хотя при запуске видно что используются фишки современной винды включая вин 7 которые видны сразу.
И уже нашёлся любитель покритиковать не глядя и не запуская ничего (извини чувак, честно извени, не хотел тебя аггрить).
А про будущие планы:
Я планирую начать потихоньку выкладывать технологии из шлюза:
- Например хороший и качественный помехостойки детектор модуляции бит в формате FSK, который используется везде в голосовой обработке, от АОН и DTMF набора, до детекторов тонов и полноценном модеме для диагностики шлюза.
- Так же планирую описать как минимум два способа расчёта нелинейных искажений и шума. Один из них очень вкусный — не использует FFT и можно запускать хоть на атттини и простой как валенок (но в рунете не встречал, вычитал на японском про него).
- Ещё можно расписать поподробнее про фильтры, в плане простой и надёжной реализации без потерь качества обработки звука и что многие считают фильтры неправильно и вносят немного но искажений и как этого избежать.
- Ну и можно выложить свои наработки компактного и грамотного парсинга АТ команд на скриптах подобных регэкспу.
- Можно рассказать о нововедениях и багфиксах предыдущей статьи про шлюз.
Если что то заинтересовало то пишите что, с удовольствием поделюсь как будет время и желание. Ну и запросившего можно наплюсовать чтоб я смог понять что больше всего заинтересовало.
извиняюсь. уже поздно. устал и невнимательно стал читать.
А про фильтры и способы расчёта искажений и шума без FFT я бы почитал.
что именно интересует? на что упор делать? на реализацию? кросплатформенность? или на метрологию (сравнение двух способов, и тд)?
могу в выходные написать. но времени не много (если будет) и поэтому объёма будет мало и смогу только что-то одно показать.
хех. Я изначально хотел выложить другой вариант загрузчика, GPRS размером в 10к, с всем лексическим феншуем: нормализатор одиночных символов, последовательностей символов, выделитель слов и фраз, преобразователь hex строк и чисел в значения переменных, с форматом похожим на регексп, очень простой в использовании. Ну и с толикой аппаратной чёрной магии когда аппаратура МК сама пишет в класс локфрии очереди.
Мне показалось всё это через-чур сложным и у меня проблемы с графоманством, да и разбить на несколько частей и выкладывать по частям тоже не удобно — быстро мотивация пропадает и забиваю посередине. Может привыкну к хабру и научусь нормально и кратко писать статьи тратя мало своего времени, тогда и опубликую и свои наработки.
Но есть вопрос: в чем проблема GPRS? я загрузчик делал как вспомогательный и особо на него времени не тратил, и случаев включения его было буквально пара штук клиентами и поэтому саму логику включения GPRS я не прорабатывал как следует.
Поэтому очень буду благодарен если поделитесь своими проблемами.
С GSM все сложнее. Мало того, что у разных производителей (не одним SIMcom мы живы) команды отличаются, так что самое важное — нет четкого способа отличить конец команды, служебное сообщение. Ну вот например, что я пытаюсь делать. Давно уже не писал — времени не хватает. Функция
bool Modem::wait_for_reply(CMD::ATCMD cmd, ATRESPONSE expected, word timeout)
https://github.com/Pugnator/CoreTex/blob/HAL/firmware/src/drivers/wireless/gsm/atcmd.cc
Это как-то работает, и то неоптимально. Но как быть при переключении в GPRS? Как отделять? как ждать.
Была бы статья. где на пальцах рассказывалось. как правильно ждать и обрабатывать AT команды, как ожидать ответа и прочее.
Описания команд есть в даташитах, да. Но многие команды не возвращают OK или вообще что-либо. А хардкодить — некрасиво и неправильно. Хочется нормального парсера. Не бизон же с флексом прикручивать.
больно уж долго он прошивает: около двух минут, особенно когда отлаживаешь схемотехнику, а не свой код.
При этом обычно вносишь минимальные правки и дольше ждёшь когда прошьётся, успеваешь отвлечься и тд.
Да и не дело терять за день более четырёх часов на прошивку изделия, притом что порой разработка длится не один месяц.
А почему нельзя использовать нормальный SWD/JTAG программатор?
- Чтоб прошивка не утекла мы всегда держим чипы залоченными. Залочка не просто отключает SWD, а при попытке обращения по SWD превращает чип в кирпич пока не выключишь питание.
- Он тоже далеко не 10 секунд прошивает, а в ряде плат на этих ножках стоят нехилые кондёры и SWD заведётся на очень маленькой скорости.
второй вариант,
но содержимое прошивки отправляется уже на стадии стирания до полного заполнения буфера (экономия ещё в 2 сек).
Но как стирание прошло начинается запись и по мере освобождения озу на мк, прога прошивки докидывает ещё данные и на этой стадии процесс идёт уже параллельно, мк прошивает и рапартует о том что до такого то адреса прошито и настолько занят буфер мк, и одновременно принимает новые данные, т.к. хост видит что сколько ещё можно дозакинуть.
Смотри на видео справа команду WR 0x080xxxxx yyyyy где 0x080xxxxx — адрес до которого дописал, и yyyy — сколько занято озу.
На видео же заметно что идёт рывок в начале (мк прошивает быстрее чем принимает новое), а под конец скорость падает.
сотая серия и четырёхсотая серия существенно различается по скорости стирания и прошивки.
Сотая серия как раз отлично работает с штатными, проблем с ней нет. В отличии от stm32F40x.
Как уже выше писали что программный усб далёк от совершенства, поэтому проще отдельную USB-UART микруху поставить.
Это всегда полезно и увлекательно пилить мозги таракана начиная
Я как раз таки даю очень взвешанные советы чтоб не вылизывали каждый байт и оптимизировали в целом, а только потом самые крупные и самые влиятельные на размер модули можно чуток подправить без уродования кода асмом и овероптимизацией.
2. Раз уж пошла такая песня. Почему не DMA? Он как раз для этих целей как никак лучше других справится.
3. И по поводу времени прошивки, позвольте не согласится. Время прошивки 32-битного поля у 405/7 почти в 6 раз быстрее чем у сотки. Время посекторного стирания у 405/7 — от 7 до 25 милисекунд/килобайт. У сотки тоже между 20 и 40 мсек/кБ. Единственное что значительно дает преимуществ — mass erase. Тут разница несоизмерима в пользу сотки.
1-2. Насчёт того почему функции в RAM и почему не DMA — это просто мой косяк и нежелание баг понормальному затыкать: я почти всё сделал но на 500кбод, почти всё протестировал и под конец решил макс скорость проверить и тут и заглючило, и опять вспомнил что встал на свои грабли — опять про время стирания флеша забыл совершенно. ну т.к. хотелось уже приступить и к статье и вообще больше 2 недель не тратить то просто закостылячил вынеся функции в RAM что существенно проще и быстрее. вот такой вот ляп и такой вот костыль.
3. хоть прошивается каждое слово и быстрее но их просто больше и постраничное стирание тормозит существенно — около 25-30 секунд, но надо его делать дважды из за локов и нашей политики безопасности (которую либо полностью соблюдаем, либо не мучаем ни себя, ни чип).
на новом HAL версии июль 2016, а не на старом SPL.
Пока без оптимизации по размеру (вышел в 12к)
и возможно не вся периферия деинициализируется правильно,
лучше быть внимательным.
если кому интересно, то могу опубликовать на гитхабе.
пишите или плюсуйте — мне интересно кол-во реквестов
вот опубликовал в вариант SFU для STM32F7xx
только сейчас руки дошли и довёл код до такого уровня чтоб показать другим было не стыдно.
Но для F745 вышло куда больше объём (11кб) т.к. используется офф. STM32 HAL без изменений,
потому что он сложнее чем SPL и его инлайнить и оптимизировать не самая хорошая затея,
а делать свой уровень аппаратной абстракции тоже сомнительно,
так-что пусть будет так — в первую страницу 16к влазит и отлично.
кроме того что стек указывает на рам, а точка входа на флеш, мне этого показалось достаточным, обычно никто даже этого не проверяет, ни JTAG ни SWD загрузчики ни стмовский встроенный не проверяют, просто запускают и всё.
Но если есть ещё способы и проверки, то мне интересно какие?
Если переданное CRC32 совподает с расчётной, то прошивка запускается, иначе возвращает в ПК ошибку.
Эта же команда выдаёт в ПК три 32 битных слова: с какого адреса, сколько байт, и их CRC32 расчётное.
Это сделано для логов и чтоб видеть что не сошлось, один байт или много или несовпадение адреса начала / кол-ва.
в логе команда утилиты ПК всё это наглядно видно
Но как я писал в статье я решал только проблему быстрой отладки схемотехники.
И поэтому в отладочной версии у меня есть код, который запускает её только один раз.
Второй запуск будет сразу остановом с миганием всех красных светодиодов и выдачей в терминал сообщения что это отладочная версия.
Поэтому проверка целостности не сделана именно при запуске по таймауту если обновление прошивки не началось — отладочная версия при повторном запуске всё равно работать не будет.
Для остальных случаев у меня есть остальные загрузчики: AN3155 с шифрованием, gprs, звуковой FSK модем — отсюда и возникла необходимость впихать в оставшиеся 5-6кб от 32к уместить этот быстрый новый. Отсюда такая раскладка памяти и получилась.
Здравствуйте!
Под какую IDE ваш проект?
FLASH_ProgramWord_inline(wr_addr, *data) — в каком файле у вас реализована эта функция? Что-то я ее не могу найти. В моем бутлоадере именно функция запиши флеш памяти блокирует время.
И еще, ваша программа FastTest.exe на моем экране 1080х1920 не помещается и меньше не делается, нет доступа к кнопкам внизу программы.
Version: Kepler Service Release 1
Build id: 20130919-0819
список плагинов
Eclipse IDE for C/C++ Developers
GNU ARM C/C++ Cross Compiler Support
GNU ARM C/C++ STM32Fx Project Templates
остальные плагины это украшательство, гитхаб, расчёт резисторов и таймеров, адаптер к кубу и тд
FLASH_ProgramWord_inline находится в src/cmsis_lib/include_inline/stm32f4xx_flash_inline.h
Поэтому я скопировал код использованных функций SPL в отдельный заголовочник, объявил их как static inline и добавил к каждой такой функции суффикс _inline, например GPIO_DeInit_inline. Так же заинлайнил все вызванные ими функции. Это сразу сократило код в разы.
А по сути это СТМовский SPL переделанный под инлайн, причины так же описаны в статье.
1080х1920? альбомная ориентация экрана и кнопки снизу не помещаются? извиняюсь, я не понял, можно скрин всего экрана?
насчёт блокирования флеша во время записи я так же в статье это отразил так:
При реализации приёма UART в прерываниях возникла проблема:
по умолчанию код находится во флеше и во время прошивки флеш памяти, шина флеша блокируется и исполнение останавливается полностью включая прерывания. И на скоростях выше 500к БОД это приводит к потере принимаемых из UART данных, т.к. время приостановки становится больше времени приёма байта. Поэтому функция обработки прерывания была вынесена в ОЗУ вот таким вот образом: ...
при этом обработчик прерывания уарта буферирует данные в озу, а пк сообщается размер буфера, пк обязан сам расчитывать кол-во записанных данных в этот буфер и следить за чтоб он не был переполненым.
Спасибо за ответ. Есть еще вопрос. Ваш способ прошивки годится только для F4 серии или для других серий тоже? На STM32F103 пробовали?
Мой (usb/uart) бутлоадер для L1 занимает 16K из 128K (12%) и пишет со скоростью 82 KB за 1:24 мин.
Сначала стираются все страницы, далее передаются блоки по 256 байт (страница), после записи и отправки подтверждения передается следующая страница. Снимается блокировка страницы один раз перед записью 256 байт и блокируется в конце. Вся задержка на 306 строке, если ее закоментировать, задержки нет. Эта одна команда (запись 32 bit во flash) блокирует программу на 233,7 ms / (256/4) = 3,7 ms.
Объясните, пожалуйста, как вы обошли аппаратное ограничение записи во flash.
То это я обошёл тем что закинул весь код в RAM. и код перестал быть зависимым от шины Flash
Насчет размера окна не правильно написал (1920х1080). Мой косяк, у меня на Windows 10 было включено масштабирование ярлыков 150%. Поменял на 100%, все помещается.
STM32F405: прошить 400кб за 10 секунд или быстрый UART-загрузчик заточенный под USB-UART, размером менее 4 килобайт