'У костра'

Скетч выложен https://www.dropbox.com/s/3gl8cpops8i1m0i/sbus-170531a.zip?dl=0

При запуске все каналы 1024

Команда по softserial  на 57600 8n1 в формате

channel_number=channel_value<CR>
  channel_number - 1..18
  channel_value - 0..2047
 Заточено под teraterm, поэтому внутри есть echo и концом строки является <cr>

Где и что крутить?

Что-то я напортачил. Случайно включил какой-то параметр в разделе HAL. Теперь после перезагрузки просто не поднимается - даже светодиодик не загорается. Прошивка старых прошивок не помогает 8-O  Что это может быть?

Брр. Вообще нет параметра RC_INPUT. Билд же правильный залит?

APM:Copter V3.6-dev (7fb40435 2017-05-31 14:42:33+

Хм. Может что-то где-то не так делается... Так как ситуация была описанной точно.

Может проблемы связаны с прошивщиком. Дело в том, что под виндой я пользуюсь двумя утилитами DFU File Manager и DFUSeDemo. Первая из hex делает dfu, а вторая прошивает этот DFU в камень. Может что-то где-то работает не как предполагается?

[2017-05-31 14:27:57] night_ghost писал(а): по некому размышлению, если тулзы слишком умные и пытаются FF-ы не шить то может случиться что да, они эти страницы не трут и не шьют.

Там есть соответствующая галочка, но я её обычно снимаю, то есть должно литься всё.

dfu-itil есть и для винды, но у меня она почему-то не работает

Cannot open DFU device 0483:df11
No DFU capable USB device available

А с виртуалкой очень не хочется связываться

утилита командной строки для винды - https://hackaday.io/project/4139-stm32-dfu-file-converter

PS. какой VID:PID у камня в DFU режиме? Добавлю генерацию файла DFU при сборке.

Ага.HAL_RC_INPUT=

0 - всё по старому

1 - после включения ch3=900, ch15=256, остальные 0. При подаче SBUS ch3=900, ch11=54611, ch12=1, ch15=274, остальные 1514

2 - после включения ch3=900, ch15=512, остальные 0. При подаче SBUS никакой реакции

3 - после включения ch3=900, ch15=768, остальные 0. При подаче SBUS никакой реакции

4 - после включения ch3=900, ch15=1024, остальные 0. При подаче SBUS ch11 непрерывно инкрементируется примерно на 700 единиц в секунду, ch12 инкрементируется в момент переполнения ch11, ch15=1042, остальные каналы 1514 (как и должны, по всем каналам идёт 1024). После снятия SBUS ch9=900, ch11/12 тикать перестают.

Дальше цифры пробовать?

Уже по этим наблюдениям видно, что на старший байт 15-го канала каким-то образом накладывается тот самый HAL_RC_INPUT и на старший байт 11-го канала и младший байт 12-го канала накладывается какой-то счётчик.

Все, поймал виновника - массив overrides был размером 8, а проверялся по всем возможным каналам. Пересобирается.

UPD. готово

Coool ! С ардуинкой тоже наблюдается Эффект есть при установке первого канала ровно на 1807 При этом на выходе в mission planner должно быть 2003? а в реальности всё просто сходит с ума. Очевидно, что проблема связана с некорректным определением стартового байта - при таком значении последовательность выглядит вот так:

0x0F,0x0F,0x07,0x20,0x00,0x01,0x08,0x40,0x00,0x02,0x10,0x80,0x00,0x04,0x20,0x00,0x01,0x08,0x40,0x00,0x02,0x10,0x80,0x00,0x00

Похоже декодер принимает ВТОРОЙ 0x0f за начало последовательности и всё сходит с ума.

Хм, странно - у декодера есть синхронизация и по времени, и по длинне пакета, так что со второго байта ну никак... Сейчас эту последовательность посмотрю в деле.

UPD. после успешной обработки пакета счетчик байтов не сбрасывался. Также сделал временнЫе ворота поуже - 3.5мс вместо 5,  пересобрал, можно проверять.

А, нет. Принимает один пакет и всё, больше ничего не принимает.

Не, то же самое - видно, что после подключения он корректно ловит один фрейм sbus, показывает значения и дальше уже ничего не декодирует.

пока боролся с SBUS - пришла мысЕль. Пока делал ее - попалась статья в тему. В результате - анонс

• для выходов на моторы компенсируется неточность установки частоты таймером
• добавлен отчет о исползуемой памяти  - кучи и стекам
• выводится отчет о ошибках шины I2C
• попытка уменьшить потребление и шум, добавив остановку процессора во время безделья на WFE, TIMER6 используется для пробуждения каждую микросекунду
• длительные операции вынесены из обработчиков прерываний в низкоприоритетный обработчик завершения ввода-вывода - IO_Completion level
•  добавлена поддержка Clock Security System - если кварц останавливается (или отваливается) в воздухе то происходит переход на внутренний генератор.
• добавлен обработчик boardEmergencyHandler который будет вызван при любом аппаратном сбое или при Panic() перед остановкойt - например для выпуска парашюта

Пока на отладке, скоро будет.

[2017-06-02 12:33:46] m-s писал(а): А магические -O0 ещё нужны?

в тех местах где нужны они есть принудительно, есть также магические -O2 в некоторых других местах