Hardware DMA for ADS1118 via SPI

[dweinho1]

Hello all,

I am looking to setup a Pyboard 1.1 to read data from multiple ADC channels using an ADS1118. I'd like to read a continuous data stream from multiple channels on the ADC. To do this, I believe I need to setup DMA to write data into buffers.

Here is the ADS1118 datasheet: https://www.ti.com/lit/ds/symlink/ads11 ... e.com%252F

Here is the STM32F4 reference manual: https://www.st.com/resource/en/referenc ... ronics.pdf

To read from multiple channels, I believe I need to write to the config register (bits 14 to 12) it appears I need to regularly write to the config register. So I believe I need to setup three DMA channels:
- A write DMA (memory to peripheral): To regular toggle the mux by writing to the config file.
- A read DMA (peripheral to memory): To get data from one input
- A read DMA (peripheral to memory): To get data from a second input

Is this feasible, and if so, any tips/help on how to proceed? From reading the micropython documentation, it doesn't look like this is setup to this as is.

Poking around in the dma.c code, it looks like I need to do a couple of things:
- Enable FIFO mode
- Utilize DMA1 Streams 3 and 4 since I want to use SPI2
- Setup the source and destination addresses --how to tie these to buffers that my code can access?
- What else am I missing?

A bit about me: I'm between a hobbyist and professional in regards to python but am very much a newbie on C. Thanks for any help.

[rkompass]

Hello dweinho1,

I had a look into the datasheet. It is 95% identical to that of the ads1115. Main difference is that the ads1118 uses spi for communication whereas the ads1115 uses i2c. Also the ads1118 has an internal temperature sensor while the ads1115 has a comparator. Electrically both are almost the same, but the ads1118 has slightly better offset errors.
I suggest adapting the existing driver for the ads1115 (you find it on https://github.com/mcauser/awesome-micropython#sensors. I.e.:https://github.com/robert-hh/ads1x15.
I attach my driver for an ads1220 for an example how to use spi and, if you like so, for a slightly different programming style (for example, I found that many const() definitions still consume memory unnecessarily, despite the manual telling us not so).
If you need help, I can assist in converting the driver to ads1118.
Both ads1115 and ads1118 have maximum conversion rate of 860 conversions per second. I don't think you need dma for such 'slow' adcs.
A timer-interrupt or an interrupt driven by the DOUT/_DRDY-pin going low to fetch the next data should be more than sufficient.
Greetings,
Raul

[dweinho1]

Raul,

Thanks so much for providing this! This should work for me. I did some poking around for current drivers out there but couldn't find any so this fantastic.

I'd still be interested in implementing DMA, but I realize I am asking for a lot of support. I am planning on doing quite a bit with my code but it probably makes sense to start without DMA and then go from there and try to implement it later if necessary.

[Roberthh]

That's all good. Making/adapting the driver for ADS1118 is on my list since long, and I have breakouts in my drawer as well since a while. Maybe this advances now. Using Timer callbacks or interrupts should be sufficiently fast. Only the timing precision of a DMA solution would be better. With Timer or Pin interrupts there will be always a small jitter caused by the latency. But I used already the ADS1115 in an application getting up to 200 samples/s with a ESP8266, and that worked well. The jitter did not matter in that case.

[dweinho1]

Robert, please update if you end up doing this. I am unexpectedly not going to work on this for a couple of weeks. So if you tackle it before I get to this, I'd love to utilize your work. Though doing this myself would be a good learning experience.

[rkompass]

I'm almost finished on adapting the driver for ADS1118. Now I'm in the testing phase. I will report the results and code here soon.
The 1118 has no dedicated _DRDY (data ready) - pin. It is combined with spi miso. if you put _CS (chip select, sometimes denoted _SS) down, miso will go down if new data are available and stay up otherwise, until the spi clock starts. I found that the miso pin can still be evaluated if instantiated separately before setting up spi and given as an extra argument to the ads1118 class. But the question why we can't get the miso.value() just from within spi is raised again. Although this does not seems to be a big thing, I'm not familiar enough with micropython internals to suggest a patch here (Robert??).
To get interrupts from the DOUT/_DRDY (i.e.miso) pin when data are ready also seems to be an interesting problem due to the fact that transmission of data produces many signal flanks that have nothing to do with data ready.

[Roberthh]

That are great news. About _DRDY: the various ports behave different. Some allow to probe a SPI pin with Pin methods, some not. For some ports the CS pins has to be asserted by the code, some ports have a kind of 'automatic' cs, where the CS signal is handled by the driver & hardware. So the common minimal approach would be not to care about the _DRDY pin and just get data from the device after a specified time. The worst that could happen is getting the data from the previous conversion cycle. Even Optionally one could offer a method probing the _DRDY pin. Since the order of instantiation of SPI object and optionally CS and Pin for _DRDY objects is port specific, both must be supplied to the ads1118 driver. The driver then can assume, that a pin read from the DRDY pin would return the level at the pad. But then the probing method would essentially be only a Pin write(CS), Pin read(_DRDY) and another Pin write to CS, it may not be worth to provide a class method for it.
For ports where CS is handled by the SPI driver, it should be possible to supply None for CS, in which case it is not used.

Using _DRDY for interrupts would requirtes to keep CS low all the time and have the ADS1118 being the only device on the bus. So we should ignore that for now.

[rkompass]

Here is a version of the driver, together with a test program.
In the single modes the reading is timed according to the miso = _DRDY signal going down.
I found that to work with SoftSPI only (on my F411 BlackPill-Board).
With ordinary SPI the MISO-Pin seems to get the property Pin.PULL_DOWN. Also miso starts to behave differently, depending on _CS.
I cannot test further now as I broke the ads when trying different boards because of this. When I get the next chips I may continue.
Experimenting with interrupts have not begun yet..
Would be nice to get feedback and perhaps you have a suggestion for ordinary SPI.

[Roberthh]

Thank you for providing the code. It looks very good, and this afternoon I started some testing.
I tried quite long with a chip, but it did not respond at all. Then I took a second chip, and that one works. I'm trying with a Teensy board, just because I have it here and it was already sitting on a breadboard. SoftSPI and HardSPI work do work similar, if the code just waits for the needed time. What does not work in hard SPI mode is probing of the /DRDY signal. The only way to get in a portable way would be connecting DOUT to another pin in Pin mode.