I dont know, but is it because the LCD controller not in sync with the date?? I am not sure I had this problem, when i try to refresh an image, I wasnt sure how fast I can do this
@cremulus I am getting bored talking with you, at least about your video... your answer is just arrogant, and thats the thing you criticize in the last post... I just dont like your video, and thats all... your arguments are not sufficient for me to state this comparison to be valid or to make sense... just that! Just relax, I dont have anything against you, it is just about your video, no more...
@alejoPusto I don't want an argument either, but before accusing me of arrogance (when I was actually being sarcastic, tsk) you might want to consider how easily I could accuse you of that if I was so inclined... But I'm not, it is my experience that those who accuse others of arrogance often do so because they recognise it in themselves and despise it there.
As for you not liking the video - aw... you'll hurt its feelings. But not mine, I think facts count far more than opinions.
@cremulus, fair enough what you say on what "better" means in terms of costs, power, tools, etc, etc. But your video just mentioned you where using a 32 bit arch. vs a 8 bit arch, and you also mentioned the frequencies. You didnt say your requirements where price, power, etc, etc. I really dont care about this, is just a video which for me is nonsense, perhaps for my experience in embedded systems. Please remember there is no need to treat people as stupid just because they think different.
If we must... I started in 1978, and have designed everything from toys costing pennies to avionics/scientific instruments that cost over a million dollars.
> Please remember there is no need to treat people as stupid just
> because they think different.
Have you *any* idea how ironic that remark seems to me? I've had nothing but utterly stupid responses to this video by people who don't appear to think at all!
[muses] Speaking as someone who has designed hundreds of products using both PIC and AVR (and lots of others) - and manufactured them in volume - I'm disappointed at the extent of the ignorance being shown here - any *competent* designer will consider far more than clock speed and bus width before choosing a device - don't get hung up on particular architectures if you want to design efficiently - every application offers different challenges and opportunities and some suit different devices.
If you get into the childish mindset of using a PIC instead of an AVR, or C instead of assembler because somebody else said it was a good idea for some application or other - then you're a prize moron and no better than a programmer, because that's the sort of non-thinking blind stupidity they engage in. Hardware designers should damned-well care about facts and not opinions!
Choices have consequences - learn them. Don't guess. Don't make assumptions you can't or won't test... Learn your trade.
It wasn't C#, it was straightforward C. Which can also suck as far as efficiency goes, though few programmers know quite how badly.
The point here is that using C on the PIC isn't a disaster because that architecture better suits compilers and the hardware has enough raw performance to max out the LCD controller even using inefficient C. The 8-bit AVR hasn't and would need to use assembler to match it - if I'd been designing a commercial product I might have done that; many of my designs do.
@cremulus I don't know the difference between Cs much :) As for the PICs, yep - only one MCU register and direct SRAM access from ALU is faster for compiled programs while the register management is a great performance booster on AVRs yet needs the knowledge of where the bottleneck is. For example, LCDs are faster to control should you reserve two registers for clock status (conserves two clocks compared to cbi/sbi). Btw compiler LOL: seen an Y-stack as a default one once. why...?!
@TheBypasser Yes, some of the things I've seen compiled code doing are too insane to describe; truly it is said that the ways of compiler-writers passeth human understanding.
Mind you, I should know - written quite a few compilers in my time... some very good and some, it has to be admitted, very lazy.
Having said that, remember that the pic32 is a MIPS architecture and has lots of registers; the GCC C compiler for MIPS has a long history and the code it generates is pretty good.
This video was not made to compare architectures, nor was it intended for anyone but the people involved in the original conference to see, who knew what the comparison was all about. So please stop making idiotic remarks about it not comparing things that were not being discussed in that thread - which were specifically an AtMega128 vs a pic32mx.
The idea was to show someone how much better off he'd be with the pic32mx. We're all aware there are other options but they weren't being discussed.
People, I've just about reached my limit for stupidity... If you don't understand what is going on here then don't comment on it - this video doesn't compare a 32 bit AVR for exactly the same reason it doesn't compare a Z80 or a PDP-11... the two devices that were being discussed at the time I made it - in an electronics conference - were an 8-bit AVR and a 32-bit PIC, driving this exact display - so this video was made to show someone how much faster the PIC would be...
You are comparing a 32 bits micro processor (PIC) vs an 8 bits micro processor (AVR) there is no point of comparisson, ATxmega it´s a 8 bit proccesor too
To be fair let´s compare a 32 bits AVR(The ARM SAM9 series) vs a 32 bits PIC, and I´m sure AVR is going to be the better one
As I said before, I'm comparing these two devices because they were the two devices that were being discussed in a conference elsewhere. The point is to show how much faster one is than the other - I don't actually understand what's so difficult to grasp about that process.
With all respect, IMHO this is a non-sense comparisson. AVR is a 8-bit CPU, PIC32 is a 32-bit CPU, and they are also running at far different frequencies. So, whats the point????
@alejoPusto I am a teacher and the point is teachers try to teach 8-bit microcontrollers when 32-bit ones are already available... most of them don't have the nerves to study new chips, sooo students get useless knowledge. What is worse they justify usage of old microcontrollers on many conferences... Sooo i think this video makes a GOOD point.
@71GA I am a teacher too, and in fact the comparison is useless because I am sure you dont need to see this video in order to state the fact that a 32-bit processor will run faster than an 8-bit one! Of course it will, given that frequencies! I think we should not teach our students some specific architecture, rather, we should teach them the concepts to be applied in any architecture, say 8-bit or 16-bit or 32-bit, or ... it doesnt matter!
@71GA I am a teacher too, and in fact the comparison is useless because I am sure you dont need to see this video in order to state the fact that a 32-bit processor will run faster than an 8-bit one! Of course it will, given that frequencies! I think we should not teach our students some specific architecture, rather, we should teach them the concepts to be applied in any architecture, say 8-bit or 16-bit or 32-bit, or ... it doesnt matter!
@alejoPusto The point was that a friend of mine was using an 8-bit AVR to drive this display and I wanted to show them how much better off they would be using the pic32...
It's easy to _guess_ that it would be at least a factor of ten faster, just from the relative clocks, but to show him just how much faster that 'feels' in practice I videoed the two side by side... Surely this isn't hard to grasp? A simple demonstration made things clearer than any amount of text.
@cremulus There is surely no need to take the time to port your code to PIC32 or write a long text in order to simply explain that a 32-bit architecture, running 10 times faster, will be better than an 8-bit architecture. Surely this isnt hard to grasp ;).... However your video generated such a controversy that I really find amusing... keep the work, indeed your video can be a very direct example to people who just want to test 32-bit vs. 8-bit architectures... although this sounds dumb for me..
@alejoPusto Well, as you don't have access to the original conference or know any of the people and their attitudes you aren't in any position to judge how useful that simple demonstration was. As this thread amply demonstrates, no matter how clearly something is expressed in text there will always be people too arrogant or stupid to understand it.
And as for "take the time" - I closed one development tool, opened another, changed a few lines of source code and compiled... Not long.
@alejoPusto It might not be hard, but few here have shown any sign that they grasp that "better" depends on price, power, package, available tools, experience, hardware port characteristics - and lots of other factors - not just a simplistic comparison of clock speed and bus width.
In this case using more efficient code the 8-bit AVR could write data to the LCD as fast as the LCD can handle it, and the 32-bit PIC could not then do any better despite the clock and bus width. [shrug]
They're both running pretty much the same crayon (GCC C) source code. If the AVR was coded in assembler it'd go about three times faster. There's less scope for increasing the speed of the pic32 because it's already getting close to driving the LCD as fast as it can accept data.
Sorry, people, didn't notice the comments. Off the top of my head it was a Mega128 running at 8MHz (fastest it'd go at 3.3V) and a picMX6xx of some flavour or other running at 80MHz, but it doesn't make much difference which pic32.
I'm comparing these two because they were the two under discussion at the time in a conference.
That's the point exactly. Beside that I'm also a PIC32 fan, I must admit this comparison is far from fair. For example even ATxmega can run at 32MHz@3.3V, or speaking of a better competitior, any of the AVR32 UC3A series can be clocked at 66MHz giving ~90DMIPS. And more or less both are in the same price segment.
They're running the same code, it redraws a screenful of text 16 times using increasing brightness with one form of character set storage and then does it again 16 times using another. Then the screen is then cleared three times by writing to each pixel with green/blue/red and the cycle repeats.
I dont know, but is it because the LCD controller not in sync with the date?? I am not sure I had this problem, when i try to refresh an image, I wasnt sure how fast I can do this
TheMasterAbdul 2 days ago
@cremulus I am getting bored talking with you, at least about your video... your answer is just arrogant, and thats the thing you criticize in the last post... I just dont like your video, and thats all... your arguments are not sufficient for me to state this comparison to be valid or to make sense... just that! Just relax, I dont have anything against you, it is just about your video, no more...
alejoPusto 2 days ago
@alejoPusto I don't want an argument either, but before accusing me of arrogance (when I was actually being sarcastic, tsk) you might want to consider how easily I could accuse you of that if I was so inclined... But I'm not, it is my experience that those who accuse others of arrogance often do so because they recognise it in themselves and despise it there.
As for you not liking the video - aw... you'll hurt its feelings. But not mine, I think facts count far more than opinions.
cremulus 2 days ago
@cremulus, fair enough what you say on what "better" means in terms of costs, power, tools, etc, etc. But your video just mentioned you where using a 32 bit arch. vs a 8 bit arch, and you also mentioned the frequencies. You didnt say your requirements where price, power, etc, etc. I really dont care about this, is just a video which for me is nonsense, perhaps for my experience in embedded systems. Please remember there is no need to treat people as stupid just because they think different.
alejoPusto 2 days ago
@alejoPusto
>perhaps for my experience in embedded systems.
If we must... I started in 1978, and have designed everything from toys costing pennies to avionics/scientific instruments that cost over a million dollars.
> Please remember there is no need to treat people as stupid just
> because they think different.
Have you *any* idea how ironic that remark seems to me? I've had nothing but utterly stupid responses to this video by people who don't appear to think at all!
cremulus 2 days ago
[muses] Speaking as someone who has designed hundreds of products using both PIC and AVR (and lots of others) - and manufactured them in volume - I'm disappointed at the extent of the ignorance being shown here - any *competent* designer will consider far more than clock speed and bus width before choosing a device - don't get hung up on particular architectures if you want to design efficiently - every application offers different challenges and opportunities and some suit different devices.
cremulus 2 days ago
If you get into the childish mindset of using a PIC instead of an AVR, or C instead of assembler because somebody else said it was a good idea for some application or other - then you're a prize moron and no better than a programmer, because that's the sort of non-thinking blind stupidity they engage in. Hardware designers should damned-well care about facts and not opinions!
Choices have consequences - learn them. Don't guess. Don't make assumptions you can't or won't test... Learn your trade.
cremulus 2 days ago
It shows that you get much more bang for your buck with pic than avr
draftube 4 days ago
Btw the overall performance is low because C# sucks :P Grow up, MCUs are not PCs so no need in pointless compilers. Use ASM and see the difference.
TheBypasser 1 week ago
It wasn't C#, it was straightforward C. Which can also suck as far as efficiency goes, though few programmers know quite how badly.
The point here is that using C on the PIC isn't a disaster because that architecture better suits compilers and the hardware has enough raw performance to max out the LCD controller even using inefficient C. The 8-bit AVR hasn't and would need to use assembler to match it - if I'd been designing a commercial product I might have done that; many of my designs do.
cremulus 2 days ago
@cremulus I don't know the difference between Cs much :) As for the PICs, yep - only one MCU register and direct SRAM access from ALU is faster for compiled programs while the register management is a great performance booster on AVRs yet needs the knowledge of where the bottleneck is. For example, LCDs are faster to control should you reserve two registers for clock status (conserves two clocks compared to cbi/sbi). Btw compiler LOL: seen an Y-stack as a default one once. why...?!
TheBypasser 2 days ago
@TheBypasser Yes, some of the things I've seen compiled code doing are too insane to describe; truly it is said that the ways of compiler-writers passeth human understanding.
Mind you, I should know - written quite a few compilers in my time... some very good and some, it has to be admitted, very lazy.
Having said that, remember that the pic32 is a MIPS architecture and has lots of registers; the GCC C compiler for MIPS has a long history and the code it generates is pretty good.
cremulus 2 days ago
This video was not made to compare architectures, nor was it intended for anyone but the people involved in the original conference to see, who knew what the comparison was all about. So please stop making idiotic remarks about it not comparing things that were not being discussed in that thread - which were specifically an AtMega128 vs a pic32mx.
The idea was to show someone how much better off he'd be with the pic32mx. We're all aware there are other options but they weren't being discussed.
cremulus 3 weeks ago
People, I've just about reached my limit for stupidity... If you don't understand what is going on here then don't comment on it - this video doesn't compare a 32 bit AVR for exactly the same reason it doesn't compare a Z80 or a PDP-11... the two devices that were being discussed at the time I made it - in an electronics conference - were an 8-bit AVR and a 32-bit PIC, driving this exact display - so this video was made to show someone how much faster the PIC would be...
cremulus 3 weeks ago
This has been flagged as spam show
hi, could you tell me if you have to send images to lcd non stop or you just have to send it once and it stay's in the lcd ? thanks.
wytis 1 month ago
И что к чему? У PIC32 80 Мгц, а у AVR'а 8 МГц. Смысл сравнивать микроконтроллеры с разной частотой?!
Slavik763 2 months ago
@Slavik763 ... и тем более с разной разрядностью. Сравнили бы свой пик с ATSAM4S16. Посмотрели бы кто кого.
IvanHighCity 2 weeks ago
PARTY HARD!!1
WaleraRigid 4 months ago
@WaleraRigid heheh lol
Intosia 3 months ago
PIC32? vs ATMEGA 8 bits????... jajaja There's AVR 32-bit, if it comes to comparative should not have disadvantage
dieguibulin730256 4 months ago
AVRaped™
spinctah 4 months ago
This is so stupid
You are comparing a 32 bits micro processor (PIC) vs an 8 bits micro processor (AVR) there is no point of comparisson, ATxmega it´s a 8 bit proccesor too
To be fair let´s compare a 32 bits AVR(The ARM SAM9 series) vs a 32 bits PIC, and I´m sure AVR is going to be the better one
kkpuzp2 4 months ago
As I said before, I'm comparing these two devices because they were the two devices that were being discussed in a conference elsewhere. The point is to show how much faster one is than the other - I don't actually understand what's so difficult to grasp about that process.
cremulus 5 months ago
With all respect, IMHO this is a non-sense comparisson. AVR is a 8-bit CPU, PIC32 is a 32-bit CPU, and they are also running at far different frequencies. So, whats the point????
alejoPusto 7 months ago 13
@alejoPusto I am a teacher and the point is teachers try to teach 8-bit microcontrollers when 32-bit ones are already available... most of them don't have the nerves to study new chips, sooo students get useless knowledge. What is worse they justify usage of old microcontrollers on many conferences... Sooo i think this video makes a GOOD point.
71GA 4 months ago
@71GA I am a teacher too, and in fact the comparison is useless because I am sure you dont need to see this video in order to state the fact that a 32-bit processor will run faster than an 8-bit one! Of course it will, given that frequencies! I think we should not teach our students some specific architecture, rather, we should teach them the concepts to be applied in any architecture, say 8-bit or 16-bit or 32-bit, or ... it doesnt matter!
alejoPusto 4 months ago
This has been flagged as spam show
@71GA I am a teacher too, and in fact the comparison is useless because I am sure you dont need to see this video in order to state the fact that a 32-bit processor will run faster than an 8-bit one! Of course it will, given that frequencies! I think we should not teach our students some specific architecture, rather, we should teach them the concepts to be applied in any architecture, say 8-bit or 16-bit or 32-bit, or ... it doesnt matter!
alejoPusto 3 months ago
@alejoPusto The point was that a friend of mine was using an 8-bit AVR to drive this display and I wanted to show them how much better off they would be using the pic32...
It's easy to _guess_ that it would be at least a factor of ten faster, just from the relative clocks, but to show him just how much faster that 'feels' in practice I videoed the two side by side... Surely this isn't hard to grasp? A simple demonstration made things clearer than any amount of text.
cremulus 3 weeks ago
@cremulus There is surely no need to take the time to port your code to PIC32 or write a long text in order to simply explain that a 32-bit architecture, running 10 times faster, will be better than an 8-bit architecture. Surely this isnt hard to grasp ;).... However your video generated such a controversy that I really find amusing... keep the work, indeed your video can be a very direct example to people who just want to test 32-bit vs. 8-bit architectures... although this sounds dumb for me..
alejoPusto 2 weeks ago
@alejoPusto Well, as you don't have access to the original conference or know any of the people and their attitudes you aren't in any position to judge how useful that simple demonstration was. As this thread amply demonstrates, no matter how clearly something is expressed in text there will always be people too arrogant or stupid to understand it.
And as for "take the time" - I closed one development tool, opened another, changed a few lines of source code and compiled... Not long.
cremulus 2 days ago
@alejoPusto It might not be hard, but few here have shown any sign that they grasp that "better" depends on price, power, package, available tools, experience, hardware port characteristics - and lots of other factors - not just a simplistic comparison of clock speed and bus width.
In this case using more efficient code the 8-bit AVR could write data to the LCD as fast as the LCD can handle it, and the 32-bit PIC could not then do any better despite the clock and bus width. [shrug]
cremulus 2 days ago
They're both running pretty much the same crayon (GCC C) source code. If the AVR was coded in assembler it'd go about three times faster. There's less scope for increasing the speed of the pic32 because it's already getting close to driving the LCD as fast as it can accept data.
cremulus 8 months ago
Sorry, people, didn't notice the comments. Off the top of my head it was a Mega128 running at 8MHz (fastest it'd go at 3.3V) and a picMX6xx of some flavour or other running at 80MHz, but it doesn't make much difference which pic32.
I'm comparing these two because they were the two under discussion at the time in a conference.
cremulus 8 months ago
it seems like compare dick with finger
AVR and PIC32 isn't same level devices, Compare AVR32 and PIC32, or ARM7 , Cortex.
Jafar4eg 9 months ago 6
@Jafar4eg
That's the point exactly. Beside that I'm also a PIC32 fan, I must admit this comparison is far from fair. For example even ATxmega can run at 32MHz@3.3V, or speaking of a better competitior, any of the AVR32 UC3A series can be clocked at 66MHz giving ~90DMIPS. And more or less both are in the same price segment.
trasheeone 7 months ago
What PIC and what AVR did you use?
florin2f 1 year ago
You can see all this happening on the AVR, but the pic32 does it roughly 12 times faster and it's just a blur.
cremulus 1 year ago
They're running the same code, it redraws a screenful of text 16 times using increasing brightness with one form of character set storage and then does it again 16 times using another. Then the screen is then cleared three times by writing to each pixel with green/blue/red and the cycle repeats.
cremulus 1 year ago