'У костра'

[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 требует, и без малейшего ожидания в прерывании.