Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 14 replies
  • Answers 3 answers
  • Subscribers 461 subscribers
  • Views 1514 views
  • Users 0 members are here
Related

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

sinistra92

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

  • 0

    Thanks for asking these questions as I had similar ones in my mind too never having worked with any embedded systems beyond 8-bit AVRs and PICs.  I am also wondering how the SoC boots Linux off the SD card.  Like you outline, there must be some type of bootloader in firmware (I'm thinking like how the Arduino serial bootloader is stored in AVR flash).

  • 0 in reply to fustini

    That would make a lot of sense, but I can't find a bootloader for say, Raspberry Pi, and no-one is talking about them either, just as if there wasn't one.

    Also I read in the FAQs section about Raspberry Pi that it doesn't have a BIOS per se. Maybe that means it is hardwired to boot up from SD...

     

    We need someone who has experience using System-on-Chip solutions.

  • 0

    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 image

     

    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.

  • 0

    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)...

  • 0

    Riiiiight...

     

    Thank you very much guys, I understand a lot more now.

     

    >Kelv:

    So if a manufaturer makes a read-only bootrstrap section, then the cpu looks for the binaries always in the same place (as it appears to be with RPi: it always looks for kernel.img on the memory card and runs it) but the manufacturer probably doesn't disclose what bootstrap there is, unless to professional designers, I guess (requiring NDA). In programmable cases we could write our own, or just make a program that would go to the flah straight in.

     

    Then the software difference between a SoC and a normal 32bit microcontroller is mainly the fact that instead of having all the program in their flash memory, they use bootloader to download (or run straight) from external memory, eg. SD. Am I more or less right?

    If so, then I suppose that the bootloader is a lot smaller comparing to a typical ARM flash memory, not in a SoC.

     

     

    >Nicolas:

    In a case you described, what is the first thing that loads the first instruction from memory (HDD bootloader section, I presume) into CPU working registers? Is it BIOS?

    Or does the CPU have an initial algorith-like sequence that fetches the first instructions?

     

     

    Thanks,

    Wojciech

     

    Edit:

     

    Ah, one more thing:

    I got myself the FT2232H USB to JTAG adapter (a while ago, now), which is said to be working well with OOCD.

    Now, how do I know what devices are compatible with this adapter, as no-one actually says that their microcontroller only accepts such vid's and pid's?

    I assume it is the jtag device (adapter) that has to be compatible with the uC, not debugger running on computer.

    The board I have is called TIAO USB Multi-Protocol Adapter (TUMPA)and it is claimed to have an eeprom that can be programmed with own vendor and product ID's.

    Does that mean It can program any device?

  • 0

    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:

     

    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"

  • 0 in reply to Former Member

    Yes, I looked at most of the stuff, although most of it isn't helpful.

     

    This shows:

    http://www.youtube.com/watch?v=rnukKDyj4LI

    that FT2232 can program LPC176x devices (using OOCD), so at least I can play with those for now.

     

    I am not sure, but it seems that the biggest problem is to get the right support on the computer side for the chip, as the jtag itself is flexible for many of them.  Once I get my TUMPA (shipped from Canada to UK) and a few ARM or AVR32 or others, I'll post around.

    I was really confused about all this JTAG thing, because I thought since it doesn't say in datasheet of a device it can be programmed by JTAG, then it couldn't. Apparently it often is not the case.

  • 0

    Nice video!

     

    Well, I would be glad to hear from your projects with your TUMPA! Sure post around and keep me informed!

  • 0 in reply to Former Member

    But by no means think this is my video. No.

    I just found it while browsing about TUMPA.

     

    Sorry to mislead you,

     

     

    I decided to get more experience in 32bits, possibly in ARM assembly and then introduce myself to SoC's and then do bare metal RPi.

  • 0

    Hehe by nice video, I meant that I have enjoyed it.

     

    About 32 bits ARM and LPC a guy from Calgary, Canada gives a course at Calgary U and made this website:http://www.engenuics.com/mpgnotes.php

    I learned about ARM microcontrollers on that website. Hope you could find something useful there.