uC selection

Choose an ARM based uC. Download & install eclipse, winarm (compiler & tools), openocd. Build or buy a wiggler compatible JTAG interface. And off you go...

If you want to program in C, stay away from Harvard architecture chips (like AVR and TI's DSPs). The seperate code and data memory makes the instruction set complex (opcodes that could be used for nifty stuff are now used to deal with something stupid like memory) and it causes a huge amount of overhead because a C pointer must be translated into the proper memory space first.

snipped-for-privacy@yahoo.com a écrit :

Even excellent musicians will have hard time using a Steinway as a flute...

lar to

seems

ng

o a

ed

).

do

What you say is true but exaggerated. There is no "huge" amount of overhead. If there were then Harvard architectures would have been forced from the market, and that certainly isn't the case. If anything they may be growing percentagewise vs. their competitors.

On a sunny day (Sat, 15 Mar 2008 20:04:36 +0100) it happened Fred Bartoli wrote in :

So I will just pretend that I think you missed the point, and point out, and underscore, that the tool does not matter so much, it is the result that counts. I can understand 'I want to get some experience with 128 bit processors?', but I do think you need a sensible project that needs that.

I would not for the fun want to learn Yet An Other Instruction Set. So, in those really complex cases use C. And C needs no fancy tools other then gcc :-) And if the micro in question has no support in gcc, then it is of no use anyways on earth or in space, or even in a Steinway.

Times are changing, also in music, and what you can do to an instrument after recording, but rotten code once compiled.... no good. Have a listen to this movie:

And designing yet an other uc board... you can buy those these days. And then what ultimately will determine what processor you chose could well be the peripherals only. It all depends, it all needs a project, else it is 'gelul in de ruimte', that is Dutch for lets politely say idle talk. And once he/she/it goes to a small Linux system then there are so many other much more complex issues to consider, like not true real time, writing drivers, some of those things may take years to learn.

Why? What is lacking in the PIC lineup?

You are completely wrong. At one point PIC was the highest selling microcontroller in the world. Do you think those sales came from hobbyists? PIC are still close to #1 in sales, but it goes back-and-forth a lot.

Absolute rubbish. That is why PIC has *hundreds* of different devices tailored to every possible application. Not many other have such an extensive line to choose from.

Dave.

PIC are hard to beat for scalability. Check out the real details instead of just guessing. The development toolsets are consistent across 8-bit, 16-bit, DSP, and

You really haven't investigated this properly have you? PIC have everything from a tiny 8 bit 5 pin job through to huge 32bit DSP's, and the toolsets and interface are consistent across the entire line. PIC will be able to do anything you ever want, both professionally and for hobby. Microchip have sold *billions* of PICs to industry, hobby sales would represent a ridiculously small percentage of that.

Look at the high end 32bit PICs:

If you need anything bigger than those then you are no longer in the realm of microcontrollers any more, but microprocessors like the ARM that can access massive amounts of memory and other resources.

Dave.

Make that 6 billion PICs:

Dave.

If PICs are annoying you for some reason, then by all means change. But don't change for the other reasons you have mentioned.

My first introduction with AVR was horrible. Not only did the Atmel development tool not properly support the chip I wanted to use (ATtiny26), but I found out it was possible (and easy) to accidently lock out the in-system programming feature. Thus if your chip is soldered to the board and you manage to disable it, you are stuffed. Only a parallel programmer can resurrect it. I can't imagine anything worse in a microcontroller design. I'm not sure if this has been fixed or what other parts are like, but beware.

Dave.

We have a few different industrial things that uses pics.

Most of the time they stick a BAR coded sticker or some typed sticker ontop of the chip body to ID the program in it. We have found them in Timer Relays, sequence loaders in vacuume systems, localized logic control for an end point results to a larger system. Wire break detectors te... The list goes on. Many like remove the ID markers of the chip and simply place a stick ontop, you'll lots of that. I have a simple antenna analyzer that operates a display for frequency counter, Load Impedance, Reflected etc which uses a PIC..

I successfully used the ATtiny13 in a high volume application and I did also manage to lock myself out once during development.

It is annoying when this happens, but it can be avoided by taking care over the configuration fuse settings. Things to watch out for are:

Don't set "Watchdog timer always on" as the watchdog then remains active through a reset. This makes it impossible to reprogram the configuration fuses - or anything else - because the watchdog resets the processor part way through a flash memory erase.

Don't set "Debug wire enable" if you don't have the in-circuit debug hardware available, as this reassigns the reset input to use a serial communications protocol, disabling reset, and hence preventing conventional in-circuit programming from working.

Don't set "Reset disabled" as this also prevents the in-circuit programming from working.

I don't really see how these dangers can be avoided without losing functionality. It is a low-cost 8-pin device, so some users will want to reassign the reset as i/o for example, rather than paying more for a processor with more pins.

Perhaps Atmel could put a warning message in the configuration fuse setting window?

John

I don't know any other micro that has this ridiculous design trait. The PICs certainly don't. Imagine if you accidentally programmed thousands of production boards, and you may not find out until you go and do the field upgrade. It's a massive accident waiting to happen.

When I solder an in-system programmable part onto a board, I want a guarantee that I'll always be able to program it. Anything else is a joke. This aspect alone makes the AVR more of a "hobby" processor than any other.

You'd have to get all the third party programmer software to follow suit too.

Dave.

I have needed this "feature" in something. On things that you need a license to export, it can be handy to ensure that nobody can ever do an upgrade without a soldering iron. This makes the "can't de upgraded" requirement easier to meet.

Imagine if you accidentally misprogrammed thousands of OTP devices. Would that make OTP a ridiculous design trait?

Maybe other users want other guarantees. Maybe Atmel even spoke with a few of them in the design process.

Perhaps I should also have mentioned that the ATtiny processors have explicit lock bits which can be set to prevent further programming or to prevent further programming and verification.

If verification is blocked, then the device must be fully erased (in a parallel programmer) before it can be reused. I believe the lock bits are designed to take longer to erase than the main memory. This makes it very difficult to extract program code.

John

Lots of commercial products use PICs. Crack open a car key remode and you'll most likely find a PIC in there. Both my previous and current car and my wife's car has PICs doing the job. Crack open a Nike+iPod sole insert and you'll find a PIC there as well.

And crappy... The PIC32 bit toolchain uses an ancient GCC compiler. Free and student versions are crippled on purpose (not all optimisation options available). So if you want the most from the PIC32, you really don't want to use the toolset from Microchip.

Besides, why mess around with obfusticated 8 bit devices which requires proprietary tools while a proper ARM based device with open tools can be bought for the same amount of money? Microchip has noticed this too hence the introduction of a microcontroller with a real CPU. I bet MIPS made them a very good offer to choose a MIPS core over an ARM core.

When it comes to a consistent toolset I'm quite sure Eclipse beats most microcontroller development environments hands down. And Eclipse can work with many more targets than just PIC. If you want a top-notch consistent development toolset which works for many devices, get Eclipse and GNU tools.

Like I stated above, PIC32 is MIPS32 based. They shouldn't call it PIC. It just doesn't do the MIPS core right. MIPS and ARM are almost the same. Both are 32bit CPUs with a 32 bit instruction set and a 16 bit compact instruction subset.

So? Download the sources and build yourself an uncrippled version.

That is not so easy because MIPS is not the most common architecture. I'm working on getting GCC 4.1.2 + Glibc + binutils compiled for MIPS using crosstool but there are some problems with getting the right versions together and using the proper settings.