I have post some questions and receive answers about imp ADC speed. The latest proposals from Hugo and Peter are OK but not enough.
ADC conversion still is slow.
After 2 weeks of many tries I give up with ADC and project fail - with imp not with other Cortex MCU like Maple or Arduino Due or much slower Arduino UNO.
After reading in to documentation about sampler “the maximum sample rate of the hardware is a theoretical 2MHz,” I must understand the rest “but Squirrel would be unable to process data at that rate except in short bursts”. Probably this must be declared for ALL ADC’s not only for sampler.
No simple an elegant design.
Below I post image (imp no installed in socket near SMPS).
Current solution is to use other MCU - ATtiny (8MHz, internal osc) - and UART communication with imp.
ATtiny here is about 20% faster than imp in this case.
I suppose - due to necessity detect fast and short event in code and we know that definitely allow to “miss the bell”.
The lack of interrupt is main imp disadvantage.
On current stage it is not possible to use single imp for 3-phase AC mains power consumption at all, in spite of Cortex inside.
Only variant show below (1-phase monitoring device) for each phase and then final calculations and WiFi can be done by imp.
Monitoring device UART output allow use less expensive 433MHz wireless communication between power monitoring nodes and main point where imp can act as final calculator and WiFi module.
Probably this must be declared for ALL ADC’s not only for sampler.
Once again: there is nothing special about ADCs in this regard: you would be probably also be unable to read GPIOs at that rate. In general, protocols that are timing-critical at a sub-millisecond level won’t work if open-coded or bit-banged in Squirrel: they must either be directly supported by peripherals (e.g. SPI), or implemented by us in C++ or in hardware and exposed to Squirrel via an API (e.g. the pin-triggered pulse generator). We’re always open to suggestions for new facilities, and if enough people wanted a pin-triggered sampler (which would remove the tight timing constraints from your Squirrel code), then we could add it to a future release.
@peter. OK - I’ll wait As we know - each device is the best for some application and for some not. For mentioned particular application imp currently isn’t the best. At moment:)
I have learned from all this that currently imp is extended easy to use WiFi modem with some special features - acceptable in general occasions and very good in some (PWM, triggered pulse).
Pin triggered ADC and clear interrupt is necessary, from my point of view.
are you trying to measure energy in AC mains? You can use an energy measuring IC for that. I am not sure if you are having the goal for a commercial or consumer product or if this is hobby?
I have used the ADE7769 chip which is quite easy to implement but with the drawback that it puts out pulses. I used to be able to read the GPIO fast enough to respond to the pulses with pin change interrupts but that does not seem possible anymore. I have changed to using the pulse counter which blocks 95% of the time and I use the other 5% to send messages. I don’t mean to hijack the thread- just sharing this in case it is helpful to someone. I would love to have a pulse counter that doesn’t block but it is not critical.
Peter is noting that you are running code in an interpreter on an MCU. Every GPIO read, every variable assignment is being done by an interpreter reading bytecode, hashing strings, etc - it’s not compiled code.
For many applications, this is just fine. We have APIs that do many things that would normally require interrupt handlers, DMA, etc, like audio sampling for example, allowing the squirrel code to implement the buffer management and application level code. But… the imp is not a general purpose real time system, just as it isn’t a general purpose wifi module.
Will stuff get faster over time? Sure, it’s very likely. Will it ever be as fast as compiled code? No.
@Hugo, yes - that is what I have leaned from all may efforts - as you say “… the imp is not a general purpose real time system, just as it isn’t a general purpose wifi module”. I don’t blame imp - I like it as simple and very useful device. Probably I want more…
But if sampler, as it is, can do the job - sampling with 10KHz or 50KHz or more - normally I suggest that reading ADC pin will be approx. with the same speed.
Practical thing and I cannot achieve result - read ADC pin and add reading to integer in 100 microseconds interval - the same 10Khz.
I agree that there are a lot of stuff in between, but may be it s worth to do something with this in future? Because that is really very common application… as @peter has mentioned - pin triggered ADC…
But that for next year.
Currently - all the best in upcoming 2014 New Year!
As we know - each device is the best for some application and for some not. For mentioned particular application imp currently isn’t the best. At moment:)