Microcontrollers, SoC's, CPU's, ARM and programming of those things

Question

Hello everyone,

Up to now, I have been programming 8 bit AVRs (in C). I now ordered Raspberry Pi and I want to switch on to a little more advanced chips (eg. ARM in RPi and AVR32).

I have trouble understanding how all the "more advanced" chips work and how they are programmed.

This is what I know (or I think is true):

I know that to get a microcontroller to work, I need to write a program on the computer and program the device through a programmer.

This also applies to 32-bit microcontrollers (many of which are ARM based). In this case, apart of boot-loading or company specific port, only JTAG would program the device.

ARM is just an architecture, or a "template" to some extend, that gives base to uC's and so there are many different companies making their 32bit around ARM.

Above ARM and 32 bit uC are Embedded solutions, eg. SoC's which are a composition of at least one microcontroller inside (commonly ARM), some flash, RAM, ROM, GPU optionally, etc.

SoC's are good to run a simple OS like Linux. A GPU is a separately programmable part of an SoC.

CPU is not a microntroller, is very fast and does the instructions which are given it.

JTAG is a universal device that can debug and programm all JTAG supportive devices, given I have appropriate software.

Now things I don't understand:

SoC's have a microcontroller inside them, so they must be programmable, but are they all like that? Does an SoC have a program stored in it's flash, that it fetches instructions from, just like an 8bit?

Something must take files from an SD card and run them in a Raspberry Pi, something must tell the GPU inside what display interface to use etc, but I can't find a source code, or an evidence of a program being run inside a SoC.

How is it really happening? (1)

About CPUs, I think they are not programmable, so they are supported by BIOS that fetches the initial instructions from HDD boot section and the CPU automatically performs all what is given to it, and so, the motherboard has to take care of all the results the CPU "throws out".

Is this really what is happening? (2)

About JTAG. It is mainly a test solution for debugging etc, but one of its uses is accessing the memories of a micronotroller, so they can be therefore programmed. But then why are there so many different JTAGs on the market?

Why isn't one JTAG IEEE 1149.1 compatible with ALL the chips? The instructions are universal, aren't they? Why is there a special JTAG for AVR32 and a different one for Xilinx? (3)

I am sorry to ask so many questions, but I really couldn't find very much information about those and I think a discussion like this would help people by bringing these answers in one place. I have numbered three distinct issues.

If there is something I misunderstand in the first part, please tell me as it may be trivial to some people, but not as such to me.

Thanks,

Wojciech

Former Member · Answer

About question 2: Here is what I can tell you: Yes, a CPU performs what it is given to it... To do so, it has registers witch are small blocks of real physical memory in the CPU. The quantity varies with the CPU. What is happening in there is: The instruction is loaded from the memory to the register called the "instruction register" .This in called a "Fetch". It decodes the value in the register to understand what it has to do. To put it simple, depending on the binary value in this (8,16,32,64) bit register, he will understand : what to do, from where to take the information (at what address in memory or in what register) and where to put it (at what address in memory or in what register). This is called a "Decode". Then it executes what it has decoded. "Execute" Finally writes what is necessary into memory. "Memory acess and register write back" So it is not exactly the motherboard that takes care of the information it is the CPU itself. But for a big flow of data, for exemple you move a file from one harddrive to another, the CPU does not move each block of 32 bits one by one, he usually asks another process to do so. In a computer it's the DMA. ( http://en.wikipedia.org/wiki/Direct_memory_access ) Another thing that will help you developp your understanding on "whats's going on in there?" is memory hierachy. "The memory hierarchy in most computers is: Processor registers – the fastest possible access (usually 1 CPU cycle), only hundreds of bytes in size Cache (if present) – often accessed in just a few cycles Main memory or RAM – many cycles. Mass storage (Harddrive, SD card) – lots of cycles to acess it." This is information that I simplified from wikipedia. So information flows upwards and downwards in a way that the CPU does what you've asked for. Also, I would add, when you say: "CPU is not a microcontroller" this is 100% true but a microcontroller has a CPU! Because it has to execute code. For exemple: PICs from microchip has a RISC CPU (that they designed themselves) Arduino, (Atmega) from Atmel has RISC CPU (that they designed themselves) LPC microcontrollers from NXP has a ARM CPU on them (ARM7,ARM9, Cortex M0, Cortex M4...) Now for a part of your Question 1: A SoC is a microcontroller on steroids, much (harder), better, faster, stronger... And like a microcontroller, it has a CPU (better and faster usually), more RAM, more memory more functions. But how does it work on a Raspberry Pi? I don't know *yet*, I intent to know soon! I'm really looking forward to get one!!! I hope it wasn't too technical (or not enough)...

Kelv · Answer

ok, please remember this reply is all generic SoC, if you would like to send me your Pi I will be happy to look further into it for you

1+2) Whilst I can't comment on the boot process of the Pi, generally there is an area of flash/ROM that contains a boot loader, This in some cases is read only in others fully reprogramable. This bootloader then configures the rest of the hardware, UART, displays, sdcard etc. The boot loader is then responsible for what happens next ie boot from SD, flash etc.

If you are interested you may want to have a scan of the U-boot repo (http://www.denx.de/wiki/U-Boot) as this has helped me in the past getting stated with a number of SoC style devices.

3) J-tag... this is a personal bug bear of mine. Yes, they should all be compatible, the main issues are voltage level and vendor software lock-ins. Voltage levels are pretty straight forward to get around but being required to use a specific J-tag interface because of a hardware/software tie in is not. There are open source debug interface available that can be used in conjunction with OpenOCD that will allow you to debug/program devices from numerous manufacturers. Being open source OOCD enables you to add new devices if you feel so inclined. OpenOCD will allow you to interface open hardware J-tag interfaces along with commercial ones, to any supported device, just be really wary about the voltage levels involved.

Let me know if there is anything specific you want to know and I'll do my best to help out.

Former Member · Answer

About what a CPU executes when the power is turned on, I'm not sure, I will let somebody else answer this question. From what I remember, it goes executes the instruction to a specific address (that is not 0x00000000)... As for your edit on FT2232H: To know what is devices are compatible with your board, I would look at these first: On their TIAO's wiki: http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User's_Manual in OpenOCD documentation: http://openocd.sourceforge.net/doc/html/Debug-Adapter-Hardware.html#Debug-Adapter-Hardware and on FTDI's website : http://www.ftdichip.com/Products/ICs/FT2232H.htm You will find that with TIAO's board, beacuse of the FT2232H, you can do more than just JTAG. I use a similar IC in one of my projects (a FT232H), so the EEPROM they are talking about is on FTDI's web site. Browse a bit, they have a software that you need to download. This software allows you to program the EEPROM so that you can change the type of conversion the device does : USB to I2C, USB to SPI.... Also, they have "application notes" that tells you how to do it, what to do and so forth.... And to answer you question: I don't know if you can program *any* devices but It would be safe to say "most devices"

Microcontrollers, SoC's, CPU's, ARM and programming of those things

Top Replies