'У костра'

я в их беседах не участвовал, по коду подумалось что с ваншотом125 бага при силянии из двух источников, кто то делал колекторники и сделал третий енум, а там третим уже добавили ваншот125 а слили неглядя

if (_pwm_type == PWM_TYPE_ONESHOT125 && (_motor_fast_mask & (1U<<chan))) {

        // OneShot125 uses a PWM range from 125 to 250 usec

        pwm /= 8;

        /*

          OneShot125 ESCs can be confused by pulses below 125 or above

          250, making them fail the pulse type auto-detection. This

          happens at least with BLHeli

        */

        if (pwm < 125) {

            pwm = 125;

        } else if (pwm > 250) {

            pwm = 250;

        }

    }

Если можно пара идей - пожеланий.

возможно ли (может даже планируется) вынести все определения назначеия пинов в конфиг платы. тоесть нетолько шины, но и остальное, втч пвм выходы, ориентация датчиков.

примерно как визвестном проекте клинфлайт. польза будет в том что при добавлении кастомной платы не будет необходимости вносить правки в основной код, поддерживать такой проект будет проще.

и еще идея под добавление праты сделать скрипт, которому на входе передаешь тип проца, частоту кварца а он генерит необходимые для платы файлы и мэйк таргет

кстати в клинфлайте еще ништяк что все порты задаются не по номерам по названию  например PE5

этот подход упрощает создание своего конфига под новую плату

[2017-01-11 15:02:49] kozin писал(а): if (_pwm_type == PWM_TYPE_ONESHOT125

Посмотрел я все это безобразие внимательно.  Тут остается либо пытаться добиться отмены этого ужаса дабы HAL получал полный сигнал, либо ставить в настройках обычный OneShot  а в HALе уже игнорить в этом режиме все остальное и генерировать самостоятельно честный OneShot125. И второй путь явно проще...

по интервалам обновления ваншот удобно отслеживать частоту маин лупа. не смотрели осцилографом 400гц стабильно?

Испытал сегодня когнитивный диссонанс. Условия: 

Обработка прерываний от таймера, функция dispatch_general_h(). Если строку сброса флагов прерывания "dev->regs->SR &= ~dsr" расположить после всех вызовов "handle_irq()"  то все замечательно работает. Но если эту строку перенести перед вызовами "handle_irq()"  то не будет вызван ни один обработчик. Хотя казалось бы какая разница - установленные битовые флаги прерываний мы ведь уже получили!

 Однако если в любое место этой функции ДО вызова нужного обработчика поставить точку отладки то все самым магическим образом снова работает... Ничего не понимаю

Не понял. Тех что вызываются по ссылке как handler()? В них нет никакой проверки, все отдано в драйвер. И вобщем-то до них дело не доходит -  вызова обработчика не производится, брекпоинт на "blx Rn" не срабатывает пока нет брекпоинта выше.

Тут самый цимес вобщем-то в том что отладка влияет на исполнение программы... Таковое обычно говорит о временах, но каким боком оно к исполнению программы в проце?!

[2017-01-16 07:48:46] anprivate писал(а): А, хорошо

Что ж хорошего в том что кусок кода нельзя отлаживать пошагово?

[2017-01-14 20:50:32] night_ghost писал(а): Но не могу не удивиться режиму ULTRAPWM8х - от меня ускользает его тайный смысл... 

смысл в том что это режим совместим с ваншот125 по длительности управляющего импульса, но с регулируемым 400гц -3,3кгц, равномерным  периодом обновления, это дает возможность принимающей стороне (контроллеру мотора или высокоскоростного сервопривода) работать в синхронном режиме.

дублирование при помехе?

у дшота достаточно высокая частота сигнала, чем она выше, тем труднее защитить от помехи. допустим у сигнала дшот есть контрольная сумма , а смысл? несошлось - такт управления все равно упущен, до следующего такта петли измерения гироскопов и передачи имульса данных не будет. дшот думаю тоже надо нарисовать, зачем пользователя ограничивать в выборе

Последние новости:

• починен баг с RC_Output, все работает.
• сделан ремап между системными режимами PWM и реальными, сейчас вместо Normal включен OneShot, вместо OneShot - OneShot125
• сделана поддержка перезагрузки в DFU загрузчик через "reboot to PX4 bootloader" в МиссионПланнер
• также плата загрузится в DFU на следующую загрузку после любого HardFault и Panic()  - больше не надо добираться до платы если что пошло не так.
• сделана (но пока не протестирована как следует) поддержка второго PPM/DSM/SBUS приемника в режиме diversity
• внесены последние изменение из апстрима

Добавлена поддержка Failsafe приемника DEVO-RX719 (от Walkera-Aibao). На мой взгляд это сейчас наилучший RC приемник с модуляцией DSSS

Волей случая протестировал анонсированный ранее вход в  режим DFU после HardFault и Panic() - и ведь работает!

Без батарейного питания, даже без отвязанного накопительного конденсатора регистры BackupDomain сохраняют свое состояние больше секунды после выключения питания! Это открывает неплохие возможности повышения надежности контроллеров - как минимум хранить там флаг "мы заармлены" с калибровочными данными сенсоров, и при перезагрузке в этом состоянии отрабатывать какой-то алгоритм экстренного спасения.

Ага, ко мне такой уже едет Только вот он во-первых несовместим с Revo по ногам ибо SPI2 используется, и во-вторых жутковато спроектирован - две шины SPI использованы как внутри, так и выведены наружу, а все датчики питаются от того же 3.3 что и проц - со всеми шумами. Так что при его цене лучше взять оригинальный Revolution, еще и на ОСД останется.

Также не стоит забывать, что все рейсерские контроллеры напрочь лишены какой-то развязки от шумов STM32, оттого без доработки пригодны только для полетов вокруг себя - шумы процессора глушат радиоуправление, мой DSSS приемник потерял связь в ~300 метрах вместо привычных 2х километров.

И пикс лайт тоже пришлось экранировать (смотрим на цвет), но у него хоть свой корпус есть.