iamnot

Добрый день. Если еще актуально, то могу предложить свои услуги. Есть большой опыт как разработки плат средней сложности так и разработки программного обеспечения для мкироконтроллеров. Работаю в Альтиуме.

Как я понял, буй собирает данные о положении и пишет в память. Через какое то время его нужно отловить. Зачем ему приемник? Нужен только передатчик, который раз в 3-5 мин выйдет в эфир и передаст координаты. Или это по энергопотреблению больше чем все время сидеть в приеме?

На STM32F207 делал бутлоадер по UDP, IP был статический. Размер получился 15 520 Байт. LwIP 1.41. Попробуйте покрутить еще настройки, возможно удастся уменьшить размер.

А мое предложение во втором посте не о том же?

Если частота не меняется, то можно попробовать: D-триггер делит на 2, получаем прямоугольник 5кГц, затем раскачка на резонансный контур на 5 кГц.

Почему CM4F? По даташиту CM4, плавающая точка только программно делается, насколько я понял. Так что по сравнению с STM8 отличие только в частотах.

Нет, такой возможности нет. А зачем переводить во флоат?

С этим проблем нет.

Спасибо, помогло! Мля, так опростоволоситься.

Приветствую участников форума. Вопрос к знакомым со средой Visual Studio Code. Не удается запустить отладку контроллера из среды VS Code с плагином cortex-debug. Причем контроллер прошивается и что то даже исполняется, но при постановке на паузу VS Code не показывает точку где остановился. Такое ощущение что нет связи строк кода с иполняемым elf файлом.

Интересно как. Если в файрволе запрещен выход программы в сеть, то это плохой файрвол. По теме: Альтиум вроде бы шлет какие то запросы на 255.255.255.255 видимо ищет серверы по всему миру. Далее работает с конкретным адресом. ИМХО

Также есть среда разработки AT32IDE (Eclipse, GCC, GDB). Версия 1.0.01, пока сырая, но работает. По пинам многое из периферии совместимо с STM32. Некоторые корпуса/модели полностью совместимы по пинам. В документации много опечаток. По сравнению с STM32 документация скудновата.

Не уверен что там надо что-то крутить в недрах LwIP, так как разработчики следовали стандартам RFC. Да и слишком там много действий происходит от момента получения пакета до решения отправить ACK. Вот пример лога установления соединения на контроллере STM32F427. 475 49.207230 172.16.16.45 172.16.16.121 TCP 74 52946 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=1910788 TSecr=0 478 49.208751 172.16.16.121 172.16.16.45 TCP 62 80 → 52946 [SYN, ACK] Seq=0 Ack=1 Win=2144 Len=0 MSS=536 WS=1 479 49.208780 172.16.16.45 172.16.16.121 TCP 54 52946 → 80 [ACK] Seq=1 Ack=1 Win=65792 Len=0 480 49.208903 172.16.16.45 172.16.16.121 HTTP 538 GET / HTTP/1.1 От момента получения пакета на установление соединения до выдачи ACK чуть больше 1,5мс Может подумать в сторону увеличения размера пакета?

Могу ошибаться, но похоже вот тут pcb->rto = 3000 / TCP_SLOW_INTERVAL; pcb->sv = 3000 / TCP_SLOW_INTERVAL; файл tcp.c, строка 1901

Всем спасибо, нашел. Завтра должны выслать.