'У костра'

[2017-11-10 12:31:26] night_ghost писал(а): все части HAL теперь собираются с оптимизацией -O2, что заметно УМЕНЬШИЛО место

Я бы попробовал собрать все с -O2 и -flto, ещё больше уменьшит бинарник, мне кажется. 

[2017-11-10 14:11:48] m-s писал(а): Огонь.

там куда не залезь, так "чем дальше в лес тем толще партизаны". От некоторых открытий аж плющит, да. А потом "а почему время цикла у вас такое плохое?"

UPD. Бинарники готовы

[2017-11-10 20:10:22] night_ghost писал(а): UPD. Бинарники готовы

Попробую вечером. Должно помочь, в px4 как-то же работает.

Если не поможет , выпилю этот блок, который сообщения дропает.

[2017-11-11 12:12:49] m-s писал(а): Если не поможет , выпилю этот блок, который сообщения дропает.

не надо, лучше тогда попробовать увеличить буфер передачи до килобайта

[2017-11-12 05:44:37] m-s писал(а): починилось!

Вот и ладушки.

В качестве промежуточного итога - бонусы отказа от ОС.

Код Ардукоптера для Пиксхока перевалил за мегабайт и перестал лезть в память старым версиям процессоров. Все платы семейства Revolution сотоварищи имеют тот же самый мегабайт, вот только даже у Ардукоптера последней версии со всеми плюшками в виде OSD и USB MassStorage остается еще 145кб свободного места.

PS, что на данный момент меня расстраивает больше всего, так это снижение точности в канале выхода на моторы: все расчеты ведутся во флоате, а затем преобразуются к историческому диапазону 1100-1900 (всего 800 шагов) и в таком виде передаются в HAL. Тогда как разрешение современных ESC составляет 2000 шагов, и логичнее было передавать в HAL именно Float значение, дабы он уже сам разбирался с управлением моторами.

[2017-11-14 05:31:55] night_ghost писал(а): В качестве промежуточного итога - бонусы отказа от ОС. Код Ардукоптера для Пиксхока перевалил за мегабайт и перестал лезть в память старым версиям процессоров. Все платы семейства Revolution сотоварищи имеют тот же самый мегабайт, вот только даже у Ардукоптера последней версии со всеми плюшками в виде OSD и USB MassStorage остается еще 145кб свободного места. 

Кажется это давно не новость)

[2017-11-14 11:02:58] night_ghost писал(а): Что именно "это"? Что не лезет или что места еще много?

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

И да, пару лет уже даже китайцы с нормальным 2мб процессором продают.

[2017-11-14 11:29:14] m-s писал(а):  Когда несколько лет назад про то, что второй мегабайт нельзя использовать, узнали - тогда уже где-то 800кб прошивка была.

Дык в том-то и дело что 3.4 лезла, а вот последняя уже перестала, даже с установленным по умолчанию флагом MINIMIZE_FEATURES. А TYT все еще лезет несмотря на кучу дополнительных фич.

[2017-11-14 11:38:20] night_ghost писал(а): А TYT все еще лезет несмотря на кучу дополнительных фич.

Отлично. Надеюсь маинстрим не увеличится в ближайшее время ещё больше )

[2017-11-14 12:12:55] m-s писал(а): В целом большие буферы тоже плохо - латентность канала увеличивается

отчего ж увеличивается? Я не использую принудительное наполнение, обработка/передача начинается по первому доступному байту, так что с латентностью все в порядке.

[2017-11-15 05:00:00] night_ghost писал(а): Без осциллографа никак

Spi прослушивать ? Тогда скорее логический анализатор нужен.

[2017-11-15 07:41:09] anprivate писал(а): Купите китайский клон Saleae Logic16

Уже заказал, едет.

[2017-11-15 06:54:27] m-s писал(а): Тогда скорее логический анализатор нужен.

Одно другому не третье, логическим анализатором завалы фронтов не посмотришь. 

UPD. А именно они и были (скорее всего) одной из причин что для SPI ранее требовалась оптимизация -O0, ибо выводы CS настраивались по умолчанию на скорость 2МГц. Второй причиной была необходимость дожидаться окончания передачи последнего байта, и выдерживать интервал до снятия CS.

[2017-11-17 07:53:26] m-s писал(а): Ах вот оно что.

Это только рабочее предположение, ибо я как-то упустил точный момент когда именно оно перестало капризничать, но таки именно такие изменения были непосредственно перед запуском SPI через DMA. 

Меня больше всего расстраивает что железо SPI в режиме мастера во-первых  не умеет вызвывать прерывание по спаду Busy, а во-вторых не умеет само управлять выводом NSS (за исключением режима совместимости TI, в коем оно игнорирует практически все настройки). В АТмеге прерывание пришло - значит передача окончена и все свободны,  а тут блин двойная буферизация, коя приводит к необходимости ждать передачу двух байт прежде чем можно отпустить CS. В прерывании, ага. Убил бы...

[2017-11-17 09:54:07] m-s писал(а): Ну в stm32hal  ждут в прерывании. Скорее всего лучше не сделаешь.

СТ-шный Хал писАли индусы и я от него вообще в ужасе, по сравнению с ним SPL покойная просто лапочка была. Не просто ж так в свежих версиях оного ХАЛа появилось семейство функций _ll_, предоставляющее практически ту же функциональность что и SPL

 Во всяческих бета-/клин- и прочих флаях тоже ждут в прерывании, аж глаза от такого вытекают   8-O

void max7456_dma_irq_handler(dmaChannelDescriptor_t* descriptor)
{
if (DMA_GET_FLAG_STATUS(descriptor, DMA_IT_TCIF)) {
#ifdef MAX7456_DMA_CHANNEL_RX
DMA_Cmd(MAX7456_DMA_CHANNEL_RX, DISABLE);
#endif
// make sure spi dmd transfer is complete
while (SPI_I2S_GetFlagStatus (MAX7456_SPI_INSTANCE, SPI_I2S_FLAG_TXE) == RESET) {};
while (SPI_I2S_GetFlagStatus (MAX7456_SPI_INSTANCE, SPI_I2S_FLAG_BSY) == SET) {};

но как говорится  - "на горбатых не равняются", и таки есть способ лучше Я вот только что доделал отправку данных по SPI со стробированием каждого байта CS-ом, как этого MAX требует, и без малейшего ожидания в прерывании.