New starter to uPython board
New starter to uPython board
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!
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!
Re: New starter to uPython board
I'm guessing that you'd need to use DMA to get the samples into memory.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'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?
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.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?
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
Re: New starter to uPython board
Thank you for your reply
Although its unfortunate that both storage devices cannot be mounted it is not a show stopper.
Thanks, Cooper
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.What are you planning on doing with the 500 kHz sample stream?
Although its unfortunate that both storage devices cannot be mounted it is not a show stopper.
Thanks, Cooper
Re: New starter to uPython board
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.
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.
Re: New starter to uPython board
+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 projectsdhylands wrote:I think that those kinds of capture rates will definitely need something like DMA to capture the samples. Anything else will have jitter.

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.
Re: New starter to uPython board
Thank you for your input guys.
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.
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?Btw that's the typical stuff you do in engineering school projects![]()
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.
Re: New starter to uPython board
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.)

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.)
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 forstijn wrote:Btw that's the typical stuff you do in engineering school projects![]()

Re: New starter to uPython board
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.
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.
After 4 years I don't think I had it in me to do anymore!that's what grad school is for
Re: New starter to uPython board
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…)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...
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
Re: New starter to uPython board
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:

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:
