For performance sensitive application, i would definitely recommend programming it with Arduino C or just plain C, then I am sure it would be way faster.
You're right. And to make it even faster, use the PIO feature of the RP 2040. Check out my video (ruclips.net/video/dGNJGC_wZtk/видео.html) where I use PIO and MicroPython to achieve speeds much faster than the 6502 can handle.
If you really want speed, you need to access the IOPorts directly rather than through "function" calls. The problem with Arduino IDE, Python IDEs, etc, is they always only promote port access in bit function calls. On the Atmega328, you can access 8-bit ports just as if they are a local variable (i.e. SFRs), and in the Pico, you can access 32-bit ports in Single-Cycle IO Block. I haven't played with the Pico IO ports, but I know they are going to be 100s/1000s times faster than calling a function to read/write just 1 bit.... Check out the RP2040 Datasheet for details.
That sounds like something I'll have to look at. Right now, what I hooking the Pico up to is very slow, and I also think I'm going to to be speed limited with the level shifting hardware that I'm testing now.
@@LifewithDavid1 I don't know if it's available in Python... But with C and PICO SDK, you could also use the gpio_get_all(), gpio_put_all(). These two along with gpio_clr_mask(), gpio_set_mask(), gpio_xor_mask() functions access ALL the I/O pins as a single 32 bit value. In any case, your title is would be more correct as: "Python's Data Throughput On Raspberry Pi Pico".
@@montpierce424 you're right. As I discover more about the Pico, I'm learning about PIO; which makes it incredibly fast. Check out some of my more recent videos.
As I understand it; utime relies on a hardware real time clock, and time relies on a system supported clock. They do the same thing as long as you don't need the exact time of day; then you would have to set the system clock to the proper time and date first. Since the pico doesn't have a hardware real time clock; so I think they would do the exact same thing.
Hex vs Octal isn't determined by the preference of the user. It's determined by the architecture of the hardware. PDPx computers had 3 bit op codes and register numbers that lent them to use octal nomenclature. Intel, Motorola, etc., used 4 bit op codes that lent them to use hexadecimal. I worked with the person who had to write a cross assembler for the Motorola 6800 that ran on a PDP11. Writing code for 4 bit on a 3 bit computer was a big problem.
You're right. For those of us that "came of age" with smaller bus widths (8 bit) that had the instruction op code in one word, hexadecimal made sense. However when you combine the op code with data or addresses in larger word sizes, I can see where using a system that fits the size of the op code would be appropriate. Thanks for the insight!
@@LifewithDavid1 One of the first computers I programmed was the GE/PAC 4020 in the 1960s. It was a 24 bit computer with 6 bit op codes. I'll put a link to the manual in a reply because RUclips likes to delete non RUclips links.
@@WilliamBurlingame In the early 90's I did some troubleshooting and modifications to a Westinghouse Prodac 50; their answer to the PAC 4000 series. Very cool computer that was used to provide automatic startup and control for an early 70's 35MW Westinghouse combustion turbine/generator. BTW, I think RUclips beat you to it regarding the link. 😞
@@LifewithDavid1 Yes and I tried again by using (dot) in the URL and they caught that also. I worked for GE at the plant where they made the computers. After I left and went to Motorola, GE sold that facility in Phoenix to Honeywell.
I've just sat and watched all your Pico videos in the Raspberry Pi Pico playlist after being referred here by Ralph Bacon's video. I enjoyed them, but one comment, perhaps you could sort the videos in the playlist by chronological order, as I found it hard to follow given you don't have episode numbers in your titles. But thats just a nitpick, I like your presentation style.
Casting shade on octal, eh? Maybe hexadecimal is good for the 6502 instruction set, but in the 8080 and Z-80 instruction sets, most of the instructions have three fields, consisting of a 2-bit opcode followed by two 3-bit operands, which makes hand assembly into octal the most convenient base. Furthermore, translating octal into binary, to flip switches on a programming panel, is much more intuitive in octal. It just doesn't make sense to me, what "DB" is in binary (without a great deal of practice), because "D" and "B" don't even feel like numbers. This doesn't work so well for the 6502, because its instructions have their bitfields arranged differently, so that they don't map directly to octal fields. Which is why you see all 6502 opcode tables in hexadecimal. Kind of dumb, if you ask me, since MOS still used a 2-bit field and two 3-bit fields, but they were arranged as 3+3+2 instead of the more sensible 2+3+3. And the 6502 doesn't align well with 4-bit fields either, so hexadecimal doesn't really make sense either, and hand-assembling 6502 code always involves looking at a big chart. And you're right, the PDP-8 people prefer octal for the same reason the Z-80 people do, as do the PDP-10 people, since that machine used a 36-bit word, and for text that didn't require lower-case letters, packed characters in 6 bit fields, which of course can be represented by two octal digits each.
You're right, when I was hand programming a PDP-8S in school, octal worked fine; actually good. However, when I built my 6502 computer in 1975, I built a hardware keypad front panel that was simply just much easier to design in hex. You work in hex for almost 50 years on 8, 16, 32, and 64 bit machines and it becomes second nature (but I still have to look at what "C" converts to in binary if I've been away from machine language for a while, LOL).
@@BrightBlueJim Some early videos about my early computer adventures: ruclips.net/video/rxBV3YILaaM/видео.html ruclips.net/video/BcqRvHkn-EA/видео.html ruclips.net/video/BcqRvHkn-EA/видео.html
Yes you can. It shouldn't be too hard to write a PIO program. The bigger issue is the difference in signal voltages. I'm not sure if you can get quick enough rise times on the standard level converters. I noticed some pretty rounded "square wave" when I looked at them in my level converter video.
@@LifewithDavid1 I used to do 6502 hand coding when I first discovered computers with a Commodore PET. I should think 3.3v would be high enough to give you a logic 1 on a 5v 6502 system. The other way (5->3v), you can use a voltage divider with 2 resistors. 2k2 and 4k7. (Per pin). Unless pico is 5v tolerant, but I doubt it.
@@andyonions7864 When I designed and built 6502 computers in the mid 70's, I had reliability issues with the data lines that I eventually traced to low voltage. However the new chips could be little more voltage tolerant.
do not the_end - start, use ticks_diff to correctly calculate the difference see docs. micropython. org/en/latest/library/utime.html?highlight=tick#utime.ticks_diff with short code, please add it after your timetable, lets us test and maybe improve (when no extra hardware is required)
You are right if the time between the start and stop is greater than 100 seconds. However the time is much less than a second, so rollover isn't an issue. I did try it several times and the the results were exatly the same. However, I will try it with ticks_diff and see how it compares. Thanks!
Argh...You're right. I guess that is a real world example how we have to keep things straight! And to think that effect took 3 hours to edit. There were a couple issues with that segment so I just removed it.
Okay, can't go any further. You want to determine how fast you can put data through a Pico, and you choose Python as your programming language. We're done here.
OK, if you notice, this was episode 0.2. Things definitely got faster, check out my 20 episodes I did on PIO. I eventually got to making an arbitrary waveform generator that could synthesize a 7 mHz sine wave using PIO and DMA. I did a lot of learning in a year.
Thank you for making this video. I was curious and you showed me the answer for the Pico's data throughput.
You're welcome! Thanks for watching.
For performance sensitive application, i would definitely recommend programming it with Arduino C or just plain C, then I am sure it would be way faster.
You're right. And to make it even faster, use the PIO feature of the RP 2040. Check out my video (ruclips.net/video/dGNJGC_wZtk/видео.html) where I use PIO and MicroPython to achieve speeds much faster than the 6502 can handle.
Those who yield the power to slow Time always win.
👍
123 Decimal
173 Octal
7b Hex
1111011 Binary
{ UTF-8
That’s Fitting
Holds My 👍 Count.
JJ74
1111
I agree. Thanks.
I removed a segment that discusses Big and Little Endian because I got the definition backwards. Sorry.
If you really want speed, you need to access the IOPorts directly rather than through "function" calls. The problem with Arduino IDE, Python IDEs, etc, is they always only promote port access in bit function calls. On the Atmega328, you can access 8-bit ports just as if they are a local variable (i.e. SFRs), and in the Pico, you can access 32-bit ports in Single-Cycle IO Block. I haven't played with the Pico IO ports, but I know they are going to be 100s/1000s times faster than calling a function to read/write just 1 bit.... Check out the RP2040 Datasheet for details.
That sounds like something I'll have to look at. Right now, what I hooking the Pico up to is very slow, and I also think I'm going to to be speed limited with the level shifting hardware that I'm testing now.
@@LifewithDavid1 I don't know if it's available in Python... But with C and PICO SDK, you could also use the gpio_get_all(), gpio_put_all(). These two along with gpio_clr_mask(), gpio_set_mask(), gpio_xor_mask() functions access ALL the I/O pins as a single 32 bit value.
In any case, your title is would be more correct as: "Python's Data Throughput On Raspberry Pi Pico".
@@montpierce424 you're right. As I discover more about the Pico, I'm learning about PIO; which makes it incredibly fast. Check out some of my more recent videos.
I wonder why the datasheet says to use 'time' but other places say to use 'utime'.
As I understand it; utime relies on a hardware real time clock, and time relies on a system supported clock. They do the same thing as long as you don't need the exact time of day; then you would have to set the system clock to the proper time and date first. Since the pico doesn't have a hardware real time clock; so I think they would do the exact same thing.
Hex vs Octal isn't determined by the preference of the user. It's determined by the architecture of the hardware. PDPx computers had 3 bit op codes and register numbers that lent them to use octal nomenclature. Intel, Motorola, etc., used 4 bit op codes that lent them to use hexadecimal. I worked with the person who had to write a cross assembler for the Motorola 6800 that ran on a PDP11. Writing code for 4 bit on a 3 bit computer was a big problem.
You're right. For those of us that "came of age" with smaller bus widths (8 bit) that had the instruction op code in one word, hexadecimal made sense. However when you combine the op code with data or addresses in larger word sizes, I can see where using a system that fits the size of the op code would be appropriate. Thanks for the insight!
@@LifewithDavid1 One of the first computers I programmed was the GE/PAC 4020 in the 1960s. It was a 24 bit computer with 6 bit op codes. I'll put a link to the manual in a reply because RUclips likes to delete non RUclips links.
@@WilliamBurlingame In the early 90's I did some troubleshooting and modifications to a Westinghouse Prodac 50; their answer to the PAC 4000 series. Very cool computer that was used to provide automatic startup and control for an early 70's 35MW Westinghouse combustion turbine/generator. BTW, I think RUclips beat you to it regarding the link. 😞
@@LifewithDavid1 Yes and I tried again by using (dot) in the URL and they caught that also. I worked for GE at the plant where they made the computers. After I left and went to Motorola, GE sold that facility in Phoenix to Honeywell.
I've just sat and watched all your Pico videos in the Raspberry Pi Pico playlist after being referred here by Ralph Bacon's video. I enjoyed them, but one comment, perhaps you could sort the videos in the playlist by chronological order, as I found it hard to follow given you don't have episode numbers in your titles. But thats just a nitpick, I like your presentation style.
Thank you! You're right, I don't have episode numbers in my titles. I'll add them as soon as I can. Thanks for the feedback, and thanks for watching!
see the pico git pio 10 megabit/s Manchester encoding example
Casting shade on octal, eh? Maybe hexadecimal is good for the 6502 instruction set, but in the 8080 and Z-80 instruction sets, most of the instructions have three fields, consisting of a 2-bit opcode followed by two 3-bit operands, which makes hand assembly into octal the most convenient base. Furthermore, translating octal into binary, to flip switches on a programming panel, is much more intuitive in octal. It just doesn't make sense to me, what "DB" is in binary (without a great deal of practice), because "D" and "B" don't even feel like numbers.
This doesn't work so well for the 6502, because its instructions have their bitfields arranged differently, so that they don't map directly to octal fields. Which is why you see all 6502 opcode tables in hexadecimal. Kind of dumb, if you ask me, since MOS still used a 2-bit field and two 3-bit fields, but they were arranged as 3+3+2 instead of the more sensible 2+3+3. And the 6502 doesn't align well with 4-bit fields either, so hexadecimal doesn't really make sense either, and hand-assembling 6502 code always involves looking at a big chart.
And you're right, the PDP-8 people prefer octal for the same reason the Z-80 people do, as do the PDP-10 people, since that machine used a 36-bit word, and for text that didn't require lower-case letters, packed characters in 6 bit fields, which of course can be represented by two octal digits each.
You're right, when I was hand programming a PDP-8S in school, octal worked fine; actually good. However, when I built my 6502 computer in 1975, I built a hardware keypad front panel that was simply just much easier to design in hex. You work in hex for almost 50 years on 8, 16, 32, and 64 bit machines and it becomes second nature (but I still have to look at what "C" converts to in binary if I've been away from machine language for a while, LOL).
@@LifewithDavid1 Ah, it's all about that first home-built machine, isn't it?! My first (1978) was a Z-80 with a TTL bitmapped graphics chain.
@@BrightBlueJim Some early videos about my early computer adventures: ruclips.net/video/rxBV3YILaaM/видео.html
ruclips.net/video/BcqRvHkn-EA/видео.html
ruclips.net/video/BcqRvHkn-EA/видео.html
@@BrightBlueJim BTW, I apologize for my "amateur" early videos. I'm not a pro like you. Your editing video was great!
I'd have thought this is what PIO is for. You can gang consecutive pins together can't you?
Yes you can. It shouldn't be too hard to write a PIO program. The bigger issue is the difference in signal voltages. I'm not sure if you can get quick enough rise times on the standard level converters. I noticed some pretty rounded "square wave" when I looked at them in my level converter video.
@@LifewithDavid1 I used to do 6502 hand coding when I first discovered computers with a Commodore PET. I should think 3.3v would be high enough to give you a logic 1 on a 5v 6502 system. The other way (5->3v), you can use a voltage divider with 2 resistors. 2k2 and 4k7. (Per pin). Unless pico is 5v tolerant, but I doubt it.
@@andyonions7864 When I designed and built 6502 computers in the mid 70's, I had reliability issues with the data lines that I eventually traced to low voltage. However the new chips could be little more voltage tolerant.
do not the_end - start, use ticks_diff to correctly calculate the difference
see docs. micropython. org/en/latest/library/utime.html?highlight=tick#utime.ticks_diff
with short code, please add it after your timetable, lets us test and maybe improve (when no extra hardware is required)
You are right if the time between the start and stop is greater than 100 seconds. However the time is much less than a second, so rollover isn't an issue. I did try it several times and the the results were exatly the same. However, I will try it with ticks_diff and see how it compares. Thanks!
You switched Big and Little Endian.
Argh...You're right. I guess that is a real world example how we have to keep things straight! And to think that effect took 3 hours to edit. There were a couple issues with that segment so I just removed it.
Okay, can't go any further. You want to determine how fast you can put data through a Pico, and you choose Python as your programming language. We're done here.
OK, if you notice, this was episode 0.2. Things definitely got faster, check out my 20 episodes I did on PIO. I eventually got to making an arbitrary waveform generator that could synthesize a 7 mHz sine wave using PIO and DMA. I did a lot of learning in a year.
@@LifewithDavid1 Then I will definitely look at your more recent posts!