is the pico clock running @ 133 MHz ?
So my math…
133/2 (Pin On/Pin Off) = 66.5 Mhz
That sounds good… but, assuming you have 100% control and no other overhead 2 key things will come into play.
how long to make the pin go high (this can vary between micro controllers)
How does code really work.
Looking at 2.
while (true) {
Pin High
Pin Low
}
at the very least would be
:Loop
Load Register with while varable.
Compare that to "true"
Branch if not equal to exit
set pin high
set pin low
jmp loop
So this will be more like 6 CPU instructions, so assuming 1 instruction per tick
133/6 (Pin On/Pin Off) = 22.17 Mhz
So already we can see a big drop.
But since you are running pyton, you have its API's and overhead to deal with.
On a side note, CD audio quality = 44.1 Khz
the highest frequence will be 44.1/2 = 22.05 Khz
But at a sample rate of 44.1 Khz, that 22.05 will just be High/Low so a very triangle looking wave as direct output from the “read → DAC” So with 62khz, you have a little bit of room to play near CD quality.
60 megahertz would be excellent.
My dire pico is managing only 60 kilohertz…
Totally. Python is not a speedy boy. But we just calculated 6-18 cycles depending on how many ticks each instruction takes. Is python really adding 1000 ticks? That’s an order of magnitude.
Maybe, Im not really a python person. I know sometimes the abstract layers add delays. eg. on the ESP32, if you use the default GPIO set calls (in C under RTOS) then they are slow. But if you use the more hardware direct calls, they are much faster.
Sometimes the issue is more to do with something interrupting your code to run “system code” then come back.
e.g. On the weekend I was working on a project with a color touch screen. the display was fine and the web call to get the data was working ok, but the touch and screen re-draw for the new “screen” was very slow.
Turned out everything was running on the one core, so the SPI/SPIFFS was really slow, then the SPI clock out to the screen was slow. So I moved the data collection from the web into its own thread and put it on the 2nd core, now things are working fairly well. So, yeah, I can see that anything can get in the way with your code unless you can fully control it.
#![no_std]
#![no_main]
use bsp::entry;
use defmt::*;
use defmt_rtt as _;
use panic_probe as _;
use embedded_hal::digital::OutputPin;
use rp_pico as bsp;
use bsp::hal::{
pac,
sio::Sio,
};
#[entry]
fn main() -> ! {
info!("Program start");
let mut pac = pac::Peripherals::take().unwrap();
let sio = Sio::new(pac.SIO);
let pins = bsp::Pins::new(
pac.IO_BANK0,
pac.PADS_BANK0,
sio.gpio_bank0,
&mut pac.RESETS,
);
let mut led_pin = pins.gpio15.into_push_pull_output();
loop {
led_pin.set_high().unwrap();
led_pin.set_low().unwrap();
}
}
2.6Mhz frequency on the spot.
Rust boilerplate is full on but man does it bring the results!
I’ll need to think about how to clean up this square wave whilst still holding a clean frequency.
Anyway, looks like a I have a path forward if I want it.
I think the ringing on the square wave is more measurement technique.
For a start use the probe in 10:1 mode. It is a bit hard to tell with that pix.
Oscilloscope also has to be set for a 10:1 probe.
Make sure the probe compensation is set up correctly.
Make sure your earth lead is as not too long and find an earth point as close to the measuring point as possible.
In a nutshell it is very possible the ringing is not there in real life and you are putting it there.
Cheers Bob
If you expect to see a square wave with no ringing on an oscilloscope then you had better do something about it. You are using a pretty good instrument (Rigol) which I assume is something like a bandwidth of 100MHz or so. Have you adjusted your probe compensation properly?? you have not mentioned this which leads me to think that maybe you don’t know what it is. If this is the case just say so and you shall be enlightened. It is all in the instruction book as well.
You are going down the wrong path if you try to correct something that may not be there in reality. You can throw filters at it but if you filter it enough you can get back to something resembling a sine wave.
This all gets back to what I have been on about for some years now. To evaluate with some meaning what you see on a scope or measure with some other instrument you must be aware of all the limitations including instrument performance and measurement technique. If you don’t do this you could and will be faced with the present problem seeing something I really believe is not there.
I am not suggesting there is NO ringing at all. I am saying that before you regard what you are seeing on your Rigol as gospel you have to eliminate all the possibilities.
If all you want to do is get rid of the ringing on the oscilloscope trace the instrument amplifiers have built in filters you can switch in and tailor to suit so you can pretty much make the trace look like whatever you want.
I am not sure what you are using to generate this but even the very fine tracks connecting to the board points which are pretty popular these days will have some inductance which would not help and I think you could be looking at this open circuit and a termination of a few kΩ might improve things. Once again tis comes down to technique.
Cheers Bob
Yep. Set both the probe and the scope to 10x and I double check my probe was still calibrated to the 1khz test rect.
Still a little bit of ringing in the line.
I agree that measurement is vital.
Something I hadn’t considered is that the breadboard’s capacitance might be mucking with the waveform. Maybe that’s a factor.
Hi Pix
Not to mention the inductance. There are a lot of contributing factors here. If you have a rats nest of wiring I would take this sort of thing with a grain of salt and would not worry until I had something more permanent and tidier.
Cheers Bob
PS: Dit it improve when you set the probe compensation? Getting information here is like pulling teeth.
I wasn’t able to locate the Factory Episode, but I want to point out that the Pico has a much higher drive strength compared to many other microcontrollers. To address overshoot and undershoot issues, we’ve added 120-ohm series resistors on the SDA and SCL lines of the PiicoDev breakout.
All circuits inherently contain some parasitic capacitance and inductance. When these parasitics are combined with a fast edge rate (a step input), they form an RLC circuit—which is typically neither tuned or damped.
A smallish series resistor ought to fix your issue
In my case GPIO15 is oscillating so that’s where I should put my resistor.
I’ll see what happens as my circuit develops but that’s a good trick to keep in my back pocket.
Something else I considered last night is that, at some point, I’m going to need to step up the voltage from 3.3v to 5v.
I’m imagining a throwing 5v into a transistor with a small resistors and logic ICs coming out at the collector. Providing I keep the transistor saturated with my pico GPIO, any ringing, if it’s even there, won’t matter.
This will invert your signal. But if your signal is a repetitive square wave (50% duty cycle) this won’t matter.
If the ringing excursions are not great enough to reach the target device switching point so it switches off (or on) again it does not matter anyway. The other danger is if the pos or neg excursions might exceed the target device input max. If this device has input protection a series current limiting resistor will fix that. If not clamp diodes and same resistor should be fitted.
Cheers Bob
Haven’t looked at this thread before. Some comments.
According to all I read, micropython is an interpreted language. Source code is reduced to some sort of intermediate tokens, then the interpreter takes the tokens and processes them. This has huge overhead so not really the language for the job. Calculating a sin wave for every point also has overhead, often computed by successive approximation in a loop. Floating point has overhead too and best avoided for speed. Probably preaching to the converted.
Creating an output waveform at any speed is best done with a lookup table. Easy to generate the lookup table using: for x = 0/1 (depends on language) to limit; element[x]=sin(x/<something>); next x
Which only needs to be done once so doesn’t need to be efficient. For different waveforms jsut use an appropriate formula. Then there’s the process of stepping through the table to produce a particular frequency. The rate of stepping through the table is proportional to the frequency you want. It is best to calculate a step size with a fractional part because using integer step sizes with a fixed generating rate can only produce certain fixed frequencies. E.g. if your generating rate is 20kHz, your required output frequency is 2kHz, and your table size is 256, the step size has to be 25.6 elements.
In machine language, it is easiest to use powers of two so have an index of say 24 bits. So allocate 8 bits to the step size (the size of the table) and 16 bits to the fraction. Just keep adding the 24 bit number to another 24 bit number and use the top 8 bits of the second number as the table index. Because the index is 8 bits, the second number can overflow which automatically sends you back to the start of the table.
And lastly - ringing. Every part of a circuit has some sort of characteristic impedance. Standard coax commonly has an impedance of 50Ω. If the source has an impedance of 50Ω and the destination has an impedance of 50Ω then what goes in comes out the other end. Any sort of mismatch between source/transmission/destination causes signal reflections - i.e. ringing. It’s a bit of art to get everything to match up, and that sort of care may not be present when setting up test circuits. So spurious ringing may appear in measurements that aren’t there when not being measured - because the act of measurement changed the impedance of the point being measured. The ringing shown on the 2.6MHz signal may not be an issue, but a bit of RC will fix it. What RC I leave up to you. As a rough guess if the source has a 100Ω resistor then a load of 50pF would damp it down (RC about 32MHz)
Hi All
For what it is worth Silicon Chip published an excellent article in October 2009 entitled
“The Secret World of Oscilloscope Probes” by Doug Ford.
Should be compulsory reading if you really want to know how these things work. For instance how many know that the inner wire in a scope probe cable is actually a resistance wire and more importantly why this is so. My probes have a resistance of 100Ω as an example.
Cheers Bob
I have this article I removed from the magazine stashed away somewhere if I can still find it.
Hi Pix, Alan
I found that article from Silicon Chip.
I scanned a relevant bit regarding earth connections. Pix this should explain what I mean when I sat that you could be causing the “Ringing” with measurement technique. Makes interesting reading.
