Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
One difference is microcontrollers are usually designed to perform a small set of specific functions whereas microprocessors are for huge, general functions.
Anything else??
A microcontroller is a microprocessor (a.k.a. CPU core or cores) with additional peripherals on-chip. The terms come from the 1970s, where a microprocessor (e.g. Motorola 6800 or Intel 8086) would have an address bus, a data bus, and control lines, and a microcontroller (e.g. Motorola 6801 or Intel 8051) would have peripheral I/O pins (serial ports, parallel I/O, timer I/O, etc.) but no external memory bus (you were stuck with what was on the chip).
Additionally, microprocessors executed their programs from external ROM and microcontrollers would use internal masked (as in "programmed at the factory by changing the IC photo mask") ROM. The only practical erasable ROMs were UV-erased EPROMS, electrically erasable PROMS (EEPROMS) were expensive, slow, and not very dense, and "flash" meant the bits of plastic sticking out of the mold seam lines on the chip.
Honestly, the line between them is fading away. Modern microcontrollers such as the Motorola 6812 series have an external memory bus and peripheral I/O pins at the same time, and can be used as either a microprocessor or microcontroller.
From
http://wiki.answers.com/Q/What_is_the_difference_between_a_microprocessor_and_a_microcontroller
A microcontroller is a specialized form of microprocessor that is designed to be self-sufficient and cost-effective, where a microprocessor is typically designed to be general purpose (the kind used in a PC). Microcontrollers are frequently found in automobiles, office machines, toys, and appliances.
The microcontroller is the integration of a number of useful functions into a single IC package. These functions are:
The ability to execute a stored set of instructions to carry out user defined tasks.
The ability to be able to access external memory chips to both read and write data from and to the memory.
Basically, a microcontroller is a device which integrates a number of the components of a microprocessor system onto a single microchip.
So a microcontroller combines onto the same microchip :
The CPU core (microprocessor)
Memory (both ROM and RAM)
Some parallel digital I/O
Also, a microcontroller is part of an embedded system, which is essentially the whole circuit board. Look up "embedded system" on Wikipedia.
The difference is that microcontroller incorporates features of microprocessor(CPU,ALU,Registers)along with the presence of added features like presence of RAM,ROM,I\O ports,counter etc.Here microcontroller control the operation of machine using fixed programme stored in Rom that doesn't change with lifetime.
The other difference is that the micro controllers usually has to handle real time tasks while on the contrary the microprocessors in a computer system may not handle a real time task at all times.
A microcontroller is much more of a complete computer system. A microprocessor is just that -- a processor. A microcontroller will normally include memory (often both RAM and some sort of ROM) as well as peripherals such as serial ports and timers, and (in some case) more specialized hardware. For example, a microcontroller intended for motor control will typically include some PWM ports, while one intended for communication use might include encryption hardware.
In short:
Microprocessor= CPU
Microcontroller= CPU+ peripherals+ memory
This link was useful too.
Micro-controller is a general purpose processor having 40pins. It is used as CPU in computer. It uses memory devices like RAM or ROM externally.
Micro-controller is also a processor designed with memory internally. It may be a computer.
General use
Microprocessor - generally use in computers as a general purpose programmable device.
microcontroller- generally use in Robotic system or a Traffic signal control system.
Ref -Difference between Microprocessor and Microcontroller
In the short word, microprocessor is the one part of microcontroller.
Related
I am currently learning about microcontrollers and processors, and I have a couple questions about some distinctions between the two. As I understand, the MCU contains a processor that implements a processor architecture. For example, I am using a SAML22 Microcontroller that has a ARM Cortex M0 for its processor. So it would have the following:
Architecture - ARM
Processor - ARM Cortex M0
MCU - SAML22
Are the registers that I gather from the SAML22 data sheet related to the ARM Cortex M0? If so, how?
No, the microcontroller datasheet describes peripherals which are not part of the ARM core.
The SAML22 has a Cortex-M0+ core, which is described in ARM documents "Technical Reference Manual" (TRM, DDI0484) and the less detailed "Device Generic User Guide" (DGUG, DUI0662).
You are trying to overcomplicate this. an mcu has a processor. A processor has a processor. there have been processors that you can find on both an MCU and an SOC that is linux capable (not just rtos or uclinux). Its like having a few horsepower motor on your lawnmower and also having the same or similar on your golf cart. Or like having a school made of bricks or a house made of the same style/brand of bricks. Dont get hung up on that. Particularly with the rest of your question which has nothing to do with the processor used in the chip at all.
Atmel wants to make an MCU, so the either create, reuse or buy a processor, they have at least one if not more processors that are their IP but they choose to buy someone elses IP. Now they want to wrap some logic around it they can use some of their own ip or buy some. Each major block is a new discussion. Do they make their own uart from scratch, do they take a uart they created years ago and re-use that, or do they buy a uart. Do they make an ADC from scratch, do they take an ADC they made years ago and use that, do they purchase an ADC design from someone and use that. Repeat for every major or minor block in the design. Just like Honda making a car, which parts are they going to make themselves and which parts are they going to buy, and does that have any relevance to a design they made years ago, or a truck sized vehicle vs a compact car, they both have four wheels, an engine and some seats, in some cases may share some components and others completely incompatible components. but its the same story, do we make a seat, use one we already have, buy one. do we make a rear view mirror, use one we already have from a prior design, or buy them from someone else. the rear view mirror decision likely has nothing to do with the seat decision.
Registers its just a term a thing you write/store some information in. A uart has registers to make it work. A processor usually has registers to make it work. An ADC usually has registers to make it work. Consider each of these blocks as separable.
A processor core is a logic blob that is programmable in the sense that it has a set of rules and its primary interface is a memory bus where it is the master, it expects to find when fetched instructions per its design that tell it what to do, up to the chip vendor to wire that up to something that will feed it instructions. It may have some interrupt lines and a few other things but its primary interface is that memory bus. The "registers" inside are part of the design accessed by the processor internals and not generally memory mapped.
A uart is a logic blob that that is programmable, it has some sort of a memory/interface bus where it is typically a slave. It also has some other signals that go off chip, RX, TX, RTS, CTS, DTR...The registers inside the uart are addressable through the interface bus and are used to make the uart operate. It is up to the chip vendor to connect this bus in a way that it fits into the address space of a bus master that directly or indirectly can write/read the registers in the uart to make it operate. It is programmable in the sense that programming the registers per its spec makes it operate.
An ADC is a logic blob that is sometimes found to be programmable, sometimes not. The converter itself isnt usually. But when used in a chip that does more than just ADConversions there will be an additional logic blob wrapped around the ADC to make it programmable and that logic blob will have some sort of an interface bus where it is a slave. It is up to the chip vendor to connect this bus to a bus master that in some way is capable of programming the ADC to do something.
This isnt limited to ARM based microcontrollers. You look inside an intel x86 processor there is third party IP in there not invented nor created by intel, a lot of it may be but not all. Same goes for pretty much everyone else.
Processor based chips are just cars with seats and an engine and wheels that were per that design sourced from somewhere and then interfaced to each other using more IP from someone be it in house or not.
For any of these chips each IP blob has documentation uart documentation, adc documentation, processor core documentation. Sometimes the license agreement prevents the chip vendor from publishing the documentation and you have to get a driver from them in some sort of board support package or SDK in some form, countless examples of this with chip vendors you have heard of from atmel to intel to zilog. Likewise there are license agreements or common practices that guide what parts the chip vendor is going to document and how and what parts not. So generally but not always when you have specifically an ARM or MIPS core as part of a design. The processor documentation as you should generally do always, is from the processor vendor so ARM, MIPS, etc. The uart, the ADC, and some others be they in house or purchased IP are generally in the chip vendors documentation. The chip vendor ideally created the address space within the rules of the various ip, so the chip vendor often documents where in the processors address space each logic blob lives, then you go to the documentation for that logic blob to see what the individual control interfaces do, registers or memory mapped memory. Not always true though esp with uarts, you sometimes find this is a 16550 compatible and you have to go find a 16550 document from someone else and connect the dots on your own. The raspberry pi includes for example other peripherals where they basically say this is just an arm purchased blob go to arm for this, or there is a blob here and we wont show you how it works (but we publish the linux driver for it and if eager you can reverse engineer from that).
With an Atmel now Microchip ARM based product you (generally) go to arm to get info on the processor core, its general purpose registers as well as the very few internal to the core peripherals like the systick timer if present. The uart, the gpio, the address space, spi, i2c, etc are going to be in one or more Atmel documents for that part, they cover the register specs for those peripherals.
As far as how many documents it takes from the chip vendor that is very much chip vendor and over time family or product line specific. Some chip vendors as with some customers like the board design specific stuff in one document usually called a datasheet. Pinouts, electrical stuff, etc. And the other documents cover the uart register specs and such. Some designs are such that they reuse the same core components. if you have a uart then here is the register spec all of our uarts are the same. so there will be a manual for all of the chips peripherals and maybe the processor or maybe the processor core itself is in a separate manual. In some cases with that design solution, the peripherals if present are always at the same address or they are not. The one I am thinking of you find the board design stuff in the datasheet along with the address map, but the rest of the information for programmers is in the family reference manual, so you need at least those two documents.
And there are of course vendors that either make bad documents with holes as sad habit, or some that intentionally do not provide documentation without an NDA, for fear that a competitor will make a clone perhaps, or just a habit for that company that goes way back. Sometimes those closed book companies do very well sometimes that causes them pain. Broadcom and allwinner seem to do okay, allwinner docs tend to get left about by chip vendors and I guess they dont get punished, but other companies you will get called out for that possibly with a financial or other punishment. Its all in the legal agreement.
There are a few perpherals where there is only one or two designs and everyone just buys it, and despite being undocumented looking at linux/unix drivers can see that everyone uses the same IP.
Way more than you asked for but could tell from your question you were off on the wrong path.
Generally the ARM stuff is not in the chip vendor stuff, so no you wouldnt find it there. Sometimes (rare) the chip vendor will re-publish an arm document in whole or in part. Better to get it from arm directly. In the case of a cortex-m the arm peripherals on core are at fixed/well known addresses. For the cortex-a, and older arm11, arm10, arm9...The chip vendor straps a peripheral base address in the address space they have designed for that product and the internal arm peripherals if any are based off of that. so you can find two products likely from different vendors with the same core but the memory mapped peripherals inside are at different addresses for this reason. (in the technical reference manuals for the various arm cores).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
What can an Arduino do that a Raspberry Pi can't?
Arduino is a microprocessor, not a computer. It means that Arduino has inputs and outputs that you can connect to different electronic components such as motors, lights, sensors, etc.
Those inputs and outputs are only pins that you can send or receive a certain amount current.
Arduino has a pretty limited memory so you can only store a simple program on it, not a OS. It is mostly used in automation. For example you want to automate a garden so you have sensors to detect the amount of water in the ground and then use this information to enable a motor that will turn the water on. There is a complete API to simplify the coding between the programmer and the device.
For example, you have a function that will control the speed of the motor in rpm so you only have to give the speed as a parameter of that function.
Raspberry pi is a complete computer, so you can plug a screen, mouse, keyboard to it. There is some OS available for it. It is not just only pins as inputs or outputs, but HDMI input or usb port.
So Raspberry pi and Arduino are completely different and have both a different field of interest.
You will not order a Raspberry Pi to automate the temperature of your coffee as you will not use a Arduino to make a OS.
I hope this will help making the difference between the two.
Good luck!
I would say that the functions and capabilities of the Pi Zero and the Arduino boards have started to overlap, as have the prices (although where I live the Pi Zeros are still somewhat more expensive that Arduinos). Perhaps we will see the applications start to overlap, too.
Conventionally, the Pi has been used in situations that demanded, or at least benefited from, running a full operating system, while the Arduino was more for running a single, custom program. I don't think there's been much interest in running code on a Pi that does not run under an OS, but it seems to be possible, up to a point. I'm not whether all the hardware is accessible this way, because some of it requires proprietary drivers, IIRC.
Because the Pi conventionally runs a full Linux kernel and utilities, it's been slower to start up in embedded applications, whereas the Arduinos essentially boot right into application code. The Pis have slightly greater power consumption (quite a bit greater, with the full-size models), and are a bit larger.
I suspect that, if you were planning commercial production, basing something around Arduino-type hardware is more likely to be productive that using a Pi. I have come across Pis being used for commercial products, but not (I think) for mass-market applications. The hardware and programming style of an Arduino is much closer to the kind of thing that you can miniaturize into a consumer product, even though the Arduino itself may be comparatively expensive.
In short, I would expect that for casual, home, and research use, it's increasingly easy to justify using a Pi Zero over any kind of microcontroller; but if I had to prototype a mass-market item, Arduino would still be closer to the final hardware spec.
I have a project in which I need to have the lowest latency possible (in the 1-100 microseconds range at best) for a communication between a computer (Windows + Linux + MacOSX) and a microcontroller (arduino or stm32 or anything).
I stress that not only it has to be fast, but with low latency (for example a fast communication to the moon will have a low latency).
For the moment the methods I have tried are serial over USB or HID packets over USB. I get results around a little less than a millisecond. My measurement method is a round trip communication, then divide by two. This is OK, but I would be much more happy to have something faster.
EDIT:
The question seems to be quite hard to answer. The best workaround I found is to synchronize clocks of the computer and microcontroler. Synchronization requires communication indeed. With the process below, dt is half a round trip, and sync is the difference between the clocks.
t = time()
write(ACK);
read(remotet)
dt = (time() - t) / 2
sync = time() - remotet - dt
Note that the imprecision of this synchronization is at most dt. The importance of the fastest communication channel stands, but I have an estimation of the precision.
Also note technicalities related to the difference of timestamp on different systems (us/ms based on epoch on Linux, ms/us since the MCU booted on Arduino).
Pay attention to the clock shift on Arduino. It is safer to synchronize often (every measure in my case).
USB Raw HID with hacked 8KHz poll rate (125us poll interval) combined with Teensy 3.2 (or above). Mouse overclockers have achieved 8KHz poll rate with low USB jitter, and Teensy 3.2 (Arduino clone) is able to do 8KHz poll rate with a slightly modified USB FTDI driver on the PC side.
Barring this, and you need even better, you're now looking at PCI-Express parallel ports, to do lower-latency signalling via digital pins directly to pins on the parallel port. They must be true parallel ports, and not through a USB layer. DOS apps on gigahertz-level PCs were tested to get sub-1us ability (1.4Ghz Pentium IV) with parallel port pin signalling, but if you write a virtual device driver, you can probably get sub-100us within Windows.
Use raised priority & critical sections out of the wazoo, preferably a non-garbage-collected language, minimum background apps, and essentially consume 100% of a CPU core on your critical loop, and you can definitely reliably achieve <100us. Not 100% of the time, but certainly in the territory of five-nines (and probably even far better than that). If you can tolerate such aberrations.
To answer the question, there are two low latency methods:
Serial or parallel port. It is possible to get latency down to the millisecond scale, although your performance may vary depending on manufacturer. One good brand is Brainboxes, although their cards can cost over $100!
Write your own driver. It should be possible to achieve latencies on the order of a few hundred micro seconds, although obviously the kernel can interrupt your process mid-way if it needs to serve something with a higher priority. This how a lot of scientific equipment actually works. (and a lot of the people telling you that a PC can't be made to work on short deadlines are wrong).
For info, I just ran some tests on a Windows 10 PC fitted with two dedicated PCIe parallel port cards.
Sending TTL (square wave) pulses out using Python code (actually using Psychopy Builder and Psychopy coder) the 2 channel osciloscope showed very consistant offsets between the two pulses of 4us to 8us.
This was when the python code was run at 'above normal' priority.
When run at normal priority it was mostly the same apart from a very occassional 30us gap, presumably when task switching took place)
In short, PCs aren't set up to handle that short of deadline. Even using a bare metal RTOS on an Intel Core series processor you end up with interrupt latency (how fast the processor can respond to interrupts) in the 2-3 µS range. (see http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/industrial-solutions-real-time-performance-white-paper.pdf)
That's ignoring any sort of communication link like USB or ethernet (or other) that requires packetizing data, handshaking, buffering to avoid data loss, etc.
USB stacks are going to have latency, regardless of how fast the link is, because of buffering to avoid data loss. Same with ethernet. Really, any modern stack driver on a full blown OS isn't going to be capable of low latency because of what else is going on in the system and the need for robustness in the protocols.
If you have deadlines that are in the single digit of microseconds (or even in the millisecond range), you really need to do your real time processing on a microcontroller and have the slower control loop/visualization be handled by the host.
You have no guarantees about latency to userland without real time operating system. You're at the mercy of the kernel and it's slice time and preemption rules. Which could be higher than your maximum 100us.
In order for a workstation to respond to a hardware event you have to use interrupts and a device driver.
Your options are limited to interfaces that offer an IRQ:
Hardware serial/parallel port.
PCI
Some interface bridge on PCI.
Or. If you're into abusing IO, the soundcard.
USB is not one of them, it has a 1kHz polling rate.
Maybe Thunderbolt does, but I'm not sure about that.
Ethernet
Look for a board that has a gigabit ethernet port directly connected to the microcontroller, and connect it to the PC directly with a crossover cable.
I am posting this question after not getting any sort of help across the web and reading many articles and tutorials. I ended up asking questions with hope of getting guided.
DESPERATE FOR HELP.
What i want:
1) I want to build a R/C tank.
2) Basically its not controlled by a remote control but i want control by a laptop.(i could write a c++ or c# program).
What i know:
1) I know how to develop a development board. (i want to develop my own, not use arduino)
2) I know c++ and assembly very well.
3) I know about AVR's ALU, Memories(all 3), Stack, Interrupts, IO Operations well.
4) I know theory about how SPI, RS232, UART works.
PROBLEMS: (I have many questions, but most important are)
1) B/c i have made my own board. How can i transfer my program(hex file) to my board(i seek practical and physical implementation, not theory please)(i know about a 6-pin ISP but not clear about practical implementation)
2) After it, how can i make wireless communication b/w my AVR and laptop.(hardware device?)(SPI, RS232, UART?)
MAIN CONFUSION:
1) I cannot help myself differentiating or relating SPI, RS232 and UART.
I know these are used for serial communication between devices but how?(which is used when and why and how)(appropriate hardware for transmitting device and receiving device)
THING TO KNOW:
1) I haven't started making my board and programming it because i think i should learn everything first and then do it in a one go. OR should i start practical work and things get easier automatically??
2) I learnt a tutorial series on Serial Communication from http://maxembedded.com/2013/09/serial-communication-introduction/ the starting 5 topics leaving the last one(I2C). Am i missing something there?
I hope everything is clear, and waiting for a good-men's words.
Note: I am already very misguided and lost, so i want experienced and expert's guidance. Many Many Many Many Thanks in Advance.
MY BOARD LOOKS LIKE:
http://www.robotplatform.com/howto/dev_board/schematic_l/38.jpg
1) To upload your code into AVR chip, you can use ISP interface. That requires you to connect at least 5 pins: SCK, MISO, MOSI, RESET, GND, and optionally VCC (it used to control or supply voltage, but not mandatory, if your board has it's own power supply). All you need is just to wire 6- or 10-pin ISP connector to that pins of your CPU.
To begin programming process you need to obtain some programmer device (USBasp, AVRISPmk2, STK500/600 etc.), Also, you can use Arduino board itself as ISP-programmer for external AVR chip, like this: http://www.instructables.com/id/Programming-an-ATTiny13A-using-Arduino-servo-int/
Each of programmer model requires it's compatible software (such as PonyProg), for example STK500 and AVRISP programmes could be used directly from Atmel Studio.
Also, you can connect ISP to parallel (LPT) port of the PC, and upload firmware using specialized software, such as uniprof
Another way to upload software - it is to make your own bootloader - a tiny program that will update firmware, using any available interface.
2) USART, SPI, I2C - it is different interfaces to communicate with peripherals. Note that RS232 - it is electrical interface built over USART. I.e. you need external IC which will convert USART logical level signals to RS232 electrical levels.
each of that interfaces have it's own profs and cons. And usually selection of which interface to use depends on which interface is supported by peripherals.
SPI - it is interface for high-speed communication. One master many slaves. It requires a lot of wires: MISO (data from master to slave), MOSI (data from slave to master), SCK (clock) - those three could be common for all slaves. Also it requires a SS (slave select) - one SS wire for each slave to determine which slave is in communication at the moment, also it sets the edges of the data packet.
USART - it is common interface, to communicate two chips. Each byte transmitted with foregoing start bit, optional parity and following stop bit. I.e. transfer has a quarter overhead, but byte can be transmitted in any moment.
Works in synchronous and asynchronous modes. Asynchronous mode requires only 2 wires (RX and TX, not counting GND that also required). This mode requires that receiver and transmitter to be sychronized, in most cases that required to crystal oscillator to be installed.
Synchronous mode works in the same format as asynchronous, but have additional XCK (clock) wire, that determines in which moments bits are possible to be transmitted. This allows to increase transmission speed and not requires time precision from receiver. Synchronous mode is rare used.
I2C - it's a bus with only two wires, allows many masters and many slaves. Utilizes pull-up resistors to achieve wired AND, have it's own algorithm to detect collisions, more complicated to be programmed, transmission speed is limited.
Often used by peripherals, such as accelerometers, RTCs etc.
AVR chips have no it's own support for wireless communication, therefore, to do that you need to use some external wireless chip, for example bluetooth, or WiFi, there are a lot of such modules (for example ESP8266). AVR chip communicate with them using USART, sending and receiving simple commands.
I just got an old pentium 4 and I thought, that it would be nice to calculate some heavy maths with it.
So I have a arduino duemilanove and I know, that how To send data in to the processor, but I dont know how I specify to processor that what mathematical things it should do (like multiplication, sqrt, sin and so on), and how do I specify that where do I get those answers out of the processor.
You make an application that you download into Arduino duemilanove and you make an application for your Pentium 4 computer. These applications need to exchange data via some communication channel like existing USB/FTDI/RS232. You need to learn how to send/receive data to/from it in both Arduino programming language and your favorite PC programming language. Then you need to make a protocol that both part will understand. Arduino will send a message that will include all inputs needed for computation, and PC will reply with a computation result. You will also need to learn how to download application to Arduino, and many other things on this way, but I strongly advice you to start with blinking leds. That's a hello world application for microcontrollers and every newbie should start with this little step first.
I think, that I gonna build a kernel to drive the basic functions of the processor, and I use agtl converted to ttl for arduino/cpu communication.