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.
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.
Microchip MPLAB writes an intermediary file format that is not of their own design?
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.
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.
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.
--
Grant Edwards grante Yow! My polyvinyl cowboy
at wallet was made in Hong
After thinking more about the question, yes, an 8-bit architecture is inherently more C-unfriendly than one which supports "pointer-length" operations.
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.
Not as C-friendly as using 1. :)
--
Grant Edwards grante Yow! MY income is ALL
at disposable!
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.
Well the H8/300's max out at 2K RAM (8K for AVR's) 60K FLASH (256K AVR's), requires 50% more power, are physically bigger, have no EEPROM, limited selection, there is a price to pay in die size when you move up to a 16 bit processor which can make your life harder it other aspects, I also seem to remember doing a H8/300 16 bit multiply was slower then a AVR's 16 bit multiply and generally slower in all instructions, so it's not so cut and dry as you imply if you dig into the details. The MSP430's are not cheaper then the AVR's.
I think another idea lurking in the background here is that C expects a Von Neumann architecture (same instructions to read from program memory as from data memory) and most micros have Harvard architecture (reading from pgm. and data memory are different kinds of operations). The AVR is like the
8051, PIC, etc., in this respect. Among microcontrollers, the 68HC11 and MSP430 have Von Neumann architecture; almost all larger computers do (Pentium, VAX, etc.).
This is the source of the C string storage problem (how to avoid filling up data memory with your string data).
Odd, I'm using one with 4K, and I evaluated models with 10K.
I'm using one with 128K, and evaluated models with 512K.
True.
Don't think so.
You must be getting better prices from your distributor. A few months ago I got quotes and MSP430's came in at $1-$3 cheaper than equivalent AVRs which were quoted at $7-$8.
--
Grant Edwards grante Yow! If I am elected no
at one will ever have to do
Well if you take the _strictest_ interpretation of H8/300 64k addressing then MOST are limited to 2K of RAM, however most H8 users appear to be using H8/300H or H8/300S or H8/300SX cores with 16M addressing and RAM largest I have seen and evaluated is 32Kb (H8S/2329 and H8S/2378).
Yep currently using several with 128kB, have used one with 384Kb and will be evaluating one with 512kB of Flash.
I agree with that.
...
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Ah. You're right. If Steve meant "H8/300" to exclude the "H" "S" etc. models, then those are strictly 16-bit address space parts. I guess when I type "H8/300" I mean to include the whole family.
That's one of the H8/300H varieties (H8/3062).
I just wish some of the parts with CAN interfaces were cheaper. For some reason, the H8 parts with CAN and a decent amount of flash (128K+) are awfully expensive (in the $20 range). What I really want is 128K of flash, 16-24K of RAM, and CAN -- but it costs about half as much to glue something together using a
3062, 32K SRAM, and an external CAN controller. :(
--
Grant Edwards grante Yow! I just bought
at FLATBUSH from MICKEY
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.