[Computer architecture - lowest level ] How CPU fetch binary

[Aslaville]

Yeah, because you need quantum mechanics to explain semiconductors.

MadSci: Why are transistors said to be dependent on quantum mechanics?

I have a feeling that if you have to go far, please do not go beyond logic gates.

Transistors, MOSFETs, IGBTs and all that those stuff depend on semiconductor electronics and all the quantum mechanics stuff but even if you take a take Computer Engineering Major, course work material does not revolve around semiconductor electronics, rather, other than circuit network theory everything else which is computer related revolves around logic gates(of course this is limited to the processor and memory while circuit network theory covers the rest)

If you have to go any far, just don't go beyond logic gates because that will be a waste of time, because for instance you could implement a NAND gate using a diode, a PMOS, NMOS, MOSFET, CMOS but who really cares, you just want to know how shift registers work.

[Nominal Animal]

I would've much rather learned about the QM in solids

Typical solid state physics courses that include semiconductors do use wave functions (QM) to construct and explain the approximations and models. A quick Googling turned up the PDF for the course at MIT (from 2001, I think), that at a quick glance seems to start with exactly this.

The first forty pages or so are relevant to this; the PDF goes much deeper into solid state physics, of course. Maybe you'll find those forty or fifty first pages interesting enough to check out?

what I don't understand is how CPU fetch and convert binary signals from text to electrical signal.

Actually, they do not. Text -- be it human-readable text or binary code -- is stored and accessed via electrical signals. The same applies to input devices: at some point the mechanical or optical signal is converted to electrical pulses. You could say that current CPUs only deal with binary signals.

(There have been some trinary CPUs, but none currently mass produced that I know.)

Current CPUs are really, really complex beasts. Not only do they have multiple levels of cache, and cache coherency protocols to manage them, there is also a memory management unit and virtual memory and whatnot. There is a lot to learn.

I think it will be better if I actually do simple CPU myself

That is not a bad idea; you don't even need to build anything physical, you could do it all in a simulator. (For example, Logic Circuit is free, and someone has already shared library components for simulating 8- and 16-bit processors, themselves targeting the old Z80 processor.)

Personally, I'd recommend getting a cheap, well-documented microcontroller to play with instead.

They are simpler than current CPUs, but have the important external components (like RAM and Flash) built-in -- making them pretty much self-contained, unlike most CPUs --, but a processor is a processor: the logic is still the same.

For example, I'd warmly recommend the $16 Teensy 2.0, which uses the Atmel ATmega32U4 chip (an 8-bit AVR chip) running at 16 MHz -- I'd say roughly comparable to a Z80 or 8086 processor, just faster. You only need the Teensy, an USB to USB Mini B cable, and a computer with an USB port and AVR-GCC to compile your own programs for it. Teensy does use a custom bootloader, not the Atmel DFU, but the loader is available for Linux, Windows, and Mac OS X. Because it has a native USB interface (and not a serial-to-USB converter like most Arduinos), you can program it to be a keyboard or a mouse (or both), for example.

The documentation is the key. The block diagram on page 4 of the ATmega32U4 datasheet shows the complete diagram of the operation of that chip. There is an architectural overview on page 9. Further pages show how each instruction is handled in the pipeline, at which stage the ALU operates, and so on.

All AVRs are well documented, but Arduinos use abstractions (and a pretty large basic libraries) that takes, in my opinion, one much further away from the "bare metal". (On the Teensy, you are writing on bare metal. The only other thing on it is the HalfKay bootloader, and that only runs when the microcontroller is powered up, to see if it should wait for a new firmware to copy to Flash or not.)

This way you can best mix learning and fun. I personally started with microcontrollers with a Teensy++ 2.0, and built an arcade joystick for myself. Having practical hands-on stuff to mix with the theory makes learning much more fun (and easier, too). You could also delve into the other background materials you have, for comparison and better (more thorough) understanding.

Just my recommendation, though; I'm often wrong.

[MartinR]

@Nominal_Animal, thank for your opinion. In fact I have been playing with microcontrollers from couple of months, it's indeed good way to start but I would like to end up with my own microcontroller. I mean I want myself link CPU + MEMORY + all the stuff to gain programmable device with nice functionality But before, I need to really good understand the architecture of CPU.

[Nominal Animal]

I have been playing with microcontrollers from couple of months, it's indeed good way to start but I would like to end up with my own microcontroller.

In that case, an FPGA board would suit you much better. Something like the Mojo v3 sold by Embedded Micro, Sparkfun and Adafruit and probably lots of other places. Embedded Micro even has tutorials for it. The last tutorial is for implementing a custom processor, a MicroBlaze soft processor designed by Xilinx, maker of the Spartan 6 Lx9 FPGA chip used on the Mojo.

You use Verilog and/or VHDL to describe exactly what hardware there should be and how it should work -- VLSI being the general name used to describe that process. You can "compile" Verilog and VHDL for the FPGA chip on the development board, or you can use it as the basis for manufacturing actual chips. The FPGA chip should behave the same way as a silicon chip would, except for some details that depend on which exact FPGA chip is used.

The nice thing about FPGAs is that they're fast, and large/capable enough to run quite complicated designs; a small CPU is certainly not a problem. The Mojo v3 seems to sell for about $75 USD, a reasonable investment if you're serious about CPU/microcontroller design. It's not much for something that allows you to create a hands-on working version of your own processor design..

I haven't gotten that deep myself yet, but I have thought about it. I'd like an FPGA big enough to do some serious double-precision floating point stuff (classical/non-QM molecular dynamics, heavily parallelized, to be specific) and those boards tend to be more expensive. Or I'd need more than one. And lots of time.

[MartinR]

Speaking of microcontrollers programming process, there is another interesting question: how these programmer devices like "USBasp" sends binary to flash memory ? As far as I know it uses 4/5 pins to communicate with microcontroller, so how millions of ones and zeros are save in flash memory ? Where can I read about this process, which is not very "popular" (all books I had chance to read about microcontrollers cover things like C programming for micro.., pins description, ADC converters, etc. No one says about the programming process itself.) Yes I do know, most microcontroller users don't care about what happens under the hood, but I would like to know Can you recommend lecture on it ?

Regards.

[Elysia]

How Flash Memory Works - HowStuffWorks

[MartinR]

I was rather thinking about how the binary is "sent" to appropriate place in flash memory, does programmer device like "USBasp" sent pulses, and how it (flash memory) recognize those signals and place bits in appropriate place ? I didn't find the answer for that yet.

[Elysia]

It sounds like you could use some basic course in electrical engineering or digital design.
Basically, there are typically N electrical wires that is connected to a bus. N being the "width" of the interface, which differs, but for example CPUs today use 32 or 64, while graphics cards can use 128 or 256. This is referred to the number of bits that can be transferred per clock cycle. Every clock cycle a new set of N bits are sent, and so it continues.
A clock is an electrical signal and a clock cycle is its period.
So the data is transferred to the flash memory controller which is connected to a bus that is connected to every memory cell of the flash memory. The controller takes care of putting the data into the flash memory as described by the above link.

[Nominal Animal]

How these programmer devices like "USBasp" sends binary to flash memory ? As far as I know it uses 4/5 pins to communicate with microcontroller

Flash memory is a type of electrically erasable and reprogrammable memory (EEPROM) that is built from logic gates. SD cards and USB memory sticks typically use (some variety of) the NAND kind, which is read and written in blocks, just like hard disks. Current microcontrollers have some flash memory of (some variant of) the NOR kind on the same chip, to contain the program (and constant data); the NOR kind allows individual words to be read or written.

(I find the description of the principles of operation on the Wikipedia page easier to follow than the link Elysia provided. Flash technology is still evolving, and many (most?) microcontrollers actually use a variant of NAND or NOR that allows reading individual words, but writing has to be done in chunks of specific size.)

Atmel AVRs in particular have flash integrated on the chip, and the program (executable) is always read from the flash directly. AVRs have Harvard architecture, where program (flash) and data (sram) are separate -- they are on the same chip, but different instructions are used depending on whether flash or sram is accessed. For example, LPM is used for loading a byte from program memory (flash), SPM for storing to flash (details vary, usually it is more complicated than just issuing the instruction), whereas LD and ST instructions access RAM.

When a microcontroller is turned on (Vcc voltage high enough and stable enough for long enough, typically; details depend on microcontroller), it will start execution at a specific address in the flash memory. This area of the flash memory is called boot sector, boot area, or boot block, and usually has extra hardware protection. On AVRs, for example, Boot Loader Lock Bits control whether writes to the boot area are actually written to the boot area, to make it less likely that a stray SPM bricks the entire device.

The boot area contains a piece of code called, unsurprisingly, a boot loader. The purpose of this program is to choose whether it should just execute the current program code (stored in flash after the boot area), or transfer a new program and write it into the flash instead.

Many Atmel microcontrollers use the DFU bootloader. The Teensies I mentioned use the proprietary Halfkay bootloader, which uses the button on the Teensies to select between programming mode (button pressed at bootup) or normal execution. I like it -- even if it is proprietary/closed -- because it only takes about half a kilobyte of flash. Arduinos use their own bootloader, but I think it is Atmel ISP compatible.

Both the format of the program data, and the interface used for the program, depend entirely on the boot loader used. You can do it with two wires (simple serial, probably using an UART on the microcontroller), three or four (SPI, also available on most microcontrollers in hardware), or more; it really just depends on the bootloader used. In most cases, the actual program data is sent bit-by-bit; for details, read up on serial communication.

Because the integrity of the data is very important, usually the programming software reads back the written data, to make sure the flash contents were written correctly. Sometimes checksums are used. Again, this varies, depending on the boot loader (or the protocol the boot loader implements).

Many Atmel AVRs have ISP, in-system programming interface. It is described in Atmel AVR910: In-System Programming application note. It is basically a simple protocol over a standard SPI bus, and allows rewriting the flash with just three wires. The typical 6-pin connector has MISO (data from microcontroller), Vcc, SCK (clock output), MOSI (data to microcontroller), ^Reset (inverted reset line), and GND lines, as shown in page 2 of the above-mentioned application note.

USBasp and USBtinyISP for example, are just implementations that use the Atmel ISP interface and protocol for programming an AVR. Atmel does have an "official" one, Atmel AVR ISP, but I think the others work just as well -- although the computer driver or software side varies a bit --; I haven't actually used any of these. I like my microcontrollers with native USB interfaces instead.

Much of this stuff evolves too fast to be properly described in print. I recommend scouring hobbyist web pages, especially those striving for open hardware -- including electronics stores that do open hardware. They have the datasheets and if not tutorials, at least blog posts you can look for keywords to search on. While datasheets describe the details, application notes describe usage, and therefore tend to be even more interesting; look for tech that you can find application notes for.

TL;DR:

Don't rely on books, they tend to get stale within a couple of years. Use the web instead. For detailed information, check the datasheets. For microcontrollers, read the Application Notes by the manufacturer. Atmel has lots.

Hope this helps.

[Matticus]

Binary data is sent serially (that is, a pulse train of ones and zeroes). The device in question has a specific protocol defined for interpreting the resulting binary it reads. The data it receives must match this protocol in order for it to be programmed correctly. There are usually other pins associated with programming, as well (i.e. mode control, clock signal, etc).

Clock signals are generally used to control a bit shift register inside the device. So if you wanted to send the binary value 11010010, you would feed the first bit ('1') to a serial input and toggle the clock high-low (or low-high, depending on the expected protocol). Then you would feed the second bit ('1') to the serial input and toggle the clock high-low (or low-high). Then the third bit ('0') and toggle the clock, etc.

Being able to read the serial binary data, and process the resulting data, requires some code to already exist on the device. Most devices have dedicated programming pins with built-in functionality to receive and decode the binary stream, with the necessary code residing in ROM. Many devices offer additional programming methods; i.e. reprogrammability via serial port. This functionality relies on pre-existing code on the chip, whether it be a user-defined "bootloader" that has already been loaded, or standard code placed in ROM by the manufacturer.

Normally, a user will purchase a chip programmer from the manufacturer or from a third party. However, many devices offer application notes describing how to program the chip oneself.

For instance, here is the application note for programming a PIC16F7X from Microchip:

http://ww1.microchip.com/downloads/e...Doc/30324b.pdf

This gives detailed instructions on how signals must be sent, and what order the binary must be received, specifically for that device. Typically, the binary might represent things like a command and/or memory location and/or data.

[megafiddle]

If you want to interface various devices, cpu, memory, gates, etc, the timing specs for the devices will be extremely important. For example, if data is being clocked into a device like a register, the data will need to present and stable for some minimum period of time before the clock pulse is applied. The data will also need to remain stable for some minimum period of time after the clock pulse.

Also, the outputs of gates do not change instantly when the inputs change. There is a propagation delay through the gate. All this has to be taken into account in any design.

You also need to understand the input and output characteristics. An output may have a third state in addition to a logic high or low state (tristate devices). This third state is high impedance, and allows several devices to drive a common bus (the outputs of all but one device are effectively switched out of the circuit as needed). Some transistor theory can help here, eg, for open collector outputs.

There are also specs for the voltage levels that represent a 0 or 1. Usually referred to as High and Low, as 0 and 1 are interpretations. A Low state will have a maximum voltage level to guarantee it meets the requirement for a logic Low, for example.

Devices of the same family are designed to interface directly, and some of the things are taken care of in that respect. But you still need to be aware of them. If the circuit doesn't work, you may very well need a good fast oscilloscope to find the problem. On the other hand it is possible to design a working circuit with enough attention to detail.

These requirements and specs can be found in the data sheets for the devices.

-

[MartinR]

Elysia, Nominal Animal and others thank you all for extensive explanation

For detailed information, check the datasheets

While this is great idea for most of the parts, there is a little problem with datasheets for some embedded stuff. As all of as I have few *old* cell phones (2008 is history in this market), So, I thought, it may be nice to play with their displays, batteries and so on and give them new life...but I can't find datasheets or any other docs etc on this subject. Where to look for information ? Looking forward for your advices
Thanks.

[Nominal Animal]

there is a little problem with datasheets for some embedded stuff.

Which is exactly why I expressly recommend buying your hardware from vendors and manufacturers that do have datasheets or guides online.

It is actually quite a big problem with some interesting hardware; and one so hard to solve, that I personally will not buy gadget parts anymore, unless I first have the datasheets and/or specs and/or a library at hand.

I have few *old* cell phones (2008 is history in this market)

Bah! My preferred cellphone is a Samsung SGH-X460 from 2005. My old phone is a Nokia 8110i Matrix banana from 1997. (It still works, too, but it only supports a GSM 900 network.)

Anyway.

For example, I have about a dozen Nokia 3510i displays I use with my microcontrollers.

If you scour the hacker and maker sites, you'll find notes and libraries you can use with the microcontroller (for example, here and here).

In the 3510i display case, the LCDInfo forum has a post that not only mentions the hardware requirements (3.3 volt I/O, in particular), but also the controller chip: D15G14 series. If you do e.g. a Google verbatim search on it, you get lots of interesting and relevant results.

I also have two SSD1963 -based 4.3" LCDs with resistive touch overlays. Similar ones are available on eBay for about 12€ to 15€ (in my case, total cost would be about 25€ per module, including shipping and VAT) -- note that only the modules with a circuit board include the display controller! It's very, very hard to interface to a display without a controller; you don't want that. The SSD1963 controller is the chip that controls the display and contains the frame buffer memory; it's a nice controller, and people have interfaced them with various microcontrollers (including AVRs). The touch module uses SPI bus, and many display modules with a touch overlay include an SD card slot on the circuit board (as SD cards are interfaced via SPI, too).

(In my LCD modules, the eBay vendor had just painted over the URL of the original board manufacturer with thick ink the same color as the board; with a bit of hobby knife scraping, I had an URL to an old page that ultimately led to a ZIP file with example code for STM32 microcontrollers. While I use ARM Cortex-M4's with these, it was useful: I found the original timing values in the sources, so didn't have to start guessing, just fine-tuning. The actual display itself is made by Hannstar, but to find the exact model (to go look for the timings Hannstar recommends for this display), I'd have to tear one of them apart. So, saved quite a bit of hassle, finding that ZIP file.)

In general, my recommendation is to do a lot of research on the net, based on both the phone model (or name and model of whatever gadget you're stripping apart), but more importantly, on any strings you can see printed or stenciled on the parts. If you have a local hacklab, go visit, with your parts/gadgets in tow. Join some hacker/maker forums, and search and ask there.

It is sometimes frustrating, and sometimes you just have to decide whether the part is worth the effort, given documented low-cost alternatives available.