The 1st example was crystal clear: GCB produced much faster and more compact code. I’m not sure what your video proves. Can you summarize?
Joe
From: stan cartwright
Sent: Monday, April 24, 2017 12:02 PM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] pic vs uno test
Hi all. I had a post about a youtube video and the question of is a pic faster than a mega328p so here's the video link https://www.youtube.com/watch?v=qdloFhULa3I&t=2s and a short video I did.https://youtu.be/StHDP3r28JY My narration isn't Attenbourough and meant 1.23 Khz not MHz.
By the way the pic header was #chip 18f25k22 ,16 and #chip mega328p, 16
The code was-
#chip mega328p, 16 ;---- OR #chip 18f25k22, 16
#option explicit
dim count as byte
dir portb.0 out
do
count=0
portb.0=not portb.0
do until count>250
count++
loop
loop
Last edit: stan cartwright 2017-04-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By leaving out the ,16 you are telling the compiler to use the internal clock at the chip's maximum speed rather than crippling it to 16Mhz.
The two chip architectures are vastly different in the way they handle the clock so a 16MHz Arduino can not be equated to a 16MHz PIC. To be fair both devices should be run at the default speed which is 16MHz for Arduino (it's Max) and 32MHz for the PIC you specified.
Cheers
Chris
p.s. You said: "Forget it....but my robot will never play the violin again :( "
I reply: "That is because it is an Electric Violin and you have no rosin on your Bow leaving the Robot in a state of flux. :) "
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.How are you Chris? I tried #chip 18f25k22 and it's the same as #chip 18f25k22, 16
so I tried #chip 18f25k22, 32--osc=int and the uno was still faster pic32.jpg then #chip 18f25k22, 64--osc=int and the pic was faster pic64.jpg
so...what's new?
Now we can draw some practical conclusions from it.
Low end PICs (8-bit) run at 1 instruction every 4 clock cycles. AVR runs at 1 instruction every clock cycle (or thereabouts - some instructions take 2 cycles).
So at 16MHz on an AVR you get about 16 MIPS. On a PIC you get 4 MIPS. Having said that, though, PIC tends to have the ability to run at much higher clock speeds - up to 64MHz in some cases.
So from a purely clocking POV then the AVR is faster at the same frequency.
The AVR has more internal registers, too, compared with the 8-bit PIC's single W register, which makes code somewhat more efficient.
What AVR doesn't have is the choice. They have a handful of devices, at a price considerably higher than the equivalent PIC and Atmel have already announced that newer devices will not br avalable in DIP packaging.
With PIC the choice of devices you have is so great you can bet there will be one that pretty much precisely fits your needs, saving you both money and power.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How fast a port can be toggled only tells part of the speed story when comparing different microcontrollers and different chip architectures.
AVRs are generally "faster" than a similar PIC in regards to I/O operations given the same system clock speed. ie. 16Mhz Vs 16Mhz. This becasue of a difference in architecures.
But we do more with microcontrollers than toggle I/0 Pins. We use the chips internal peripherals, and connect to external devices to build an application that meets certain specifications. As long as the specifications are meet (including cost) it does not really matter what chip is used. You don't need 100 MIPS to control a microwave oven or to drive a 16X 2 Character LCD.
Now compare AVR and PIC 10-bit ADC acquisiton times and see what you get.
Last edit: William Roth 2017-04-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The test was suggested by the poster of the original compiler comparison and was interesting although certainly not complete like my comparison isn't but it was interesting. The mega328p can be clocked at 20MHz but in GCB didn't show any difference to 16MHz.
It's like comparing 6502-pic and Z80-avr. the 328 has a bigger instruction set than a pic which microchip boast only 40 odd instructions to learn. I programmed 6502 and z80,popular at the time.
The z80 clocked higher and had hardware block mem move-ld hl,source ld de,destination ld bc,number of bytes-ldir
The 6502 with less instructions and clock was fast though in different ways. The block mem move in software would be comparable in say refreshing screen ram with new data.
It's an open discussion so I thought I'd post it. I have no preference for pic or avr as brand names as they're both the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't like the Z80 or the 6502 and followed the Motorola route - the 6809 was my weapon of choice. I guess, though I was technically correct, I backed the wrong horse and the PC industry went with the z80 and its descendants at intel and the Microcontroller industry backed the 6502 Core IP - That is what the core of the AVR is. The PIC is actually a RISC core on Harvard architecture so a completely separate development path to all of the above but my favorite device now in its Enhanced Core Form :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A "compiler comparison" should be done on the same exact chip operating at the same clock speed. with the same code. Thus it is not really possible to precisely compare Arduino "Wiring C" and its compiler on an UNO Great Cow Basic and it compiler on the same UNO becasue the code will be different, But like Chuck did in his video we can make the code as close to the same as possible.
The Arduino "fanboys" usually cry "foul'' on these kind of tests because they think a more fair comparison would be to use lower level C constructs with Arduino instead of the high level and bloated "Arduino Language" that doe not compile efficiently. But we are not comparing native C to GCB. We are comparing the Arduino Language to the Great Cow Basic Language. (Which GCB will always win)
If we compare native C with the UNO to GCB there will not be much difference at all.
Did you know?
In GCB with an UNO R3, setting the ChipMHz with #Chip mega328p, 16 does not change the clock speed. The 16 only tells the GCB compiler how to calculate delay times, baud rates,etc based upon the clock speed setup with the "fuses" in the Arduino Bootloader. Changing the ChipMhz to anything other than "16" will likely cause inaccurate delays and inacurate baud rates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know much about GCB yet. It was suggested to investigate pic vs uno. I don't know what a 18f25k22 does that a 16f678 doesn't except clock speed and one's enhanced core but don't know if GCB optimises enhanced features. I'm totally plank but like playing around and I suppose learning along the way.
My intentions were first pic but found uno don't need vero and stuff to use,don't even need a programmer and is a neat unit. The 328 on the board is fine for a lot of things.
I'm not pro arduino or anti and wonder why the Chinese ones that use the usb chip that bricks stuff haven't been reported as bricked arduino. Like the made in Italy ones with a dil socketed chip use the same usb chip. Only with win 10 updates? I use 10 and 7. Now when did I last plug a uno into win 10??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
William understands the point of my video. So many beginners use Arduino and think its better/faster than anything written in BASIC because the Arduino uses C language. What they fail to understand is the libraries that are created to make programming easier for Arduino also are very in-efficient for both speed and code space. So it has nothing to do with C vs BASIC is has everything to do with the compiler. Most home 3D printers are run by Arduinos with Marlin code written in Arduino. My example just showed if you rely on the High/Low style commands, Arduino is pretty slow. Fortunately Marlin has been optimized to drive ports directly as much as possible to speed things up. Some are claiming 3D printers have to move to 32bit to get any kind of performance upgrade. I'm not saying that isn't an option but 8-bit is not the only limitation. Code is a factor.
Now if you program an Arduino module with GCB like Stan did and then compare that to a PIC programmed in GCB then that is a different example altogether. AVR and PIC both have their advantages but the ability to program either one with one compiler (aka GCB) is something I have not seen anywhere else. That's a major feature of GCB.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Chuck. well said. I got into GCB with the intention of programming pics but found the same code worked on avr and a uno board was so simple to set up and programme compared to a pic chip, I used that first.
I've reposted that video really to show that I can program avr faster in gcbasic than c and that option is little known from feed back it seems.
A 3d printer is on my wish list :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've the same ILI9341 display and the same "oscilloscope" display a-d port code and changing the chip header the results look the same with pic clocked at 64. What would be a fair test. Is there a fair test?
Is there a point to all this ?? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course - always interested. Whilst just changing the header is the design goal of Great Cow BASIC there is a lot is going on beneath the covers. So, my thougths on creating a level playing field from a user perspective of the two architectures.
I'll test any suggestions. Pic and Avr are different.Instruction set and hardware. pic is 16 mips but avr is 1mips per MHz clock and 328p can be 20 MHZ..in GCB?
Then I'm comparing using GCB which is another complication.
Which pic to compare? Do what, draw circles and inc a count for 60 seconds and see how many circles have been drawn? Would that just be a speed test of drawing circles? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all. I had a post about a youtube video and the question of is a pic faster than a mega328p so here's the video link https://www.youtube.com/watch?v=qdloFhULa3I&t=2s and a short video I did. https://www.youtube.com/watch?v=StHDP3r28JY&feature=youtu.be My narration isn't Attenbourough and meant 1.23 Khz not MHz.
Last edit: stan cartwright 2017-04-24
Dave
The 1st example was crystal clear: GCB produced much faster and more compact code. I’m not sure what your video proves. Can you summarize?
Joe
From: stan cartwright
Sent: Monday, April 24, 2017 12:02 PM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] pic vs uno test
Hi all. I had a post about a youtube video and the question of is a pic faster than a mega328p so here's the video link https://www.youtube.com/watch?v=qdloFhULa3I&t=2s and a short video I did.https://youtu.be/StHDP3r28JY My narration isn't Attenbourough and meant 1.23 Khz not MHz.
pic vs uno test
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gcbasic/discussion/579125/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
By the way the pic header was #chip 18f25k22 ,16 and #chip mega328p, 16
The code was-
#chip mega328p, 16 ;---- OR #chip 18f25k22, 16 #option explicit dim count as byte dir portb.0 out do count=0 portb.0=not portb.0 do until count>250 count++ loop loopLast edit: stan cartwright 2017-04-24
ps Why does portb.0=xor portb.0 give errors when compiling?
Cheers Guys.
New posting on this please
re speed test is dual scope, pic at top and uno at bottom for same code.
Try defining it as
. #chip 18f25k22
By leaving out the ,16 you are telling the compiler to use the internal clock at the chip's maximum speed rather than crippling it to 16Mhz.
The two chip architectures are vastly different in the way they handle the clock so a 16MHz Arduino can not be equated to a 16MHz PIC. To be fair both devices should be run at the default speed which is 16MHz for Arduino (it's Max) and 32MHz for the PIC you specified.
Cheers
Chris
p.s. You said: "Forget it....but my robot will never play the violin again :( "
I reply: "That is because it is an Electric Violin and you have no rosin on your Bow leaving the Robot in a state of flux. :) "
Hi.How are you Chris? I tried #chip 18f25k22 and it's the same as #chip 18f25k22, 16
so I tried #chip 18f25k22, 32--osc=int and the uno was still faster pic32.jpg then #chip 18f25k22, 64--osc=int and the pic was faster pic64.jpg
so...what's new?
1 picture at a time sorry
I am good thanks Stan,
Interesting experiment.
Now we can draw some practical conclusions from it.
Low end PICs (8-bit) run at 1 instruction every 4 clock cycles. AVR runs at 1 instruction every clock cycle (or thereabouts - some instructions take 2 cycles).
So at 16MHz on an AVR you get about 16 MIPS. On a PIC you get 4 MIPS. Having said that, though, PIC tends to have the ability to run at much higher clock speeds - up to 64MHz in some cases.
So from a purely clocking POV then the AVR is faster at the same frequency.
The AVR has more internal registers, too, compared with the 8-bit PIC's single W register, which makes code somewhat more efficient.
What AVR doesn't have is the choice. They have a handful of devices, at a price considerably higher than the equivalent PIC and Atmel have already announced that newer devices will not br avalable in DIP packaging.
With PIC the choice of devices you have is so great you can bet there will be one that pretty much precisely fits your needs, saving you both money and power.
Cheers
Chris
How fast a port can be toggled only tells part of the speed story when comparing different microcontrollers and different chip architectures.
AVRs are generally "faster" than a similar PIC in regards to I/O operations given the same system clock speed. ie. 16Mhz Vs 16Mhz. This becasue of a difference in architecures.
But we do more with microcontrollers than toggle I/0 Pins. We use the chips internal peripherals, and connect to external devices to build an application that meets certain specifications. As long as the specifications are meet (including cost) it does not really matter what chip is used. You don't need 100 MIPS to control a microwave oven or to drive a 16X 2 Character LCD.
Now compare AVR and PIC 10-bit ADC acquisiton times and see what you get.
Last edit: William Roth 2017-04-25
The test was suggested by the poster of the original compiler comparison and was interesting although certainly not complete like my comparison isn't but it was interesting. The mega328p can be clocked at 20MHz but in GCB didn't show any difference to 16MHz.
It's like comparing 6502-pic and Z80-avr. the 328 has a bigger instruction set than a pic which microchip boast only 40 odd instructions to learn. I programmed 6502 and z80,popular at the time.
The z80 clocked higher and had hardware block mem move-ld hl,source ld de,destination ld bc,number of bytes-ldir
The 6502 with less instructions and clock was fast though in different ways. The block mem move in software would be comparable in say refreshing screen ram with new data.
It's an open discussion so I thought I'd post it. I have no preference for pic or avr as brand names as they're both the same.
I didn't like the Z80 or the 6502 and followed the Motorola route - the 6809 was my weapon of choice. I guess, though I was technically correct, I backed the wrong horse and the PC industry went with the z80 and its descendants at intel and the Microcontroller industry backed the 6502 Core IP - That is what the core of the AVR is. The PIC is actually a RISC core on Harvard architecture so a completely separate development path to all of the above but my favorite device now in its Enhanced Core Form :)
A "compiler comparison" should be done on the same exact chip operating at the same clock speed. with the same code. Thus it is not really possible to precisely compare Arduino "Wiring C" and its compiler on an UNO Great Cow Basic and it compiler on the same UNO becasue the code will be different, But like Chuck did in his video we can make the code as close to the same as possible.
The Arduino "fanboys" usually cry "foul'' on these kind of tests because they think a more fair comparison would be to use lower level C constructs with Arduino instead of the high level and bloated "Arduino Language" that doe not compile efficiently. But we are not comparing native C to GCB. We are comparing the Arduino Language to the Great Cow Basic Language. (Which GCB will always win)
If we compare native C with the UNO to GCB there will not be much difference at all.
Did you know?
In GCB with an UNO R3, setting the ChipMHz with #Chip mega328p, 16 does not change the clock speed. The 16 only tells the GCB compiler how to calculate delay times, baud rates,etc based upon the clock speed setup with the "fuses" in the Arduino Bootloader. Changing the ChipMhz to anything other than "16" will likely cause inaccurate delays and inacurate baud rates.
I don't know much about GCB yet. It was suggested to investigate pic vs uno. I don't know what a 18f25k22 does that a 16f678 doesn't except clock speed and one's enhanced core but don't know if GCB optimises enhanced features. I'm totally plank but like playing around and I suppose learning along the way.
My intentions were first pic but found uno don't need vero and stuff to use,don't even need a programmer and is a neat unit. The 328 on the board is fine for a lot of things.
I'm not pro arduino or anti and wonder why the Chinese ones that use the usb chip that bricks stuff haven't been reported as bricked arduino. Like the made in Italy ones with a dil socketed chip use the same usb chip. Only with win 10 updates? I use 10 and 7. Now when did I last plug a uno into win 10??
William understands the point of my video. So many beginners use Arduino and think its better/faster than anything written in BASIC because the Arduino uses C language. What they fail to understand is the libraries that are created to make programming easier for Arduino also are very in-efficient for both speed and code space. So it has nothing to do with C vs BASIC is has everything to do with the compiler. Most home 3D printers are run by Arduinos with Marlin code written in Arduino. My example just showed if you rely on the High/Low style commands, Arduino is pretty slow. Fortunately Marlin has been optimized to drive ports directly as much as possible to speed things up. Some are claiming 3D printers have to move to 32bit to get any kind of performance upgrade. I'm not saying that isn't an option but 8-bit is not the only limitation. Code is a factor.
Now if you program an Arduino module with GCB like Stan did and then compare that to a PIC programmed in GCB then that is a different example altogether. AVR and PIC both have their advantages but the ability to program either one with one compiler (aka GCB) is something I have not seen anywhere else. That's a major feature of GCB.
Hi Chuck. well said. I got into GCB with the intention of programming pics but found the same code worked on avr and a uno board was so simple to set up and programme compared to a pic chip, I used that first.
I've reposted that video really to show that I can program avr faster in gcbasic than c and that option is little known from feed back it seems.
A 3d printer is on my wish list :)
I've the same ILI9341 display and the same "oscilloscope" display a-d port code and changing the chip header the results look the same with pic clocked at 64. What would be a fair test. Is there a fair test?
Is there a point to all this ?? :)
Of course - always interested. Whilst just changing the header is the design goal of Great Cow BASIC there is a lot is going on beneath the covers. So, my thougths on creating a level playing field from a user perspective of the two architectures.
Recommend that you optimise the code using the Great Cow BASIC ADC optimisation shown in the Help. Why? The ADC methods for PIC can be optimised where the AVR ADC methods are optimised. See http://gcbasic.sourceforge.net/help/_analog_digital_conversion_code_optimisation.html for details of optimisation.
You may want to set a standard test signal for both devices the PIC and the AVR.
You may want to have your code peer reviewed prior to testing. Then, folks get the chase to correct what 'they think' creates a level playing field.
I'll test any suggestions. Pic and Avr are different.Instruction set and hardware. pic is 16 mips but avr is 1mips per MHz clock and 328p can be 20 MHZ..in GCB?
Then I'm comparing using GCB which is another complication.
Which pic to compare? Do what, draw circles and inc a count for 60 seconds and see how many circles have been drawn? Would that just be a speed test of drawing circles? :)