Mir sind folgende BLE Controller mit Dual Core bekannt:
- ST WB55
- NRF53
- ESP32-S3 (und andere Varianten)
In meiner Applikation habe ich einen ADC einer Datenrate von 1kHz -
10kHz, daher fallen Controller mit managed Interrupts wie NRF52 raus
(der BLE Stack könnte zu lange blockieren). Daher suche ich BLE
Controller mit Dual Core.
Beim ST hat man volle Kontrolle über den Application Core, aber bei den
NRF53 und ESP32 Dual Cores finde ich keine Dokumentation, darüber ob die
Applikation in einer Sandbox läuft oder nicht.
Für den NRF52 habe ich die zugehörige Doku über das Softdevice gefunden,
aber wo ist die zugehörige Doku für den NRF53?
PSoC 63 ist ein dual core (MR und M0+) mit BLE. Bei dem man beide cores
frei programmieren kann.
PSoC4 ist "nur" ein single core M0, wobei ich mich Frage was in der ADC
ISR passieren soll, damit der nicht reicht.
Die STM32WBs sind sicher gute Drivate, jedoch habe ich als Laie es nicht
hinbekommen das BLE zu verwenden. Die Dokumentation ist ziemlich
verworren und unübersichtlich, sowie umfangreich.
Robin schrieb:> PSoC 63 ist ein dual core (MR und M0+) mit BLE. Bei dem man beide> cores> frei programmieren kann.
Das geht wohl bei den ESP32 dual cores auch, aber das freie
Programmieren von dem 2. Core (also der angenommene für BLE) erzwingt
soweit ich weiß eine Sandbox, ansonsten kann das nicht vom Hersteller
für beliebige Applikationen zertifiziert sein?
Bei den STWB55 läuft auf dem Network Core wirklich nur BLE, das gefällt
mir besser. Dadurch entwickelt man auch gar nicht für einen Dual Core,
sondern quasi für einen Single Core mit spezieller Peripherie.
ble schrieb:> In meiner Applikation habe ich einen ADC einer Datenrate von 1kHz -> 10kHz, daher fallen Controller mit managed Interrupts wie NRF52 raus> (der BLE Stack könnte zu lange blockieren). Daher suche ich BLE> Controller mit Dual Core.
Verwende einfach DMA, dann sollte es doch überhaupt kein Problem geben,
die 10k samples vom ADC abzuholen.
> Für den NRF52 habe ich die zugehörige Doku über das Softdevice gefunden,> aber wo ist die zugehörige Doku für den NRF53?
Spannend, habe ich auch nicht gefunden. Vielleicht gibt es kein SD und
die Verwendung von Zephyr ist vorgesehen.
Der CC2640 von TI hat eine Cortex M3 plus einen eigenen
Radio-Controller. Die Software-Entwicklung macht in dem Bereich aber
echt keinen Spaß.
ble schrieb:> Das geht wohl bei den ESP32 dual cores auch, aber das freie> Programmieren von dem 2. Core (also der angenommene für BLE) erzwingt> soweit ich weiß eine Sandbox, ansonsten kann das nicht vom Hersteller> für beliebige Applikationen zertifiziert sein?
Mein Stand hierzu ist, dass die Module nur den BLE Stack und die BLE
Hardware Implementierung (Transceiver, Antenne, ...) zertifiziert haben,
die Application muss aber meines Wissens immer selbst zertifiziert
werden.
> Bei den STWB55 läuft auf dem Network Core wirklich nur BLE, das gefällt> mir besser. Dadurch entwickelt man auch gar nicht für einen Dual Core,> sondern quasi für einen Single Core mit spezieller Peripherie.
Dafür gibt es beim PSoC6 auch ein fertiges Image für den M0+, der den
BLE LowLevel kram übernimmt, auf dem CM4 Core werden dann die BLE
Profile gehandelt. Ist dann auch quasi Single Core.
https://github.com/Infineon/psoc6cm0p/tree/master/COMPONENT_CM0P_BLESS
Ich sehe aber auch noch nicht wirklich den Anwendungsfall für einen Dual
Core, 1-10kHz ist jetzt nicht wirklich schnell.
Danke für die Vorschläge soweit.
Was mir erst jetzt in den Sinn kommt:
Kann ich bei den frei programmierbaren Dualcores (Psoc, ESP32, NRF53)
einstellen, dass die BLE Interrupts auf Core0 und mein DRDY Interrupt
gleichzeitig auf Core1 läuft?
Dann hätte sich das Problem ja erübrigt. Meine Befürchtung war, dass der
BLE Stack wahllos um 100µs alle Interrupts blockieren kann (wie bei BLE
Singlecore Modulen).
ble schrieb:> Kann ich bei den frei programmierbaren Dualcores (Psoc, ESP32, NRF53)> einstellen, dass die BLE Interrupts auf Core0 und mein DRDY Interrupt> gleichzeitig auf Core1 läuft?
davon würde ich sehr stark ausgehen.
> Dann hätte sich das Problem ja erübrigt. Meine Befürchtung war, dass der> BLE Stack wahllos um 100µs alle Interrupts blockieren kann (wie bei BLE> Singlecore Modulen).
Was sind den genau Deine Befürchtungen / Anforderungen? Ich kann mir
beim besten Willen nicht vorstellen, warum der BLE Stack 100µs lang alle
Interrupts blockieren sollte. In der Regel werden das ein paar µs sein.
Und wie gesagt: die meisten µCs haben DMA.
Torsten R. schrieb:> Was sind den genau Deine Befürchtungen / Anforderungen? Ich kann mir> beim besten Willen nicht vorstellen, warum der BLE Stack 100µs lang alle> Interrupts blockieren sollte. In der Regel werden das ein paar µs sein.> Und wie gesagt: die meisten µCs haben DMA.
Wenn man hier
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fprocessor_avail_interrupt_latency%2Fexception_mgmt_sd.html
das softdevice runterlädt, findet man z.B. auf Seite 89, dass der bei
einem Connect Event der BLE Stack bis zu 250µs für das Postprocessing
braucht. Das läuft im Softdevice timing-critical interrupt, solange
läuft da nichts von der Userapplikation. Das ganze gilt für einen NRF5X
Singlecore.
DMA ist natürlich gut, aber wenn ich die ADC Daten auch live verarbeiten
möchte muss der DMA (oder mit weiterem Peripheral):
- automatisch Transfer triggern bei DRDY interrupt
- Memoryaddresse nach jedem Transfer ändern können
Das können manche, aber denke ich nicht alle Mikrocontroller.
Die Anforderung ist, dass ich in Echtzeit (also höchste
Interruptpriorität) alle 100µs einen DMA transfer starten kann. Wenn der
Controller/DMA das automatisch kann, entfällt die Echtzeitanforderung.
