New starter to uPython board

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
cooper
Posts: 23
Joined: Mon Oct 20, 2014 8:40 am

New starter to uPython board

Post by cooper » Mon Oct 20, 2014 10:02 am

Hello!

I think I'll introduce myself first, my name is Cooper and I am engineering graduate with an interest in python and and microcontrollers.

I have a few questions about the board:
1) Is it possible to boost the speed of the ADC? Our experiments seem to indicate a speed of around 46kHz but the datasheets suggest 2.4MHz. I don't need speeds quite that fast, around 500k would be great!
2) When the SD card is plugged into the board, the PC can only see the SD card mounted, is it possible to also mount the inbuilt flash storage as well as the SD card?

My apologies if these questions have been answered elsewhere but I cant seem to find anything relating to my questions above.

I appreciate any help!

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: New starter to uPython board

Post by dhylands » Fri Oct 24, 2014 3:42 pm

cooper wrote:Hello!

I think I'll introduce myself first, my name is Cooper and I am engineering graduate with an interest in python and and microcontrollers.

I have a few questions about the board:
1) Is it possible to boost the speed of the ADC? Our experiments seem to indicate a speed of around 46kHz but the datasheets suggest 2.4MHz. I don't need speeds quite that fast, around 500k would be great!
I'm guessing that you'd need to use DMA to get the samples into memory.

I'd recommend that you figure out what the fastest rate you can perform interrupts at is first. What are you planning on doing with the 500 kHz sample stream?
cooper wrote: 2) When the SD card is plugged into the board, the PC can only see the SD card mounted, is it possible to also mount the inbuilt flash storage as well as the SD card?
Currently the PC will only see the sdcard if the sdcard is plugged in, or see the internal flash if the sdcard is not plugged in.

Of course, both are available to micropython, so you could write some code that works over the serial port. I'd actually recommend this. Personally, while I like the convenience of having

cooper
Posts: 23
Joined: Mon Oct 20, 2014 8:40 am

Re: New starter to uPython board

Post by cooper » Tue Oct 28, 2014 10:12 am

Thank you for your reply
What are you planning on doing with the 500 kHz sample stream?
I want to to use the ADCs to measure the voltage of an RS485 bus running at maximum 115200baud. Usually it would be a maximum of 38400baud. I want to measure the A and B wires to get a value for signal quality by looking at the rise time of the signals. Measuring both channels allows us to remove any noise on the bus e.g. 50Hz mains. Even though RS485 is a robust standard, sometimes external factors can affect it like cable length or cable shielding.


Although its unfortunate that both storage devices cannot be mounted it is not a show stopper.

Thanks, Cooper

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: New starter to uPython board

Post by dhylands » Tue Oct 28, 2014 2:25 pm

I think that those kinds of capture rates will definitely need something like DMA to capture the samples. Anything else will have jitter.

Unfortunately, there isn't any support for that yet in micropython.

The closest thing that exists today is the timed read where you can specify a frequency and a buffer and it goes off and collects the indicated number of samples.

You'd need to disable interrupts (while doing the timed read) or things like the millisecond tick counter will screw things up.

stijn
Posts: 735
Joined: Thu Apr 24, 2014 9:13 am

Re: New starter to uPython board

Post by stijn » Tue Oct 28, 2014 4:43 pm

dhylands wrote:I think that those kinds of capture rates will definitely need something like DMA to capture the samples. Anything else will have jitter.
+1 that is how it is done commonly on all architectures ranging from tiny microcontrollers to pcs: use DMA, which then causes an interrupt when one or more blocks have been read, then in the interrupt you either process directly (tricky) or signal the rest of the code that new data is in (more common, plus you have plenty of time anyway). Btw that's the typical stuff you do in engineering school projects :D

Can't help you with the practical side though: no idea if the board exposes everything needed to make DMA work. If it does however it shouldn't be particularly hard to write some C code for it and add micropython 'bindings' for it. After all that's how adc/dac are implemented now as well.

cooper
Posts: 23
Joined: Mon Oct 20, 2014 8:40 am

Re: New starter to uPython board

Post by cooper » Thu Oct 30, 2014 8:38 am

Thank you for your input guys.
Btw that's the typical stuff you do in engineering school projects :D
Haha my project, although used microcontrollers did not touch upon DMA, nor were we taught anything about them! Will DMA be implemented in some form in the future or will this be something I'll have to implement?
I have touched upon PIC C back in the day to make a really simple line following robot... but i imagine something like this involves a bit more work.

blmorris
Posts: 348
Joined: Fri May 02, 2014 3:43 pm
Location: Massachusetts, USA

Re: New starter to uPython board

Post by blmorris » Thu Oct 30, 2014 1:26 pm

Another +1 for using DMA for this kind of application. While I haven't dug into it too deeply yet, I'm pretty sure that the DMA resources on the pyboard's STM32F405 are quite useable. I know that the DAC write_timed() method uses DMA (ADC doesn't yet use it), and I have a colleague who has written an I2S driver which also uses it (unfortunately it was written using a much older set of peripheral libraries than micropython uses and I haven't yet been able to interest him in porting his work over to micropython.) I imagine that it is only a matter of time and (probably somewhat significant) effort to get more of the peripheral drivers to use DMA, but I'm not sure if there are any other tradeoffs or disadvantages to using it.

I imagine it would be possible to get high sample rates from the ADC using inline assembler, but you would waste most of the processor's computing power stuck in a blocking loop to do so - might be useful to test how fast you can go, but won't give you any time to process or store your data (maybe you could just stream it out over USB? I don't know.)
stijn wrote:Btw that's the typical stuff you do in engineering school projects :D
Yeah, in my experience the undergraduate academic schedule doesn't allow much leeway for getting stuck with problems that are too big or deep to solve right away - that's what grad school is for ;)

cooper
Posts: 23
Joined: Mon Oct 20, 2014 8:40 am

Re: New starter to uPython board

Post by cooper » Mon Nov 03, 2014 9:51 am

Does anyone have any other suggestions for measuring rise time for a signal on an RS485 bus without having to use a really fast ADC? Or another means of measuring signal quality...

My other idea was to measure the capacitance of the line as any rise time below the time constant would never reach peak levels but this would require disconnecting everything on the bus which would be inconvenient.
that's what grad school is for ;)
After 4 years I don't think I had it in me to do anymore!

blmorris
Posts: 348
Joined: Fri May 02, 2014 3:43 pm
Location: Massachusetts, USA

Re: New starter to uPython board

Post by blmorris » Mon Nov 03, 2014 2:43 pm

cooper wrote:Does anyone have any other suggestions for measuring rise time for a signal on an RS485 bus without having to use a really fast ADC? Or another means of measuring signal quality...
For direct measurement of rise/fall time, I don't know of any better alternative to a fast ADC or an oscilloscope trace, both of which provide essentially the same information in this case. I can imagine it might be possible to implicitly determine the transition time of a signal by doing a spectral analysis and looking at the high-frequency harmonic components, but for a relatively slow 115.2 kbaud signal I don't know that this would actually be easier than a direct measurement. (Certainly not easier for me, as I couldn't tell you exactly how to do it…)
The ADC hardware on the STM32F405 is certainly up to the task, if you can figure out a way to squeeze out the necessary high sample rates - even if 2.4 MHz isn't sufficient, the hardware documentation describes a 'triple interleaved' mode in which all three hardware ADC's take turns reading from a single pin to achieve rates as high as 7.2 MHz. Of course, none of this is available via the uPy API yet, and even if it were you would still need to figure out how to store and/or process the burst of data you receive.
Neither of these problems is insurmountable. As for the ADC, any work that you do to expand the hardware support in the API would likely get incorporated into the main trunk. I will be happy to help as I can, though with my limited knowledge of C I can't promise too much.
As for dealing with the flood of data, you probably don't actually need to store or process it all - I could imagine a system where all data is written to a modest size buffer in RAM as it is received. When you detect an edge transition you can be pretty sure that there will be a bit of time before another transition is due, so you could stop collecting long enough to process the buffered data and store the statistics on that transition before you resume data collection again. I would also imagine that this system would probably work best if the board is not maintaining a USB connection at the same time as you are collecting data - as I understand it, the USB system uses a nontrivial amount of processor time, and it can't be temporarily postponed or disabled if a connection is to be maintained. In other words, probably best to plan a standalone application to collect data, and store the collected data to an SD card.
Good luck with your project, and if you decide to continue with micropython I would be interested to hear how it all goes.
-Bryan

cooper
Posts: 23
Joined: Mon Oct 20, 2014 8:40 am

Re: New starter to uPython board

Post by cooper » Wed Nov 05, 2014 9:50 am

Hello Brian,

Thank you for your input, I agree that directly measuring the output would be best as I don't really fancy doing Fourier analysis (especially as I have forgotten it all!).

As I do not need to sample for long periods of time, there might be enough ram to store the info on. I intend this to be a stand alone unit, controlled via Bluetooth over a Bluetooth terminal so USB isnt any issue. At the end of the sampling/processing period I just want a percentage or a green light saying the comms quality is ok, nothing too detailed. Even 2.4MHz would be over kill really, it would only be the odd instance where we would want to look at 115200 baud comms it would usually be a max speed of 38400 baud.

For all purposes I intend to continue with uPython as most of my existing programs are in python and porting them across would be a doddle. The main purpose of this project is a serial comms monitor, that is flexible. The flexibility allows me to swap the type of comms used e.g. 485,232 even IBIS! The quality measurement part of it would just be the cherry on top.

Right now I have a prototype running which features 2 changeable serial ports, 1 bluetooth to serial, a UPS, a 24V to 5V stepdown to charge the battery and various break outs. It's all looking very good, just need to transfer the circuit to a CAD package so I can make a few of these! Heres a pic if you're interested:

Image

Post Reply