Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 14 replies
  • Answers 3 answers
  • Subscribers 472 subscribers
  • Views 1892 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

Parents
  • 0

    1) as far as I know there is a bootloader in there. It may be configurable or not, this is the decision of the product manufacturer. In the case of the Raspi it is not: it's hardcoded to load from the GPU firmware, fetch the kernel which must be compiled in a certain way and reside in a certain area of the SD, and jump to this kernel.

    I don't remember the name, but I've seen an ARM devboard which has jumpers to select the bootloading source: it could span from internal flash, to nand, to ethernet to usb. Quite neat!

     

    2) the BIOS name really tells it all: Basic Input Output System.

    Since x86 became really complex (remember it's a CISC), the CPU in an x86 system is not the only processor. The biggest processing fragmentation was in the first 2000:

     

    • CPU
    • North Bridge
    • South Bridge
    • VideoCard/GPU

     

    Each of these was and is a processor in its own right, but tailored to some specific work. The CPU doesn't have a predetermined path, so it must be fed instructions and data. N/S bridges had their own program hardcoded, oftentimes these are ASICs and/or FPGAs. Videocard did have pre-determined programs, now they are a different kind of CPU (in essence a VPU: vector processing unit).

    So to be fully programmable the CPU, as any 8-bit MCU, when starting up, jumps to an hardcoded address to load the first instruction.

    This address is the bios.

    The bios contains the basic programs to access memory and storage in a simple manner. Nowadays for example memory control is passed to the CPU's own memory controller as both AMD and Intel have integrated this component in the CPU to diminish latency.

    The bios is essentially like configuring your AVR to use the Parallel Master Port to access some ram/rom, or the SPI to access an SD.

    The bios does exactly the same for an x86 CPU.

Reply
  • 0

    1) as far as I know there is a bootloader in there. It may be configurable or not, this is the decision of the product manufacturer. In the case of the Raspi it is not: it's hardcoded to load from the GPU firmware, fetch the kernel which must be compiled in a certain way and reside in a certain area of the SD, and jump to this kernel.

    I don't remember the name, but I've seen an ARM devboard which has jumpers to select the bootloading source: it could span from internal flash, to nand, to ethernet to usb. Quite neat!

     

    2) the BIOS name really tells it all: Basic Input Output System.

    Since x86 became really complex (remember it's a CISC), the CPU in an x86 system is not the only processor. The biggest processing fragmentation was in the first 2000:

     

    • CPU
    • North Bridge
    • South Bridge
    • VideoCard/GPU

     

    Each of these was and is a processor in its own right, but tailored to some specific work. The CPU doesn't have a predetermined path, so it must be fed instructions and data. N/S bridges had their own program hardcoded, oftentimes these are ASICs and/or FPGAs. Videocard did have pre-determined programs, now they are a different kind of CPU (in essence a VPU: vector processing unit).

    So to be fully programmable the CPU, as any 8-bit MCU, when starting up, jumps to an hardcoded address to load the first instruction.

    This address is the bios.

    The bios contains the basic programs to access memory and storage in a simple manner. Nowadays for example memory control is passed to the CPU's own memory controller as both AMD and Intel have integrated this component in the CPU to diminish latency.

    The bios is essentially like configuring your AVR to use the Parallel Master Port to access some ram/rom, or the SPI to access an SD.

    The bios does exactly the same for an x86 CPU.

Children
  • 0 in reply to Former Member

    Oh, that is great.

     

    It makes sense that the CPU runs BIOS now, but somehow before, I thought that BIOS is a separate "system" on the motherboard, that runs parallel to the CPU. Thanks for clarifying. This also explains why the chip with "BIOS" sticker on it is not a microcontroller, but a memory. It only has instructions for CPU.

     

    Good.

     

    This is very interesting, I will now read as much as possible on North/South Bridges, that got me interested...

     

    Sinistra92

  • 0 in reply to sinistra92

    Curiosity is the fuel of life image

     

    A sum-up:

    since the CPU is data-hungry (where data represents both the instruction and the actual data on which to operate), the first bottle-neck has always been the main bus.

    This has taken various forms (of which I'm not informed enough), but in essence it's a very wide (since the 386 it was already 32bits wide) parallel bus clocked as fast as possible.

    Since data may come from two sources (storage and ram), this bus was administered by the north-bridge.

    This chip controlled the ram (as you may know, nowadays modules have more then 200 pins, so think how many lines are needed just to control the ram) and passed other requestes to the south-bridge.

    This one, which still exists albeit possibly with other names, was in charge of all the other subsystems: usb,uart, pci, ide, sata, ata... you name it, and the SB managed it.

    In if you look at some Pentium4 or early Core schematics, you'd see the FrontSideBus (Intel TM) running from the CPU to the NB, and a slower bus from the NB to the SB.

    From the SB then dipanate all other buses.

     

    Nowadays the FSB has taken another name, but still connects the CPU to the SB, while the NB is integrated in the CPU itself.

    Essentially you have a very fast PCIX bus coming out of the CPU and linking it to the SB as well as to some other high-speed peripherals (GPUs namely), while low-speed ones are linked to the SB on slower PCIX lanes, the SB then aggregates data access and sends it to the CPU.

     

    Happy reading, it's a whole lot to digest! Pretty high tech stuff, but between wikipedia and old processor technical reviews (from the likes of tomshardware, anandtech, and others) you can learn a lot.

    I suggest you start from Pentium4 technology though, it was much simpler (so simple infact that AMD gained the technical and performance advantage in that period).

  • 0 in reply to Former Member

    Yes, this is a lot to digest, but I alwyas wondered how the CPU is connected to USB and all, but now I see!

    I don't know how this post got from uC and ARMs but I like it did.