Hi all.

Not a really specific question, but I'm keen to learn.

What are the actual compatibilities between various microcontroller programs? I would assume (certainly for asm) that different manufacturers' uC's are quite incompatible, but to what degree can one reuse a program within a manufacturer's series?

I would say, I am most interested in the PICs, but if anyone wants to add some stuff about anyone else, feel free.

For example, aside from the hardware differences, (clock speed, IOs, etc) what differences exist across the PIC family? Could I reuse a program for a pic16 in a 18 or 32? Or are the instruction sets different? If some families need only tweaking, what sort of tweaks are common?

I appreciate that this may seem a broad question, but any replies would be really cool.

Thanks guys,

Sparky

 

If you are programming in something like C then apart from the config and some of the programming differences like port and lat usage most programs would be pretty easy to port.

Obviously moving up the PIC tree usually gives more memory and pins with more facilities like serial ports etc. so you sometimes can't go down a level but moving up is often pretty easy.

 

As long as things are abstracted enough and recompiled for the target, the process pwdixon described is pretty easy, however, there are often huge variation even among families of controllers as technology changes and newer controllers are added to the family that may seem to have a completely different architecture.

Memory location is one thing that changes from controller to controller, making ASM porting frustrating unless the new controller has the same (or sufficiently similar) memory layout. In C, you simply offload that burden to the compiler and it will decide where to store something, which may be completely different from a previous version's storage location.

Microchip seems to have tried to keep things with a common naming convention which makes things easier with C (though one example to the contrary is something like the OPTION_REG in early 16F series).

While instruction sets, indeed, are different across families, a C programmer won't really notice or care, except when line execution time is important, as the instruction set is obfuscated by the higher language construct of C.

That said, basic programs (blink a LED) should have no problem with portability using C (ASM might run into trouble, but, provided a similar memory map, it should have minimal headaches associated), where larger programs may require significant rework.

 

Converting a whole program can be a pain, even between different midrange PICs. That said, I usually find that the parts that I want to reuse from one program into another on a different PIC are much easier.

 

In my case I acquired familiarity with Picmicro and the Pic instruction set using the 16F series, where programs are basically interchangeable across the range.
I subsequently migrated over to the 18F series, the instruction set is basically the same, but I found some of the features and instruction changes and additions make it a lot easier to use.
*Program memory paging gone - tables any length, anywhere.
*Compare instructions
*Bit toggle, set file etc
*Motor Control aimed instructions
*CAN bus
*USB
*Ethernet
And a few others.
Changing a 16F program to 18F etc may require some changes depending on the intended result, but once you have the new instructions under your belt, it does not take long to figure the change required.
App note AN716 'Migrating designs' and others help.
I will add I program in assembly. I find it more intuitive.
Max.

 

Hi Sparky, here's my 2 cents.

If you write your programs in "c", they are mostly portable. That's what "c" is for. For example, simple "hello world" program in c should compile and run on just about any platform. What makes the big difference is when using various peripherals and the libraries for them. As soon as you want to use a UART or ADC, then you run into differences. That's been my experience anyway. I'm sure other members will find lost of exceptions, but this is true in the general sense.