[ZiB 0]

Сходил за платой...

 

Нашел место, но не понял причину.

 

Странная штука получается, в обоих мк (STM32F303 и STM32F373) независимый таймер подключен к шине АВР1, правда АЦП сидят на разных шинах.

В 303 снижение частоты АВР1 в 16 раз, ни дает ни какого эффекта, а вот в 373 это приводит к торможению обмена АЦП, хотя АЦП подключен к APB2.

 

В 100-ом похожая структура и там тоже аналогичная ситуация, процесс передачи данных замедляется.

 

В 407-ом замедления нет, но структура похожа на 100 и 373.

 

--------

Получается в 100-ом, 373-ом при обращение к любой переферии на шине АВР1, тормозится процесс обмена.

В 407-ом и 303, нет замедления.

 

Кто подскажет как прогнозировать данный процесс ?

 

[ZiB 0]

Работать на бОльшей и много спать.

 

Выигрыша нет. Например при тактовой 12 МГц потребление (по цифре) на полном ходу 7,4 мА, при остановленом 3,8 мА.

Если поднять частоту до 48 МГц, при этом уменьшить частоту шин для периферии на 4 (пропорционально увеличению частоты) и остановить ядро, получим 10,5 мА (на полном ходу 19,9 мА).

Начинает кушать больше всё, что весит на шине AHB.

В моем случае: 10,5 - 3,8 = 6,7 мА и (48 - 12 = 36 МГц) - это

1) DMA - 18,3 * 36 = 658 мкА

2) BusMatrix - 6,9 * 36 = 248 мкА

3) ABP2-Bridge - 4.2 * 36 = 151 мкА

4) ABP2-Bridge - 6.9 * 36 = 248 мкА

5) GPIO(A-E) - (12.2+11.9+4.3+12.0+4.4)*36 = 1612 мкА

суммарно 2,9 мА, оставшиеся 3,8 мА (105 мкА/МГц) прочие накладные расходы :)

[jcxz 184]

Мне трудно судить про ST, я работаю в основном с NXP ядрами.

Но недавно у меня была похожая проблема при переносе кода с LPC1778 на более ранний LPC1758.

Начинало сбоить DMA<->SSP, хотя на LPC1778 всё прекрасно работало под длительными тяжёлыми тестами и периферия SSP и GPDMA в обоих контроллерах очень похожа.

На более низких скоростях (при снижении до единиц МГц) начинало работать, но хотелось как на LPC1778 - 20-30МГц по SSP.

Да - на LPC1778 я ещё ставил приоритет доступа к шине для GPDMA выше чем для CPU (там есть соотв. регистр), но на LPC1758 такого регистра нет :(

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

В чём разница я так и не понял, но теперь все тесты проходят нормально на самых высоких скоростях.

Да - у SSP-портов на LPC есть небольшое FIFO - вроде 8 слов насколько помню. Может оно помогает.

На контроллерах ST почему-то FIFO в периферии не любят

 

В вашем ST нету регистра управляющего приоритетами доступа к шине для разных устройств?

 

PS: А зачем кста так часто дёргать сторожевик?

[ZiB 0]

Да, есть 4-е уровня приоритета для ПДП, но у меня он и так самый высокий стоит.

 

Сбрасывал реально не так, часто.

Просто когда заметил небольшое отклонение стал искать причину, ну остановился на бескончном цикле, так более заметно влияние.

 

[jcxz 184]

Да, есть 4-е уровня приоритета для ПДП, но у меня он и так самый высокий стоит.

Я имею в виду не приоритеты каналов DMA, а приоритеты разных bus-masters (CPU I-Code bus, CPU D-Code bus, System bus, GPDMA bus, ...). У вас задача - чтобы приоритет доступа к шине для DMA был выше чем у шин CPU.

Вообще не понимаю разработчиков ядра Cortex - почему у процессора приоритет доступа (по дефолту) выше чем у DMA??? С этим часто бывают проблемы. На DSP C5502 у меня тоже с этим была проблема.

Имхо - должно быть наоборот. Везде где можно ставлю приоритет DMA выше чем у CPU.

Если интересно как сделано в LPC1778, можете глянуть раздел "2.5 AHB arbitration" юзермануала (UM10470.pdf). Там расписаны все bus-master-ы с приоритетами.

[Flexz 0]

В STM-ках приоритет Bus master-ов не контролируется, Round Robin и точка. По крайней мере так говорит мануал.

[vlad_new 1]

Поставте в while несколько __nop(). Дайте DMA немножко больше тактов на передачу данных. Может все и будет нормально, если перефирию слишком часто не дергать. Ну так просто для интересу.

К стате, чего Вы к таким скоростям ADC привязались? Сигма дельта, который Вы хотите на таких скоростях не работает.

 

Изменено 20 мая, 2013 пользователем vlad_new

[ZiB 0]

Дело, в том, что при любом обращении (хоть в цикле с нопами, хоть без) происходит задерка обмена, что приводит к изменению частоты дискретизации.

Конечно, чем реже обращения тем меньше вклад.

 

Возможности АЦП я прекрасно осознаю, да и не писал я, что мне нужно выжать из сигма-дельта 400 кГц.

 

Я говорил, о комбинации высокоскоростного преобразования 400 кГц (12 бит) и низкоскоростного, но с высоким разрешением 16 бит. А это доступно, только в STM32F373 (383).

 

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