$10 O-Scope revisited

mrburnette wrote:
Yes, this issue is simply an Arduino IDE issue in the way that libraries are searched … one can only have a single Time.h in the /Arduino/libraries directory. It sucks, really, but is just one of those abstract things that Arduino does.

I strongly recommend putting such code directly into the directory with the INO file(s) and encapsulate it. Hard disks are so large these days that the duplicated space is insignificant and the way the ArduinoIDE is evolving, having the Board Manager updating libraries has caused me a great deal of annoyance. Anyway, there are some environments such as Cypress PSoC development where libraries are always copied into the working folder – so the paradigm is not weird.

Ray

rexnanet wrote:
<…>
To solve many of these issues we could create a zip/rar file with all the necessary libraries “in a working state” to make it easier to replicate the project.

That approach makes it more dificult to share libraries and their changes but makes compilation a lot easier.
<…>

victor_pv wrote:Andy,

I worked some optimizations in the lcd library. It is still not the best it can, but much faster than before specially when it comes to drawing the captured data.
Download the zip attached and use that. It requires the latest SPI library from Roger’s repo.

Adafruit_ILI9341_STM.zip

mrburnette wrote:The neatest part of this is that you are using Pix of the O’scope in operation to show capability and issues.

Job well done… this should be a required build for any serious tinkerer who does not have access to a scope. This would be a great PSoC 4200 project due to the “free” analog subsystem and analog mux + OpAmp. FYI, only $4 http://www.cypress.com/?rID=92146
( do not even consider 4100 )

Ray

rexnanet wrote:
Latter I’ll test it on the board

rexnanet wrote:
Is the ADC fast(enough)?
http://www.mouser.com/ds/2/100/001-87197-269422.pdf

rexnanet wrote:rexnanet wrote:
Latter I’ll test it on the board

ahull wrote:
Take care with the backlight, the pins on the STM32F103 may not be able to source the current needed to run the display at full brightness, you may (depending on your LCD board) need to add a transistor to drive the backlight.

rexnanet wrote:ahull wrote:
No, the ADC on most boards is tied to the supply voltage, so in most cases you input signal *must* be between 0v and VCC (3.3V) otherwise you will damage the ADC.

ahull wrote:
Dual channel should be relatively easy, but you will not get the full bandwith.

You might find this interesting. https://www.tablix.org/~avian/blog/arch … oller_adc/

As to the stability of AnalogWrite, I am not aware of any instability, I suppose the best way to check for this would be to compare with a real oscilloscope.

Once you have the kinks ironed out of your changes and you are happy with them, fire me a pull request on githib, and I can merge them if you want.

Based on the available analog bandwidth per Alvin’s Blog post I wonder if we can over clock the ADC (at the expense of resolution presumably), and get reliable results beyond the 1MHz stated STM Spec. It looks like an interesting experiment to try. Even 8 bit resolution at say 10MHz would be useful. The GD32F103 red pill boards might also be worth a bit of over clocking experimentation, their silicon should in theory be more amenable to being driven at higher frequencies.

Andy

The GD32 boards seem to work fine at 120Mhz, but Ive not looked at whether the ADC works at that frequency.
But it is specced to 108Mhz ( but as you know, USB only works at 48,72,96 and 120Mhz because of limitations in the USB PLL clock divider)

RogerClark wrote:Andy

The GD32 boards seem to work fine at 120Mhz, but Ive not looked at whether the ADC works at that frequency.
But it is specced to 108Mhz ( but as you know, USB only works at 48,72,96 and 120Mhz because of limitations in the USB PLL clock divider)

HI Andy

I think someone may have already looked into clock switching, but I though it breaks the USB connection

You could of course force USB re-enumeration, but that would be a pain every time you wanted to transfer data

Unfortunately the STM32 only has 2 clock divider settings for the USB PLL, but the GD32 has 4 (2 bits) (this has been possible because STM have a reserved bit in the register next to the bit for the PLL divider, so GD were able to add 2 more PLL divider settings and yet keep backwards compatibility

RogerClark wrote:HI Andy

I think someone may have already looked into clock switching, but I though it breaks the USB connection

Hi Andy

I’m afraid I’ve not looked at the ADC clock at all.

Looking in the manual RM0008, there is a PLL divider for the ADC clock, but I don’t know where its setup in the core.

I took a quick look in the libmaple folder at adc.c, but I can only see the setup for the number of clock cycles per sample, rather than the master PLL divider for the ADC.

I suspect the ADC clock stuff is probably setup somewhere in the RCC code, but I’m not sure where.

If someone had time to play with it, I suppose you may be able to get a bit more performance at the expense of resolution, but I wonder how useful it would actually be, or whether you’d just end up with erroneous results.

ahull wrote:You might find this interesting. https://www.tablix.org/~avian/blog/arch … oller_adc/

As to the stability of AnalogWrite, I am not aware of any instability, I suppose the best way to check for this would be to compare with a real oscilloscope.

rexnanet wrote:
With an overclocked ADC we must keep the 1.5clk on the sample time to allow a proper sampling of the signal.

You could modify the SPI DMA transfer to be non blocking, and to generate an interrupt when the transfer is complete, as this would allow the core of the cpu to go off and do other stuff while the spi transfer was happening.

But I dont suppose there is much that the cpu could do while waiting for the spi transfer to finish?