Right, so we have 8-bit, 16-bit and 32-bit microcontrollers in this world at the moment. All of them are often used. How different is it to program 8-bit and 16-bit micrcontrollers? I mean, does it require different technique or skill? Lets take microchip for example. What new things does a person need to learn if they want to transition from 8-bit microcontrollers to 32-bit microcontrollers?
Electronic – How different are 8-bit microcontrollers from 32-bit microcontrollers when it comes to programming them
microcontrollerprogramming
Related Solutions
Digital design does not have a lot in common with software development (maybe except that Verilog syntax looks a bit like C language but it just looks). Thus it is very hard to answer this type of question adequately. But as a guy who walked a path from software development to hardware design I'll give it a shot. Looking back at myself, here is how I would have advised myself back then if I knew what I know now:
Start from scratch
Forget everything about software development. Especially programming languages. Those principles do not apply in digital design. It probably would be easy for a guy who designed a CPU to program it in assembler or even C, but an assembler programmer won't be able to design a CPU.
On your learning path do not tend to solve what seem to be an easy problem with your existing knowledge from software. One of the classic examples is a "for loop". Even though you can write a for loop in, say, verilog — it serves a different purposes. It is mainly used for code generation. It may also be a for loop as software developers see it, but it won't be good for anything but simulation (i.e. you won't be able to program FPGA like that).
So for every task you want to tackle, don't think you know how to do it, do a research instead — check books, examples, ask more experienced people etc.
Learn hardware and HDL language
The most popular HDL languages are Verilog and VHDL. There are also vendor-specific ones like AHDL (Altera HDL). Since those languages are used to describe hardware components, they are all pretty much used to express the same thing in a similar fashions but with a different syntax.
Some people recommend learning Verilog because it looks like C. Yes, its syntax is a mix of C and Ada but it doesn't make it easy for a software developer to lean. In fact, I think it may even make it worse because there will be a temptation to write C in Verilog. That's a good recipe for having a very bad time.
Having that in mind, I'd recommend staring from the VHDL. Though Verilog is also OK as long as the above is taken into account.
One important thing to keep in mind is that you must understand what you are expressing with that language. What kind of hardware is being "described" and how it works.
For that reason, I'd recommend you get yourself some book on electronics in general and a good book like this one — HDL Chip Design (aka as a blue book).
Get a simulator
Before you start doing anything in hardware and use any Vendor-specific features etc., get yourself a simulator. I was starting with a Verilog, and used Icarus Verilog along with GTK Wave. Those are free open-source projects. Run examples you see in books, practice by designing your own circuits to get some taste of it.
Get a development board
When you feel like going forward, get a development board. If you know that your employer wants to go with Lattice, then get Lattice board.
The programming methods are very similar, but there are details that are different. For example, different tools, different options, different interfaces. Usually, if you have experience with one vendor, it is not hard to switch. But you probably want to avoid this extra learning curve.
I'd also make sure that the board comes with components that you are planning to use or is extendable. For example, if you want to do design a network device like a router, make sure the board has Ethernet PHY or it can be extended through, say, HSMC connector, etc.
Boards usually come with a good reference, user guide and design examples. Study them.
Read books
You will need to read books. In my case, I had no friends who knew digital design, and this site wasn't very helpful either because of one simple thing — I didn't even know how to phrase my question. All I could come up with was like "Uhm, guys, there is a thing dcfifo and I heard something about clock domain crossing challenges, what is it and why my design doesn't work?".
I personally started with these:
- Advanced Digital Design with the Verilog HDL.
- 100 Power Tips for FPGA Developers
- Advanced FPGA Design - Architecture, Implementation and Optimization.
FPGA vendors have a lot of cookbooks with best practices. Study them along with reference designs. Here is one from Altera, for example.
Come back with more specific questions
While you go through your books, simulate a design, blink some LEDs on your development board, you would, most likely, have a lot of questions. Make sure you don't see an answer to those on the next page of the book or online (i.e. in the Lattice-specific forum) before asking them here.
Intel HEX files are always byte-addressed. This does not mean they can't handle information for other word sizes, only that there needs to be a convention about how those words are mapped to the bytes of the HEX file.
Just like with all the other non-byte addressed PICs (PIC 10, 12, and 16), the addresses are doubled in the HEX file. PIC programmer software knows this and interprets the HEX file addresses accordingly. This is of course all well documented in the programming spec for whatever part you want to program.
You say you want to make your own programmer. That's fine as long as you understand this will take way more time and frustration than just getting a known working one. If the point is the experience and learning of making your own, then fine, but otherwise go buy one.
If you really do want to make your own, you should look at the code for my PIC programmers. All the host code and firmware is open and available in the Development Software release at http://www.embedinc.com/picprg/sw.htm. By looking thru the host source code, you can see how there are flags indicating whether HEX file addresses are doubled for various parts of the PIC's memory.
If you make your programmer compatible with my PIC programmers protocol, then you can make use of all my host-side tools. This could be very helpful when bringing up your system since you have known working code on the other side. The protocol spec may look intimidating at first, but look carefully and you will see much of it is optional, especially if you plan to only support a single PIC.
Related Topic
- Electronic – Figuring out the functions of PIC numbers in a data file
- Electronic – arduino – If one has used PIC uC, how different is it to migrate to using a different uC like say Arduino or ARM
- Electronic – Jumping from microcontroller to DSPs
- Electronic – Do CMSIS libraries also handle GPIO registers
- Electronic – Existing UART libraries on pic/atmega/
Best Answer
In general, going from 8 to 16 to 32 bit microcontrollers means you will have fewer restraints on resources, particularly memory, and the width of registers used for doing arithmetic and logical operations. The 8, 16, and 32-bit monikers generally refers to both the size of the internal and external data busses and also the size of the internal register(s) used for arithmetic and logical operations (used to be just one or two called accumulators, now there are usually register banks of 16 or 32).
I/O port port sizes will also generally follow the data bus size, so an 8-bit micro will have 8-bit ports, a 16-bit will have 16-bit ports etc.
Despite having an 8-bit data bus, many 8-bit microcontrollers have a 16-bit address bus and can address 2^16 or 64K bytes of memory (that doesn't mean they have anywhere near that implemented). But some 8-bit micros, like the low-end PICs, may have only a very limited RAM space (e.g. 96 bytes on a PIC16).
To get around their limited addressing scheme, some 8-bit micros use paging, where the contents of a page register determines one of several banks of memory to use. There will usually be some common RAM available no matter what the page register is set to.
16-bit microcontroller are generally restricted to 64K of memory, but may also use paging techniques to get around this. 32-bit microcontrollers of course have no such restrictions and can address up to 4GB of memory.
Along with the different memory sizes is the stack size. In the lower end micros, this may be implemented in a special area of memory and be very small (many PIC16's have an 8-level deep call stack). In the 16-bit and 32-bit micros, the stack will usually be in general RAM and be limited only by the size of the RAM.
There are also vast differences in the amount of memory -- both program and RAM -- implemented on the various devices. 8-bit micros may only have a few hundred bytes of RAM, and a few thousand bytes of program memory (or much less -- for example the PIC10F320 has only 256 14-bit words of flash and 64 bytes of RAM). 16-bit micros may have a few thousand bytes of RAM, and tens of thousand of bytes of program memory. 32-bit micros often have over 64K bytes of RAM, and maybe 1/2 MB or more of program memory (the PIC32MZ2048 has 2 MB of flash and 512KB of RAM; the newly released PIC32MZ2064DAH176, optimized for graphics has 2 MB of flash and a whopping 32MB of on-chip RAM).
If you are programming in assembly language, the register-size limitations will be very evident, for example adding two 32-bit numbers is a chore on an 8-bit microcontroller but trivial on a 32-bit one. If you are programming in C, this will be largely transparent, but of course the underlying compiled code will be much larger for the 8-bitter.
I said largely transparent, because the size of various C data types may be different from one size micro to another; for example, a compiler which targets a 8 or 16-bit micro may use "int" to mean a 16-bit signed variable, and on a 32-bit micro this would be a 32-bit variable. So a lot of programs use #defines to explicitly say what the desired size is, such as "UINT16" for an unsigned 16-bit variable.
If you are programming in C, the biggest impact will be the size of you variables. For example, if you know a variable will always be less than 256 (or in the range -128 to 127 if signed), then you should use an 8-bit (unsigned char or char) on an 8-bit micro (e.g. PIC16) since using a larger size will be very inefficient. Likewise re 16-bit variables on a 16-bit micro (e.g. PIC24). If you are using a 32-bit micro (PIC32), then it doesn't really make any difference since the MIPS instruction set has byte, word, and double-word instructions. However on some 32-bit micros, if they lack such instructions, manipulating an 8-bit variable may be less efficient than a 32-bit one due to masking.
As forum member vsz pointed out, on systems where you have a variable that is larger than the default register size (e.g. a 16-bit variable on an 8-bit micro), and that variable is shared between two threads or between the base thread and an interrupt handler, one must make any operation (including just reading) on the variable atomic, that is make it appear to be done as one instruction. This is called a critical section. The standard way to mitigate this is to surround the critical section with a disable/enable interrupt pair.
So going from 32-bit systems to 16-bit, or 16-bit to 8-bit, any operations on variables of this type that are now larger than the default register size (but weren't before) need to be considered a critical section.
Another main difference, going from one PIC processor to another, is the handling of peripherals. This has less to do with word size and more to do with the type and number of resources allocated on each chip. In general, Microchip has tried to make the programming of the same peripheral used across different chips as similar as possible (e.g. timer0) , but there will always be differences. Using their peripheral libraries will hide these differences to a large extent. A final difference is the handling of interrupts. Again there is help here from the Microchip libraries.