What about the dsPICs from Microchip. They surpass the AVRs in speed, memory, functionality (I'm not really sure about the third one though).The fastest dsPIC in DIP package goes 30MIPS (10MIPS faster than the AVR). The fastest dsPIC goes 40MIPS, has 144kilobytes of flash and has 8192bytes of SRAM.
PIC versus AVR
Started by ●August 3, 2006
Reply by ●August 5, 20062006-08-05
Reply by ●August 5, 20062006-08-05
"Aly" <retro@dial.pipex.com> wrote in message news:q8idnRNqmJyyKknZRVnyrg@bt.com...> > "mc" <look@www.ai.uga.edu.for.address> wrote in message > news:ol2Bg.46464$Nt.35383@bignews8.bellsouth.net... > >> Yes, I know, but end users in 2006 ought not to have to do kluges like > this >> to run the current version of software. >> > > Ideally in 2006 we wouldn't be needing electricity generated from burning > prehistoric animals that died a million years ago. > > You wanted a solution, I gave it to you.I already knew several workarounds. My point is that the manufacturer should fix the product so it doesn't require workarounds in order to run today's software under today's operating systems. Windows has had long filenames for 11 years. DOS isn't coming back. The future is entirely in the future.
Reply by ●August 5, 20062006-08-05
In article <TDTAg.46058$Nt.40021@bignews8.bellsouth.net>, "mc" <look@www.ai.uga.edu.for.address> wrote:> Yes, I've been corresponding with them about this. I'm also pressing them > to make the old 62-character path length limit go away, because it is now > very common for paths on a Windows system to be that long or longer > (C:\Documents and Settings\blahblah\My Documents\PIC projects\myprog.asm). > The limit is actually in the .COD file format, which they don't control.Microchip MPLAB writes an intermediary file format that is not of their own design?> You can work around it by first adding a linker script to your project (so > the linker will run, rather than assembling directly to HEX) and then > turning off COD file generation. I argue that this should actually be the > default, since there are more people who need long paths than people who > need COD files.Is MPLAB still a 16-bit application? One of my biggest gripes last time I used it (IIRC 5.x) was how projects could not be moved from their original path. The whole path, rather than relative path, was stored in the binary project file. Was a royal pain to surf all the menus and submenus looking to correct filename paths.
Reply by ●August 5, 20062006-08-05
"David Kelly" <n4hhe@yahoo.com> wrote in message news:n4hhe-0DC73B.20035605082006@ispnews.usenetserver.com...> In article <TDTAg.46058$Nt.40021@bignews8.bellsouth.net>, > "mc" <look@www.ai.uga.edu.for.address> wrote: > >> Yes, I've been corresponding with them about this. I'm also pressing >> them >> to make the old 62-character path length limit go away, because it is now >> very common for paths on a Windows system to be that long or longer >> (C:\Documents and Settings\blahblah\My Documents\PIC >> projects\myprog.asm). >> The limit is actually in the .COD file format, which they don't control. > > Microchip MPLAB writes an intermediary file format that is not of their > own design?That's what they tell me!> >> You can work around it by first adding a linker script to your project >> (so >> the linker will run, rather than assembling directly to HEX) and then >> turning off COD file generation. I argue that this should actually be >> the >> default, since there are more people who need long paths than people who >> need COD files. > > Is MPLAB still a 16-bit application?Not as far as I can tell, but I don't have utilities handy that will tell me for sure.> One of my biggest gripes last time I used it (IIRC 5.x) was how projects > could not be moved from their original path. The whole path, rather than > relative path, was stored in the binary project file. Was a royal pain > to surf all the menus and submenus looking to correct filename paths.I don't *think* it still has that limitation.
Reply by ●August 6, 20062006-08-06
On 2006-08-04, Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:>>> AVRGCC - single stack, does something odd when making function calls. >>> >>> IAR, Rowley, ImageCraft - separate call and data stacks to prevent the >>> necessity for the above odd thing. >> >> And yet people claim the AVR was designed to be C-friendly. >> I've looked at AVR code generaged by GCC and IAR. The AVR is >> not C-friendly. It may not be actively hostile like the 8051 >> or PIC, but it's not C friendly. >> >> Any processor that falls over when you attempt to do any >> pointer manipulation isn't C-friendly.> You are probably saying that an 8 bit architecture is inherently > C-unfriendly.The big problem I see with the AVR is that only one (or is it two) register pairs can be used as a pointer. A good C-friendly architecture would be able to handle more than one pointer at a time.> If you start in the other end: How do you make an 8 bit > architecture which is C-friendly you may come to a different > conclusion.Allow any register pair to be used for pointers, mainly.> From this viewpoint it is "C-friendly" to use 2 instructions > for 16 bit operations and 4 instructions to do 32 bit > operations.That's fine -- the problem I've seen is that code that has to use multiple pointers thrashes because the AVR can only deal with 1-2 pointers at a time. -- Grant Edwards grante Yow! My polyvinyl cowboy at wallet was made in Hong visi.com Kong by Montgomery Clift!
Reply by ●August 6, 20062006-08-06
On 2006-08-04, Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:>>> AVRGCC - single stack, does something odd when making function calls. >>> >>> IAR, Rowley, ImageCraft - separate call and data stacks to prevent the >>> necessity for the above odd thing. >> >> And yet people claim the AVR was designed to be C-friendly. >> I've looked at AVR code generaged by GCC and IAR. The AVR is >> not C-friendly. It may not be actively hostile like the 8051 >> or PIC, but it's not C friendly. >> >> Any processor that falls over when you attempt to do any >> pointer manipulation isn't C-friendly. >> >> -- > > You are probably saying that an 8 bit architecture is inherently > C-unfriendly. > If you start in the other end: How do you make an 8 bit architecture which > is C-friendly > you may come to a different conclusion. > > From this viewpoint it is "C-friendly" to use 2 instructions for 16 bit > operations > and 4 instructions to do 32 bit operations. > >-- Grant Edwards grante Yow! BRILL CREAM is at CREAM O' WHEAT in another visi.com DIMENSION...
Reply by ●August 6, 20062006-08-06
On 2006-08-04, Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:>> Any processor that falls over when you attempt to do any >> pointer manipulation isn't C-friendly.> You are probably saying that an 8 bit architecture is > inherently C-unfriendly.After thinking more about the question, yes, an 8-bit architecture is inherently more C-unfriendly than one which supports "pointer-length" operations.> If you start in the other end: How do you make an 8 bit > architecture which is C-friendly you may come to a different > conclusion.Start at yet another end again: why pick an 8-bit architecture if you're using a language or writing an application that needs to do a lot of 16-bit operations? Something like an MSP430 (16-bit) or H8 (16/32 bit) is cheaper than an AVR, and makes life easier. I particularly like the H8/300 which provides atomic read/write of 32-bit variables (long integers and floats): that eliminates the requirements for a lot of mutexes.> From this viewpoint it is "C-friendly" to use 2 instructions > for 16 bit operations and 4 instructions to do 32 bit > operations.Not as C-friendly as using 1. :) -- Grant Edwards grante Yow! MY income is ALL at disposable! visi.com
Reply by ●August 6, 20062006-08-06
>> You are probably saying that an 8 bit architecture is inherently >> C-unfriendly. > > The big problem I see with the AVR is that only one (or is it > two) register pairs can be used as a pointer. A good > C-friendly architecture would be able to handle more than one > pointer at a time. >X,Y,Z,SP can be used as pointers. Y is of course occupied as a stackpointer in some compilers.>> If you start in the other end: How do you make an 8 bit >> architecture which is C-friendly you may come to a different >> conclusion. > > Allow any register pair to be used for pointers, mainly.> That's fine -- the problem I've seen is that code that has to > use multiple pointers thrashes because the AVR can only deal > with 1-2 pointers at a time.The new MOVW instruction helps somewhat.> -- > Grant Edwards grante Yow! My polyvinyl > cowboy > at wallet was made in Hong > visi.com Kong by Montgomery > Clift!
Reply by ●August 6, 20062006-08-06
>> If you start in the other end: How do you make an 8 bit >> architecture which is C-friendly you may come to a different >> conclusion. > > Start at yet another end again: why pick an 8-bit architecture > if you're using a language or writing an application that needs > to do a lot of 16-bit operations?It all depends on the relations between the amount of 8 and 16 bit operations.> Something like an MSP430 > (16-bit) or H8 (16/32 bit) is cheaper than an AVR,Depends on who is asking and who is asked, I guess.>> From this viewpoint it is "C-friendly" to use 2 instructions >> for 16 bit operations and 4 instructions to do 32 bit operations. > > Not as C-friendly as using 1. :)The ability to support high end features often come at a cost in code space. When those high end features are used, then the architecture with native support excels. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Reply by ●August 6, 20062006-08-06
On Sun, 06 Aug 2006 14:58:02 -0000, Grant Edwards <grante@visi.com> wrote:>The big problem I see with the AVR is that only one (or is it >two) register pairs can be used as a pointer.It's actually three register pairs. Though only one of them is able to address the program memory, but I've never had the need to point to more than one place in program memory at a time. And I just love the AVR instruction that addresses indirectly with displacement. That is really useful for pointers to structs. And that is a C friendly instruction if I ever saw one. Best regards, Mikael -- Mikael Ejberg Pedersen http://www.ejberg.dk
