ADC sampeling en Data verzenden

Hallo allemaal,

Voor mijn eindwerk moet ik de breedte van pulsen meten (in de tijd) via een arduino nano en vervolgens verzenden (via SPI).

Het meten van de pulsen doe ik als volgt:

  • Interrupt op Rising edge
  • Wanneer interupt gedetecteerd is start ik de timer.
  • Interrupt op Faling edge
  • Wanneer interupt gedetecteerd is stop ik de timer.

Dan weet ik aan de hand van de waarde van de timer hoe breed de puls is, dit werkt goed :).

Nu momenteel meet ik eerst 400 pulsen, na de 400 pulsen zet ik alle interrupt af en verzend ik alle info. Nu zou ik dit graag "op het zelfde moment doen" het lezen en verzenden van de sampels.

Zit op het volgende mogelijke probleem te denken, wat als er een intterupt gedetecteerd wordt terwijl de vorige data nog verzonden wordt (via SPI)? Wordt de bit die dan op dat moment verzonden wordt niet "uitgerokken" over de SPI bus??

Weet iemand hier een oplossing voor? Wil voorkomen dat de data over de SPI bus niet vervormd wordt door een interrupt.

Ik was zelf aan volgende oplossingen aan het denken:

  • Dual core CPU
  • IOT bordje dat linux draaid en hier met threads werken (Maar werkt dit dan feilloos, blijft nog steeds dikkels 1 core)
  • ...

Wat denken jullie dat een goede oplossing is? Is het vervormen van de data op de SPI bus echt een probleem of is dit een redenatiefout van mij?

Alvast bedankt!

Mvg

Nico

Op 27 september 2016 16:36:06 schreef Xest:
Zit op het volgende mogelijke probleem te denken, wat als er een intterupt gedetecteerd wordt terwijl de vorige data nog verzonden wordt (via SPI)? Wordt de bit die dan op dat moment verzonden wordt niet "uitgerokken" over de SPI bus??

Arduino is een AVR, en AVR devices hebben (meestal) een hardware SPI controller. Dat betekend dat de SW (je sketch) een volledige byte klaarzet voor de controller, en dat de controller die dan vervolgens verstuurt.

Daar komt dan geen interrupt meer tussen (tenzij je vanuit de interrupt-routine aan de SPI gaat frutsen, maar dat is meestal geen goed idee).

Als je een software SPI hebt (dus code die de touwtjes individueel hoog en laag maakt) gaat het ook goed: De bit blijft inderdaad hangen, maar de clock ook, waardoor de SPI bus als het ware "bevroren" wordt tijdens de interrupt.

Tot slot: Heeft de timer op de nano geen capture mogelijkheid? Want dan kun je die rechtstreeks gebruiken om pulslengte te meten.