I am a self-taught embedded developer. I mostly use AVRs programmed in C and ASM, but I have dabbled with other systems. I am looking to move onto more complex devices like CPLDs and FPGAs, but I have no idea where to start. So my one and a half questions are:
Do you prefer VHDL or Verilog and why?
What is a good way for one with no prior experience in HDLs get started in learning such a beast?
Buy a cheap starter kit from Xilinx or Altera (the two big FPGA players). A Xilinx Spartan3 starter kit is $200.
I personally prefer VHDL. It is strongly typed and has more advanced features than Verilog. VHDL is more popular in Europe and Verilog is dominating in the US.
Buy a book (e.g. Peter Ashendens The Designers Guide to VHDL) and start simulating your designs in a free simulator. ModelSim from Mentor Graphis is a good one and there are free versions available (with crippled simulation speed).
Make up some interesting project (mini cpu, vga graphics, synthesizer) and start designing. Always simulate and make sure your design works before putting your design into the hardware ...
If you have no background in digital electronics buy a book in that subject as well.
Back in the day when I worked on ASIC design, it was in verilog. In many cases as a designer you don't get to choose: the ASIC synthesis tools for an HDL cost a substantial amount of money, and companies only purchase the full toolchain for one "blessed" language. My employer had standardized on verilog, so that is what we used.
FPGA synthesis tools are substantially cheaper, so you have more freedom as an FPGA designer to pick your favored language and tools.
There are also free verilog simulators available at verilog.net.
As #kris mentioned, an FPGA starter board is also a good way to go. Having your verilog code light up an LED on a board is infinitely more satisfying than a simulator waveform on the screen.
Also check out opencores.org - There are some articles and a lot of open source code in both Verilog and VHDL you can learn from.
As far as I can tell, VHDL vs Verilog gets just as religious as Ruby vs Python or Java vs C#. Different people have their own favourites.
Check out this site:
http://www.fpga4fun.com/
Nice simple projects using simple tools. I used one of these boards a few years ago to build a small VGA display system for use as a notice board.
Looking at the site again I'm thinking of getting a Xylo-LM board as it has an ARM processor as well as SDRAM and a Xilinx Spartan 3e.
Another board I used before was the XPort 2 from Charmed Labs. This plugs into a Gameboy Advance which is well supported with open source development tools.
Check out:
http://www.charmedlabs.com/index.php?option=com_virtuemart&page=shop.browse&category_id=6&Itemid=43
One additional thing to think about is whether you should start by learning an HDL, or by learning boolean logic, Karnaugh maps, DeMorgan's theorem, gates, implementing arithmetic in gates, etc. It's easy to write non-synthesizable HDL if you don't have an accurate mental model of what the underlying hardware will look like.
This book is the Verilog version of the one I used in undergrad, and it did a pretty good job in my opinion. It starts you out with the material mentioned above, as well as some basic, basic info on the transistor-level implementation of gates, then introduces you to an HDL, and has you build progressively more complex structural and behavioral hardware blocks. Yes, I know it's ungodly expensive, as are most college textbooks, but this is one of those things for which the information I've been able to find online, at least, has been woefully inadequate.
Once you're ready to choose an HDL, I heartily recommend Verilog (having learned VHDL first). Yes, VHDL was once much more feature-rich than Verilog, but later revisions of the language (Verilog 2001, Verilog 2005, SystemVerilog, etc..) have cherry-picked most of the interesting features, and there is far more robust toolchain support for Verilog and its variant these days, in addition to it being the dominant language in use in the US (in my experience, VHDL is only used here when dealing with extreme legacy blocks, and in academic contexts, partially due to the tools support mentioned previously). Finally, once you've learned the HDL, you have a hardware verification language (HVL) in SystemVerilog with strict-superset syntax, saving you a good bit of the learning curve. Not so for VHDL, to my knowledge.
Altera and Xilinx have simulators build into their free tool sets. They are limited versions of the very popular Mentor ModelSim tools. They will handle the size of designs you are likely to get to fit in a < $500 (US) board.
For HDL choice Verilog is to C as VHDL is to ADA. So Verilog is easier to get started with, but you can make mistakes more easily. Check your simulation and compilation warnings to avoid those problems.
Verilog 2.http://www.opensparc.net/
HTH
Verilog is much easier to learn and simpler syntax. Its also a newer language. Secondly, most people use verilog. VHDL has many datatypes which give it a learning curve. Once you know verilog it will be easier to bridge the gap to VHDL. Oh and theres also macros in verilog which are very neet. I invented a language with it. Finally, you will eventually be able to do mixed language HW design. I started out with VHDL, then learned verilog and am now pro verilog.
I was in the same boat as you are now a semester ago. My preferred book was this one, since it talked about FPGAs by reviewing digital logic. It also shows side-by-side comparisons of VHDL and Verilog code so that, instead of choosing one that people may push you to, you can learn the one that you like stylistically.
As for an FPGA itself, use Xilinx's ISE webpack to do your programming (it's free), and start off with FPGAs like the Basys2 FPGA board. It's a very small FPGA that should get you started for a small price, but has the added advantage that you learn resource and memory management very early. You can use Digilent's Adept (also free) to make life easy in uploading your "compiled" code to the board.
Good luck!
Before plunging into Verilog/VHDL or buying an FPGA dev kit I'd recommend taking an introductory class on digital design. There are good online OpenCourseWare MIT classes.
Good luck.
Related
I come from a programming background and not messed around too much with hardware or firmware (at most a bit electronics and Arduino).
What is the motivation in using hardware description languages (HDL) such as Verilog and VHDL over programming languages like C or some Assembly?
Is this issue at all a matter of choice?
I read that hardware, which its firmware is written in an HDL, has a clear advantage in running instructions in parallel. However, I was surprised to see discussions expressing doubts whether to write firmware in C or Assembly (how is Assembly appropriate if you don't necessarily have a CPU?) but I concluded it's also an option.
Therefore, I have a few questions (don't hesitate to explain anything):
A firmware really can be written either in HDL or in a software programming language, or it's just another way to perform the same mission? I'd love to real-world examples. What constraints resulting from each option?
I know that a common use of firmware over software is in hardware accelerators (such as GPUs, network adapters, SSL accelerators, etc). As I understand it, this acceleration is not always necessary, but only recommended (for example, in the case of SSL and acceleration of complex algorithms). Can one choose between firmware and software in all cases? If not, I'd be happy to cases in which firmware is clearly and unequivocally appropriate.
I've read that the firmware mostly burned on ROM or flash. How it is represented in there? In bits, like software? If so, what's the profound difference? Is it the availability of adapted circuits in the case of firmware?
I guess I made a mistake here and there in some assumptions, please forgive me. Thank you!
The term "firmware" is at best ill defined, and I believe that is probably the cause of your confusion.
Historicallym - before the availability of programmable logic devices - the term "firmware" has been used to refer to code stored-in and executed-from read-only memory (ROM). At a time when the only available ROM technology was mask-ROM where the code was burned into the device at manufacture of the silicon and therefore unchangeable without replacing the chip - that was pretty "firm". Even with later programmable read-only memory (PROM), which could be programmed post-manufacture, because it was one-time programmable (OTP), the term still applied.
With the introduction of UV erasable EEPROM, firmware became perhaps less "firm", but the lack of in-circuit programmability and the need to expose the device to UV to erase it still made replacement of the embedded software a chore - normally requiring removal of the chip, placing it in the eraser for an hour or so, then programming it in a dedicated programmer.
The advent of NOR Flash memory, where code could be stored and executed directly from the device, but also readily changed in-circuit, the term firmware in this context has become less common. However it is still used (perhaps mainly by older practitioners) to refer to embedded software stored and executed from a random-access, read-only memory device as opposed to loaded into RAM from a file system.
The use for the term firmware to refer to programmable logic configuration is newer and has probably come about simply because it is hardware, but the configuration is written much like software using a high-level language.
The upshot of this is that you do not choose
"Verilog and VHDL over programming languages like C or some Assembly"
because in each context the term firmware simply refers to a different concept.
It would be best to avoid the term firmware altogether as it means different things to different people or in different contexts.
There is perhaps some further confusion form the fact that some hardware description languages are based on software development languages - such as Handle C, which is a C-like hardware description language.
This question would not have much arise some time ago, but with current platforms you can now translate between C and HDL languages (instead of using Handel-C extension of C, from the 90's), mainly between C and behavioral VHDL. And a lot of newer tools provided by enterprises, like Xilinx Electronic System Level Design Ecosystem, or Impulse-C (http://www.impulseaccelerated.com/products_universal.htm)
It is important to know though that as C is a middle level language, and VHDL is, as stated a Hrdware Description Language. C can only handle sequential instructions while VHDL allows both sequential and concurrent executions.
And even though a C program can be successfully written with pure logical or algorithmic thinking,
a successful VHDL programmer needs thorough working knowledge of the hardware circuits. being able to predict how a given code will be implemented in hardware.
In both languages you care about the resource usage, but in a different way (Unless you are programming for resource-constrained devices). But when it comes to VHDL, apart from the memory, other logic elements are limited in a FPGA (where you normally put the VHDL code in).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have completed my degree in Computer Engineering. We had some basic electronics courses in Digital Signal Processing, Information Theory, etc. but my primary field is Programming.
However, I was looking to get into Embedded Systems Programming, and I have NO knowledge of how it is done. However, I am very keen on going into this field.
My questions :
What are the languages used to program embedded systems?
Will I be able to learn without having any basics in electronics?
Any other prerequisites that I should know?
Without a doubt, experience or at least a significant understanding of digital electronics and low level computer engineering is required. You'll need to be able to read device datasheets and understand them. Scopes, multimeters, logic analyzers, etc... are tools of the trade.
C is used mostly, but higher level languages are sneaking in slowly.
Getting started in Embedded Systems is a complex task in itself, because it is a very vast field with numerous options in hardware and software.
What are the languages used to program embedded system programs?
Assembly Language, C, C++, Python, C# and others.
Will I be able to learn without having any basics in electronics?
Learning embedded systems without the basic knowledge of electronics would not be a good idea. Embedded systems is a mix of hardware and software. You can follow the approach of learning-by-doing instead of going through the lengthy and detailed text books.You can refer to this blog
to learn embedded systems by doing practicals, step by step. It will help you to get started from the scratch.
Any other prerequisites that I should know?
Basic electronics, digital electronics, knowledge of microcontrollers and C programming. Since you are from computer science background you would need a development board of any 8-bit microcontroller (students of EE and ECE have enough knowledge and background to build it on breadboard or pcb) to get started. (Don't prefer simulators in the start, you might get your concepts wrong!).
You have to accept constraints and be able to work with them:
CPU speed
scarce memory
lack of networking facilities
custom compilers and OSes
custom motherboards and drivers
debugging with a logic analyzer
weird coding and testing practices
...
The reward is a deep understanding on what is going on.
VHDL, Verilog, and FPGA's are serious players in this arena as well. With a good background in CS, plenty of commitment, and maybe some MIT OpenCourseware you'll be able to pull off something good. A good knowledge of cpu architectures and some ASM will go a long way too.
I went into that field with no knowledge of how it was done as a fresh graduate and quit after 1,5 years. So, what I say may be a little bit rusty, and definitely not comprehensive.
The language we were using was C. But at that time, the disc space was 4MB and memory was 8MB on the devices we were developing for, and I know that C was used due to its libraries' tiny footprint. Apparently, performance was a criterion as well.
As to basic electronics, for an entry level position almost none is necessary. You will gain the required information and experience with time.
Not prerequisites, but having experience in the operating system internals and system development is definitely a plus.
Embedded systems are generally programmed in C, although there are systems at the ends of the range which use assembler when code space or timing is really tight (or there is no decent C compiler available), and at the other end, C++ up to .NET compact. It depends on what you mean by embedded systems, they go from really small microcontrollers with a few hundred bytes of RAM and program space, up to the smartphone type of device running a full multitasking operating system and user interface.
You'll get further in the higher end of this range without a background in electronics, because its less tied to the hardware and more similar to desktop development. As you go down the range of applications, a knowledge of electronics, analogue and digital, and power supplies, noise issues, compliance issues, heat issues and others all combine to make a really challenging design environment.
Start by reading some of the links here and embedded.com
The one thing that I have not seen mentioned in the answers so far is that up until now you have probably done most of your coding in the context of an operating system. In many (perhaps most?) cases, with firmware as opposed to software, you will not have the convenience and benefits of coding on top of an operating system. This is why so many of the other answers indicated that a good knowledge of electronics was critical.
As others mentioned, embedded can mean many things. In my world (Aerospace and Defense), we work with real-time operating systems (VxWorks and Integrity are the biggest players) and occasionally Linux. We program in C primarily, although C++ is also used as well if the project has decided to use Object Oriented Programming and Modeling.
So, as for the Pre-Reqs, C for sure. You really need to learn all about C, including BIT wise operations, dealing with hex values, pointers, all the low level stuff. Assembly as well, but I only use it for debugging the hardest stuff nowadays. You need to know enough to read and understand.
I think An Embedded Software Primer is a great start to change your thinking towards embedded. Handling interrupts, real-time issues, etc...
As Mickey mentioned, sometimes you don't even have an OS. In these cases, you usually write your own task manager of some sort, but that usually wouldn't be something for the newbie to start with. Good luck.
Languages: C, Assembler, Processing, Basic and a whole variety of others, it depends on what platform you're using as to what's available.
You might get more specific information if you ask the same question at ChipHacker or Electronics Exchange which are both stack exchange style sites (like this is) but geared to electronics and "physical computing".
You'll want to get pretty comfortable with C and build a solid understanding of assembly. In systems / embedded, usually you're working with small amounts of memory and slower processors, so you need to understand how to use limited resources wisely.
If you're getting into this as a hobby, pick up a gumstix board or an arduino, these dev boards will give you hundreds of hours of learning and fun.
If you're trying to make a career of this, find a job where the projects sound interesting and get your hands dirty. Take every task that comes your way and ask yourself how you can do better and learn from this task.
Either way, have fun and happy coding!
Learn C. Learn to apply C to all problems. Other languages can wait. Eventually assembly will help and no programmer should be without the use a scripting language.
Depending on what embedded targets you use there could be very little difference between a PC and your target. With little electronics background this would be your easiest entry.
Small processors will give you the the steepest learning curve but you will learn the most about embedded programming. However with no electronic background this can present extra problems you might not have the skills to solve yet.
Eventually you will have to learn electronics if you want to make further progress beyond the basics.
I've experience in doing desktop and web programming for a few years. I would like to move onto doing some embed system programming. After asking the initial question, I wonder which hardware / software IDE should I start on...
Arduino + Arduino IDE?
Atmel AVR + AVR Studio 4?
Freescale HCS12 or Coldfire + CodeWarrior?
Microchip PIC+ MPLAB?
ARM Cortex-M3 + ARM RealView / WinARM
Or... doesn't matter?
Which development platform is the easiest to learn and program in (take in consideration of IDE usability)?
Which one is the easiest to debug if something goes wrong?
My goal is to learn about "how IO ports work, memory limitations/requirements incl. possibly paging, interrupt service routines." Is it better to learn one that I'll use later on, or the high level concept should carry over to most micro-controllers?
Thanks!
update: how is this dev kit for a start? Comment? suggestion?
Personally, I'd recommend an ARM Cortex-M3 based microcontroller. The higher-power ARM cores are extremely popular, and these low-power versions could very well take off in a space that is still littered with proprietary 8/16-bit cores. Here is a recent article on the subject: The ARM Cortex-M3 and the convergence of the MCU market.
The Arduino is very popular for hobbyist. Atmel's peripheral library is fairly common across processor types. So, it would smooth a later transition from an AVR to an ARM.
I don't mean to claim that an ARM is better than an AVR or any other core. Choosing an MCU for a commercial product usually comes down to peripherals and price, followed by existing code base and development tools. Besides, microcontrollers are general much much simpler than a desktop PC. So, it's really not that hard to move form one to another after you get the hang of it.
Also, look into FreeRTOS if you are interested in real-time operating system (RTOS) development. It's open source and contains a nice walk through of what an RTOS is and how they have implemented one. In fact, their walk-through example even targets an AVR.
Development tools for embedded systems can be very expensive. However, there are often open source alternatives for the more open cores like ARM and AVR. For example, see the WinARM and WinAVR projects.
Those tool-chains are based on GCC and are thus also available (and easier to use IMHO) on non-Windows platforms. If you are familiar with using GCC, then you know that there are an abundance of "IDE's" to suit your taste from EMACS and vi (my favorite) to Eclipse.
The commercial offerings can save you a lot of headaches getting setup. However, the choice of one will very much depend on your target hardware and budget. Also, Some hardware support direct USB debugging while others may require a pricey JTAG adapter.
Other Links:
Selection Guide of Low Cost Tools for Cortex-M3
Low-Cost Cortex-M3 Boards:
BlueBoard-LPC1768-H ($32.78)
ET-STM32 Stamp Module ($24.90)
New Arduino to utilize an ARM Cortex-M3 instead of an AVR microcontroller.
Given that you already have programming experience, you might want to consider getting an Arduino and wiping out the firmware to do your own stuff with AVR Studio + WinAVR. The Arduino gives you a good starting point in understanding the electronics side of it. Taking out the Arduino bootloader would give you better access to the Atmel's innards.
To get at the goals you're setting out, I would also recommend exploring desktop computers more deeply through x86 programming. You might build an x86 operating system kernel, for instance.
ARM is the most widely used embedded architecture and covers an enormous range of devices from multiple vendors and a wide range of costs. That said there are significant differences between ARM7, 9, 11, and Cortex devices - especially Cortex. However if getting into embedded systems professionally is your aim, ARM experience will serve you well.
8 bit architectures are generally easier to use, but often very limited in both memory capacity and core speeds. Also because they are simple to use, 8-bit skills are relatively easy to acquire, so it is a less attractive skill for a potential employer because it is easy to fulfil internally or with less experienced (and therefore less expensive) staff.
However if this is a hobby rather than a career, the low cost of parts, boards, and tools, and ease of use may make 8 bit attractive. I would suggest AVR simply because it is supported by the free avr-gcc toolchain. Some 8 bit targets are supported by SDCC, another open source C compiler. I believe Zilog make their Z8 compiler available for free, but you may need to pay for the debug hardware (although this is relatively inexpensive). Many commercial tool vendors provide code-size-limited versions of their tools for evaluation and non-commercial use, but beware most debuggers require specialist hardware which may be expensive, although in some cases you can build it yourself if you only need basic functionality and low speeds.
Whatever you do do take a look at www.embedded.com. If you choose ARM, I have used WinARM successfully on commercial projects, although it is not built-for-comfort! A good list of ARM resources is available here. For AVR definitely check out www.avrfreaks.net
I would only recommend Microchip PIC parts (at least the low-end ones) for highly cost sensitive projects where the peripheral mix is a good fit to the application; not for learning embedded systems. PIC is more of a branding than an architecture, the various ranges PIC12, 16, 18, 24, and PIC32 are very different from each other, so learning on one does not necessarily stand you in good stead for using another - often you even need to purchase new tools! That said, the dsPIC which is based on the PIC24 architecture may be a good choice if you wanted to get some simple DSP experience at the same time.
In all cases check out compiler availability (especially if C++ support is a requirement) and cost, and debugger hardware requirements, since often these will be the most expensive parts of your dev-kit, the boards and parts are often the least expensive part.
This is kind of a hard question to answer as your ideal answer very much depends on what it is your interested in learning.
If your goal is just to dive a little deeper into the inner workings of computing systems i would almost recommend you forgo the embedded route and pick up a book on writing a linux kernel module. Write something simple that reads a temperature sensor off the SMbus or something like that.
If your looking at getting into high level (phones, etc) embedded application development, download the Android SDK, you can code in java under eclipse and even has a nice emulator.
If your looking at getting into the "real" microcontroller space and really taking a look at low level system programming, i would recommend you start on a very simple architecture such as an AVR or PIC, something without an MMU.
Diving into the middle ground, for example an ARM with MMU and some sort of OS be it linux or otherwise is going to be a bit of a shock as without a background is both system programming and hardware interfacing i think the transition will be very rough if you plan to do much other than write very simple apps, counting button presses or similar.
Texas Instruments has released a very interesting development kit at a very low price: The eZ430-Chronos Development Tool contains an MSP430 with display and various sensors in a sports watch, including a usb debug programmer and a usb radio access point for 50$
There is also a wiki containing lots and lots of information.
I have already created a stackexchange proposal for the eZ430-Chronos Kit.
No it doesn't matter if you want to learn how to program an embedded device. But you need to know the flow of where to start and where to go next. Cause there are many micro-controllers out there and you don't know which one to choose. So better have a road-map before starting.
In my view you should start with - Any AVR board (atmega 328P- arduino boards or AVR boards)
then you should go to ARM micro-controller - first do ARM CORTEX TDMI
then ARM cortex M3 board.Thus this will give you an overall view after which you can choose any board depending on what kind of project you are working and what are your requirements.
Whatever you do, make sure you get a good development environment. I am not a fan of Microchip's development tools even though I like their microcontrollers (I have been burned too many times by MPLAB + ICD, too much hassle and dysfunction). TI's 2800 series DSPs are pretty good and have an Eclipse-based C++ development environment which you can get into for < US$100 (get one of the "controlCARD"-based experimenter's kits like the one for the 28335) -- the debugger communications link is really solid; the IDE is good although I do occasionally crash it.
Somewhere out there are ICs and boards that are better; I'm not that familiar with the embedded microcontroller landscape, but I don't have much patience for poor IDEs with yet another software tool chain that I have to figure out how to get around all the bugs.
Some recommend the ARM. I'd recommend it, not as a first platform to learn, but as a second platform. ARM is a bit complex as a platform to learn the low-level details of embedded, because its start-up code and initialisation requirements are more complicated than many other micros. But ARM is a big player in the embedded market, so well worth learning. So I'd recommend it as a second platform to learn.
The Atmel AVR would be good for learning many embedded essentials, for 3 main reasons:
Architecture is reasonably straight-forward
Good development kits available, with tutorials
Fan forum with many resources
Other micros with development kits could also be good—such as MSP430—although they may not have such a fan forum. Using a development kit is a good way to go, since they are geared towards quickly getting up-and-running with the micro, and foster effective learning. They are likely to have tutorials oriented towards quickly getting started.
Well, I suppose the development kits and their tutorials are likely to gloss over such things as bootloaders and start-up code, in favour of getting your code to blink the LED as soon as possible. But that could be a good way to get started, and you can explore the chain of events from "power-on" to "code running" at your pace.
I'm no fan of the PICs, at least the PIC16s, due to their architecture. It's not very C-friendly. And memory banks are painful.
It does matter, you need to gradually acquire experience starting with simpler systems. Note that by simpler I dont mean less powerful, I mean ease of use, ease of setup etc. In that vein I would recommend the following (I have no vested interest in a any of the products, I just found them the best):
I've started using one of these (MBED developer board). The big selling points for me were that I could code in C or C++, straightforward connection vis USB and a slick on-line development environment (no local tool installation required at all!).
http://mbed.org/
Five minutes afer opening box I had a sample blinky program (the 'hello world' of the emedded world) running the following:
#include "mbed.h"
DigitalOut myled(LED1);
int main()
{
while(1)
{
myled = 1;
wait(0.2);
myled = 0;
wait(0.2);
}
}
That's it! Above is the complete program!
It's based on ARM Cortex M3, fast and plenty of memory for embedded projects (100mhz, 256k flash & 32k ram). The online dev tools have a very good library and plenty of examples and theres a very active forum. Plenty of help on connecting devices to MBED etc
Even though I have plenty of experience with embedded systems (ARM 7/9, Renases M8/16/32, Coldfire, Zilog, PIC etc) I still found this a refreshingly easy system to get to grips with while having serious capability.
After initially playing with it on a basic breadboard I bought a base board from these guys: http://www.embeddedartists.com/products/lpcxpresso/xpr_base.php?PHPSESSID=lj20urpsh9isa0c8ddcfmmn207. This has a pile of I/O devices (including a miniture OLED and a 3axis accelerometer). From the same site I also bought one of the LCPExpresso processor boards which is cheap, less power/memory than the MBED but perfect for smaller jobs (still hammers the crap out of PIC/Atmega processors). The base board supports both the LCPExpresso and the MBED. Purchasing the LCPExpress processor board also got me me an attached JTAG debugger and an offline dev envoronment (Code Red's GCC/Eclipse based dev kit). This is much more complex than the online MBED dev environment but is a logical progression after you've gained expeience with the MBED.
With reference to my original point noite that the MBED controller is much more capable than the the LPCExpresso controller BUT is much simpler to use and learn with.
I use microchips PIC's, its what I started on, I mainly got going on it due to the 123 microcontroller projects for the evil genius book. I took a Microprocessors class at school for my degree and learned a bit about interrupts and timing and things, this helped a ton with my microcontrollers. I suppose some of the other programmers etc may be better/easier, but for $36 for the PicKit1, I'm too cheap to go buy another one...and frankly without using them I don't know if they are easier/better, I like mine and recommend it every chance I get, and it took me forever to really actually look at it, but I was able to program another chip off board with ICSP finally. I don't know what other programmers do it, but for me that's the nicest thing 5 wire interface and you're programmed. Can't beat that with a stick...
I've only used one of those.
The Freescale is a fine chip. I've used HC-something chips for years for little projects. The only caveat is that I wouldn't touch CodeWarrier embedded with a 10 foot pole. You can find little free C compilers and assemblers (I don't remember the name of the last one I used) that do the job just fine. Codewarrior was big and confusing and regardless of how much I knew about the chip architecture and C programming always seemed to only make things harder. If you've used Codewarrior on the Mac back in the old days and think CW is pretty neat, well, it's not at all like that. CW embedded looks vaguely similar, but it works very differently, and not very well.
A command-line compiler is generally fine. Professionals who can shell out the big bucks get expensive development environments, and I'm sure they make things better, but without that it's still far better than writing assembly code for a desktop PC in 1990, and somehow we managed to do that just fine. :-)
You might consider a RoBoard. Now, this board may not be what you are looking for in terms of a microcontroller, but it does have the advantage of being able to run Windows or DOS and thus you could use the Microsoft .NET or even C/C++ development tools to fiddle around with things like servos or sensors or even, what the heck, build a robot! It's actually kinda fun.
There's also the Axon II, which has the ATmega640 processor.
Either way, both boards should help you achieve your goal.
Sorry for the robotics focus, just something I'm interested in and thought it may help you too.
I use PICs, but would consider Arduino if I chose today. But from your goals:
how IO ports work
memory limitations/requirements
interrupt service routines
I wonder if you best bet is just to hack in the Linux kernel?
BBC Micro Bit
https://en.wikipedia.org/wiki/Micro_Bit
This cheap little board (~20 pounds) was crated by ARM Holdings as an educational device, and 1M units were given out for free to UK students.
It contains an ARM Cortex-M0, the smallest ARM core of all.
I recommend it as a first micro-controller board due to its wide availability, low cost, simplicity, and the fact that it introduces you to the ARM architecture, which has many more advanced boards also available for more serious applications.
How can I make my own microcontroller? I've done some work using GAL chips and programmed a chip to do simple commands such as add, load, move, xor, and output, but I'd like to do something more like a real microcontroller.
How can I go about doing this? I've read a little bit about FPGA and CPLD, but not very much, and so was looking for some advice on what to get and how to start developing on it.
Look here for a good wiki book. I had some coursework I wrote when I was teaching Electronic Eng, but I couldn't find it around. When I was teaching, most of the students were happy to use the schematic capture tools in the Xilinx Foundation package. They've moved onto ISE and WebPACK now. You can download the WebPack for free, which is useful, and it has schematic capture and simulation in it.
If you really want to shine, learn VHDL or Verilog (VHDL seems to be more common where I've worked, but that is only a small smattering of places) and code the design rather than enter it through the GUI.
If you know ANYTHING at all about digital logic design (and some HDL) I rekon you can have a somewhat functional 8-bit microprocessor simulating in VHDL in about 2 days. You're not going to build anything blazingly fast or enormously powerful in that time but it's a good starting point to grow from. If you have to learn about digital design, factor in a couple of days to learn how the tools work and simulate some basic logic circuits before moving onto the uP design.
Start learning the basics of digital systems, and how to build a binary adder. Move on to building an ALU to handle addition, subtraction, and, or, xor, etc and then a sequencer to read opcodes from RAM and supply them to the execution unit.
You can get fancy with instruction set design, but I'd recommend starting out REALLY simple until you have your head around whats going on, then throw it out and start again with something more complex.
Once you have the design simulating nicely you can gauge its complexity and purchase a device to suit. You should look at a development system for the device family you've chosen. Pick a device bigger than what you need for development because it's nice to be able to add extra instrumentation to debug it when it's running, and you almost certainly won't have optimized your design in the early stages of getting it on the device.
EDIT: Colin Mackenzie has a good tutorial about uC design and some FPGA boards as well as a bit of other stuff.
You may want to have a look around OpenCores.org, a "forge" site for open source IP core development. Also, consider getting yourself a development board like one of these to play around with.
Much of the tools ecosystem revolves around VHDL, although Avalda is working on tools to compile F# for FPGAs.
I saw a textbook once that stepped through building a machine from TTL chips. This had the same instruction set as a PDP-8, which is very - and I mean very - simple, so the actual machine architecture is easy to implement in this way.
The PDP-8 FAQ mentions a book: "The Art of Digital Design," second edition, by Franklin Prosser and David Winkel (Prentice-Hall, 1987, ISBN 0-13-046780-4). It also mentions people implementing it in FPGA's.
Given the extreme simplicity of this CPU architecture and availability of PDP-8 code or reference implementations it might be a good starting point to warm up with.
Alternatively, an acquaintance of mine implemented a thumb (cut down ARM) on a FPGA as a university project run by one Steve Furber (a prominent Acorn alumnus). Given that this could be compressed into a format small enough for a university project it might also be a good start.
To play with soft-core microprocessors, I like the Spartan 3 Starter Board from Digilent just because it has 1M of static RAM. SDRAM and DDR RAM are harder to get going, you know.
The leds, switches and a simple serial interface are a plus to debug and communicate.
As someone already pointed out, OpenCores.org is a good place to find working examples. I used the Plasma uC to write some papers while on university.
A microcontroller can be as simple as a ROM (instruction*2^x + (clock phase) is the address, outputs are the control signals, and you're good to go). Or it can be a complex harry beast with three arms and branch prediction support hardware.
Can you give more details about your aspirations?
After searching some very helpful links by all of you, I came across this Wikiversity course.
One of the first sentences is, "Have you ever thought to build your own microprocessor?"
Xilinx has a MicroBlaze and a PicoBlaze soft controller for its FPGAs. The latter is free, while, IIRC, the Microblaze is to be paid for.
As its name suggests the PicoBlaze is a small processor, which has its limitations, but OTOH is compact enough to run on a CPLD. Anyway a nice processor to get you started.
Pablo Bleyer has a PicoBlaze-compatible PacoBlaze. PacoBlaze was written in Verilog (which, like Adam said, less common than VHDL).
You need a big fpga for a little mcu.
You need a fpga with the correct hardware blocks if you need things like AD.
You need a soft core to put into the fpga.
But how about to just play around with a normal MCU before this project,
so you kind of know where you are going? How about some AVR:s from Atmel.
You can get free samples of pic micro controllers at this site. Last I knew, you don't even have to pay shipping.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=64
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which family should I start to learn? (Never did any programming on microcontroller)
Today AVR and PIC are probably the most common microcontrollers among hobbyists. Both have a very wide range of device variants and both can be used to achieve similar results.
For a beginner I would suggest AVR due to various reasons:
AVR family (tiny, mega) is coherent and easy to understand. The architecture is powerful and modern, and is especially suitable for C compilers. AVRs can of course be programmed in assembly too.
Due to its C-friendly architecture, there are quality C compilers available, both commercial and free. The ubiquitous GCC is ported to AVR and called avr-gcc.
For getting started all you really need is a handful of basic components, the AVR chip itself and a breadboard. Even the programming cable between PC and AVR can be built essentially for free (a so called wiggler). However, several commercial development kits are available, most notably Atmel's own STK500. A commercial development kit is more expensive way for getting started, but doesn't require practically any prior knowledge about electronics. Some development kits contain for example LCD displays so it's easy to get interesting stuff done.
It has a rich hobbyist community.
PIC is notorious for its peculiar architecture. Many love PIC for this, some hate it. AVR is more straightforward and doesn't seem to cause as much extreme and polar opinions.
Both AVR and PIC are used in many serious commercial applications. However, they are not the only options of course. My personal favorite microcontroller for both hobby and commercial work is Silicon Laboratories' C8051 family, most notably C8051F530. There is an excellent free C compiler and assembler for the C8051 family called SDCC.
Summary: There are lots of options, but please don't let that overwhelm you. Just pick one and start learning with it. Microcontrollers are, really, surprisingly easy to master once you just decide to get going!
My boss picked up the basics using AVR within a week without prior experience.
I would suggest AVR. It has far surpassed PIC as the microcontroller platform of choice for general hobbyist projects. Most notably, consider the Arduino (and other *duino) platform, which provides a high end AVR in an easy to interface and popular form factor.
I very much prefer the AVR over PIC, whose architecture I find a bit messy. This may be just me, and it won't trouble you if you can write in a high level language, most likely (some dialect of) C.
Since you're new to microcontrollers I presume performance will not be the issue, so instead I would look for availability of development tools: prototyping boards, IDE and simulation/debugging tools. Personally I liked AVR Studio (Atmel's free development environment) a lot.
Jason mentions the TI's MSP430, which is an excellent controller indeed, especially if you're in very low power applications. But I wouldn't recommend it for a newbie, since configuration is a bit cumbersome. (I recall that the description of the oscillator covered 20+ pages in the user manual.)
Some people commented on the strange (and C unfriendly) architecture of the PIC micro. This is true of the smaller PICs, but the 16 bit chips (PIC24F, dsPIC30, etc) have very clear architectures that work very well with C.
The PIC24F line has the ability to assign pins to functions (timers, A/D, serial I/O) on the fly, making it a bit easier to design with. The MPLAB environment for debugging and development is quite nice.
I've done some PIC programming - mostly because I liked the idea the chip were only a dollar or two. However, for a beginner, making a decision solely on price is premature optimization.
Programming in assembler is an experience. You basically have to learn about 100 concepts before you can blink an LED. (Watchdog timer, reset pins, 8-bit counters/overflows, delay loops, hex, binary, bit-masking, interrupts, interrupt service requests, IO ports, etc.) It's all very educational - and a great feeling to get so close to the machine - but being able to code something in C will hide some of this complexity so you can focus on results. For this reason I would say go with the AVR. (And I believe the prices are now closer to PICs.)
Also: If you're interested in getting things done (and don't mind spending ~$30) check out the arduino. A guy selling them at my local electronics shop was saying he's selling tons of them to art students. (It uses the IDE from the Processing project, and compiles code with avr-gcc.)
Update: Fixed comment that Arduino runs interpreted code. Also updated the approx Arduino price.
I don't understand what the big deal with arduino is, it will ruin your chance of ever understanding what is actually happening. I program with AVR's and PIC's regularly, basically there is not much difference, I can't see what the big fuss is all about.
However for a beginner stay away from arduino, it may be simple, but thats the trap, it gives you no concept of hardware architecture, and no idea what is happening behind the scenes, the stuff beginners need to learn to be an effective programmer.
When I was a beginner I started out with an ATmega32 a $20 USBasp programmer, AVR Studio (Free) and AVRDude (Comes with WinAVR) and followed the intro tutorials in AVR Freaks.
That is all you need, Done!!!
P.S. If you want to really learn how to program micros and have the time learn the assembler for your micro and you will be 20 times the C programmer than someone who started out using arduino.
My vote goes to PIC for the extreme variety of devices availables. But I must say that when I started to use PICs, they was almost nothing else. Maybe now things are changed.
I vote for TI's MSP430 series. I've used PICs extensively (also Atmel chips a little) and by far the most important thing to me is a good debugging IDE. TI has done a pretty good job on this, and their C++ compiler works really well. You can get going with an eval board for less than $100 including an IDE + USB-debugger. The PICs have better & more diverse hardware peripherals, but MPLAB is a piece of crap and the only C++ IDE for PICs is one by IAR which is rather expensive. (more than $2K)
I/we chose PIC mostly because there is more peripheral hardware for the same price. And more importantly, you can't even find comparable AVRs. I did choose one of the legacy free versions though (started with PIC18, migrated to dspic33)
The IDE is free, the (C) compiler is free in the student version (that disables optimization after the first month). Entry level programmers are fairly cheap too. If you have heaps of interrupts, counters and timers, there is a chance you won't need optimization at all. A programmer straight from Microchip is $30.
Note that the above remarks about AVR catering more to HLL development are slightly outdated unless you really go for the legacy architectures like PIC12 and 16.
One typically programs the more modern PIC18 (8-bit) and the 16-bit architectures (24F,30F and dspic33 which are based on the same principal core) in C. The 16-bitters even use GCC. There are also MIPS based 32-bitters now, but they rival more with ARM in the audio/video processing scene. Strangely enough, the modern ones are often cheaper than the old ones. Probably they are produced on in a more modern process that has higher yields.
Another note: meanwhile Microchip/PIC bought Atmel/AVR, but I assume that for the first few years that won't affect the productlines much.
I'm really looking forward to the 60MIPs ethernet enabled 16-bitter that is going to be released this summer (afaik streetprice just above EUR 10)
If you just want to know what is MCU programming, start from Arduino is a good idea. It's cheap, with a novice-friendly IDE (based on processing programming language, which has a similar syntax with C).
But this did not answer your quesiton, beacuse altough Arduino is based on AVR, you cannot feel there is an AVR MCU behind that modern IDE. :)
I had much more success with PIC while I was just getting started. I tried to get a simple starter kit from Arduino and just couldn't get a good basic kit without spending more than $100-200 nickel and diming the setup together. Got a great little starter kit from PIC for about $40 and it has everything: IDE, programmer, starter board with built in circuitry for demos and tutorials. One purchase. Also, the PIC environment was very easy to get set up and working. I was playing with it within an hour.
My first experience with microcontrollers was with an OOPic-R. It allowed me to make simple robotic experiments without worrying too much about the code. The object oriented programming flow makes everything work fast and is easy to program.
Recently, I tried another variety of PIC's, the dirt cheap PICAXE. The included programming interface is a breeze to work with. Also, to physically interface the PICAXE, you only need an RS-232 port to program it and two pins on the chip (no need to do level shifting). I've embedded the PICAXE in very small containers (SMD and DIP chips available) and it has worked quite well.
I have no experience with programming microcontrollers in assembly. If you want to try that, the AVR might be more suitable because of it's bigger user community.
As far as I know, the cheapest way to program an AVR using ATMEL's tools is the ATMEL AVR ISP mkII for 35$. You can find third-party programmers for 10-15$.
I would make my choice based on availability of a C cross-compiler. In the past, that would make AVR the choice. I'm not sure what the status is now.
I've programmed a PIC in assembler, and it was not much fun. C is much nicer in many ways.
http://www.arduino.cc/
HTH
On of the best features of AVR is the community in the forums at www.avrfreaks.net. You get a bunch of experienced electronics engineers hanging out, willing to help newbies to get going.
I would say that i fount the 8051 microcontroller the most easiest and Atmel has come up with microcontrollers with so many inbuilt functions .... but still people are more preferably using the AVR's... my hand would go up with the 8051 family ( if found comfortable ) else the AVR's ...
I love AVR. its easy to program and resources available. there are few community like arduino works with it.
Some more dicussion about the superiority of AVR, on the other Stack Overflow:
http://embeddedgurus.com/stack-overflow/2009/04/pic-stack-overflow/
The popularity of 8 bit PICs baffles me. It’s architecture is awful –
the limited call stack is just the first dreadful thing. Throw in the
need for paging and banking together with the single interrupt vector
and you have a nightmare of a programming model. It would be one thing
if this was the norm for 8 bit devices – but it isn’t. The AVR
architecture blows the PIC away, while the HC05 / HC08 are also
streets ahead of the PIC. Given the choice I think I’d even take an
8051 over the PIC. I don’t see any cost advantages, packaging
advantages (Atmel has just released a SOT23-6 AVR which is essentially
instruction set compatible with their largest devices) or peripheral
set advantages. In short, I don’t get it! Incidentally, this isn’t an
indictment of Microchip – they are a great company and I really like a
lot of their other products, their web site, tech support and so on
(perhaps this is why the PIC is so widely used?)
I started on a Motorola M68HC11, it was simple enough. I think you'll get about the same experience with any 8Bit controllers.