Are there any reason you did not use interrupt based sampling?
1 Like
I have no idea what that is? Can you elaborate?
Below link is a sample code for sampling MCP3208.
It tested upto 50Khz ( 3.3V supply on MCP3208).
No need any delay or while loop.
Optimized 19bit SPI.
Example
I don’t open zip files from unknown sources, but to your points IoTaWatt presently samples at a rate of 75K using 19 bit SPI and doing housekeeping (check zero cross, time-shift odd sample, store sample values etc.) asynchronously while ADC transfers SPI data, so I don’t see a big win. The sampling code operates on the metal. I would expect that interrupt handling would only slow it down, and apparently does if your sample code achieves 50K.
1 Like
Thanks for your points.
I changed the link.
The maximum sampling rate is limited by VDD of MCP3208, not the Interrupt.
When we don’t use interrupt, we should have while loop and wait for end of every SPI transfer.
Waiting isn’t the issue, it’s what you do while you are waiting. If you have nothing else to do, then a while loop is really the same as this interrupt technique. In the case of IoTaWatt, we do some other things during the SPI transfer, then wait, with a while loop, until completion. The module is samplePower in the Git.
So looking at your code, it appears you interrupt every 20 usec, which is consistent with your 50 kHz sample rate. IoTaWatt does an SPI sample in 13 usec. So to answer your original question, I use the while loop rather than something else like this interrupt technique because it’s much faster.
1 Like