Processor Architecture Registers vs. MCU Registers - microcontroller

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

Related

How do smart phones use AT commands and data connection(s)? gsm mux? multiple uarts?

I am involved in a project where we have some kind of IoT device. An nxp processor with an LTE modem on a PCB. The software running on it connects to the modem over a single uart interface. It will initialize the modem through AT commands, and finally made a data call to the provider (PPP).
Then, it uses lwIP (light weight IP) to open some mqtt subscriptions, and allow user code to make http get/post requests to our servers.
Every 15 minutes we want to retrieve signal strength from the modem and report this back to the server. What I do now, is put the modem back in command mode, retrieve the signal strength info, go back to data mode, and resume normal operation.
The round trip from data mode, to commando mode, and back to data mode takes several seconds (4-5 ish). This is annoying, because during that time we are not receptive for commands.
I've read about gsm mux 07.10. By following some defined protocol it allows to create virtual serial ports, over one physical uart. That sounds nice, although I realize this will go at the cost of performance (bytes will be added to each frame we send to either command mode / data mode).
The gsm mux 07.10 spec dates from 1999. I am far from an expert in mobile solutions. I was wondering: is muxing still the way to go? How does a typical smart phone deals with this for example? Do they include modems with more than one uart to have parallel access to AT commands and a live internet connection? Or do they in fact still rely on gsm mux?
If somebody would be so kind to give some insights. Also on potential C libraries that are available that implement gsm mux 07.10? It seems that TinyGSM implements it (although I can't seem to find where), and I also can find the linux kernel driver that implements gsm mux 07.10. But that driver is written on top the tty interfaces in linux, so that would mean I would have to reverse engineer the kernel driver and strip out the tty stuff and replace it with my own uart implementation.
First of all, the spec numbering is the old GSM specification numbering, so those old specs will never be updated, the new specifications with new numbering scheme will. I do not remember when the switch was made, but I do remember someone at work giving a presentation on 07.10 probably around 1998/1999, so probably a few years after that or around that time (and definitely before 2009).
The newer spec numbering scheme uses three digits for the first part.
So for instance the old AT command spec 07.07 is now 27.007, and the current 07.10 multiplex specification is 27.010.
The following is what I remember of 07.10.
The motivations for developing 07.10 was to exactly support the kind of scenario that you describe. Remember back in the mid 90's, if mobile phones had a serial interface then that was RS-232 though each manufacturer's proprietary connector at the bottom of the phone. One single serial interface.
However, in order to use 07.10 mux in serial communication you needed to install some specific serial drivers in Windows with support for 07.10 (and I think maybe there was some reliability issue with them?), and for that reason 07.10 never took of and became anything more than an rarely used solution.
Also by the end of the 90's additional serial interfaces like Bluetooth and IrDA became available on many phones, and later USB as well, which both added additional physical interfaces as well as natively multiplexing within each protocol.
So the need for multiplexing over physical RS-232 became less of an issue, and whatever little popularity 07.10 ever had dwindled down to virtual nothing.
Fast forward a couple of decades and suddenly someone asks about it on stackoverflow. Good on you :) As far as I can tell I cannot see any fundamental problems with using it for the purpose you present.
Modern smart phones that support AT commands will most likely have a code base for the AT command parsing with roots in the 90's, which most likely include the AT+CMUX command. Of course manufacturers today have zero explicit wish for supporting it, but when it is already present it will just come along with the collection of all other legacy AT commands that they support.
So if the modem supports AT+CMUX you should be good to go. I have no experience or recommendation with regards to client protocol libraries.

What is the purpose of application processor in a wifi module?

I am just learning about embedded systems and checking about wifi modules. I see in the datasheet they mention about a core processor that is integrated with rf SoC. I also see another processor on the MCU called application processor. I am confused about its purpose. What is it used for? Can someone please clarify? For reference, I was reading about the ATSAMW25 module.
Typically, devices that include wireless technologies (whether its Bluetooth/BLE, WiFi, LoRa, etc) include both the hardware required to manage the wireless connectivity and then separate hardware for running the higher-level application of the system. Frequently, managing the wireless protocol is intensive enough that it is best done with its own small processor running its own firmware to deal with connectivity and sending data over the link and might include a fair amount of proprietary firmware from the vendor (ie, Microchip in your example). To enable programmers to write their own code for the system, these protocol processors are paired with application processors, ones for whom the development tools and documentation are more openly available to developers for implementing whatever they want to do with the module. By separating the two operations (wireless/protocol and application), the code developers implement has less chance of causing fundamental problems for the wireless connectivity (like, application code hanging causes entire WiFi networks to fail) and the proprietary aspects of the system can be better protected (or another way, more documentation can be provided to developers without signing an NDA as the application processor is more "open" while the details of the wireless implementation are usually not).
In the case of the module youre looking at, the wireless hardware is all inside the ATWINC1500 and is accessed via SPI and some other GPIO by the SAMD21G (the application processor). All the code you write for the module end up running on the SAMD21G with some library/driver support to implement the wireless functions (which under the hood, are implemented by talking to the ATWINC1500). The ATWINC1500 simply runs the code the vendor (Microchip) wrote to actually do all the wireless protocol work and provides an interface for another processor (in this module, the SAMD21G) to control it.

Whether ibeacon and sensortag are same?

I know both are bluetooth smart devices. I need to know whether both can be used for the same applications. If not what do they have in common and what is different about them?
A sensortag can be configured to be an iBeacon, but it is designed to be a more generic Bluetooth LE device that can be put to many other uses as well, providing many other Bluetooth services.
An iBeacon is a very specific type of Bluetooth LE device, and many types of iBeacons can only perform that one function.
Because a sensortag is so generic, it is not optimized to be an iBeacon. Its battery, for example, will not last a super long time when acting as an iBeacon.
A TI "Sensortag" is basically just an eval board for the CC2540 / CC2541 BLE chips.
Most hardware "iBeacon" implementations use either that chip, or the competing NRF51822, on a more specialized custom board.
In either case, the transmission of "iBeacon"-formatted BLE advertising packets is controlled by the custom firmware loaded into the device.
The duty cycle, which is the major determination of power consumption, is also determined by the firmware. The Sensortag does have some other onboard peripherals, but if the design is sane it should be possible to get those into a negligible powered-down state.
Answering #TimTisdall comment (below), the following link is a 3rd party, non-official iBeacon-enabled firmware update for TI's 2541DK SensorTag hardware:
hex firmware files, demonstrating iBeacon on the cc254x
For more info regarding SensorTag, see:
http://www.ti.com/ww/en/wireless_connectivity/sensortag
&
http://www.ti.com/tool/CC2541DK-SENSOR
This question was a bit ahead of the time and here are some updates: The SensorTag now officially supports iBeacon technology. Information on how to configure it to act as an iBeacon is described in the wiki.
As davidgyoung already pointed out: it wasn't build to solely work as an iBeacon, so it may come with reduced battery life. On the other hand, it provides more functionality, which makes it a valuable tool for development at a good price tag.
As noted before the SensorTag has many other sensors on board. Using a "generic" iBeacon firmware on the SensorTag results in a high current consumption. The unused sensors need to be put into sleep mode (I believe it was the Gyro implementation, which eats a lot of power when not configured correctly in sleep mode).

How to program an XBee ZigBee module?

I have a project which the information from the microcontroller (drop rate changes of dextrose like sending notification "nearly empty" or "Sudden change of drop rate. Drop rate of 15 automatically return to 14") would display in an application in a computer. I am thinking of using ZigBee and it would be responsible for transferring the information but I am new with the technology.
Does anyone could help me how to program the ZigBee module? I have seen some articles saying that it could be programmed in eclipse CDT. I am bit confused how to get start.
Any help would be appreciated. Thanks!
Use USB Explorer device (or similar) to enter a serial terminal session on the receiving XBee.
Type ATMY to get the receiving XBee's address. Write it down.
Put the sender in the USB Explorer and type ATDL plus the receiver's address, like "ATDL798A728"
Type ATWR to save this setting.
Attach sender XBee's UART (TX and RX pins) to microcontroller.
Plug receiving XBee into USB Explorer attached to computer.
Run Processing sketch or similar to read from the serial port.
The two XBees will run by default in 'transparent mode,' which pipes data coming into one UART out of the other UART, exactly like a wire. So when your microcontroller writes data into the sender XBee, it will come out of the receiving XBee and be read (and displayed or whatever you need) by your software.
It really depends on how much configuration your installation can handle. Is this a one off installation, or a "system" of products you want to make that have to be able to work together in whatever configuration they're bought?
As already explained, xbee modules that have the whole radio + stack already setup and working for serial data are simple to use for the trivial case of you sending out a few pre-paired setups form the lab, or even site installation by an expert.
If your embedded devices have to find each other automatically, then you'd need a way to get the embedded microcontroller to get the modules discover each other, make a connection, and then have the application code in the embedded microcontrollers talk to each other and identify what they need to do with each other.
In this case, you probably would be better off with the (upfront much more complex and likely expensive) design where the zigbee stack is inside the embedded controller, so your application code can use it properly to control connectivity.
The TI zigbee pro evaluation kit is very comprehensive, and seems great to me so far. It sounds like you're at the point where you need to spend some money and get some experience with real modules, just to get a feel for the technology. Though be warned, you may need IAR embedded workbench to work with these long term, and that's pretty expensive software!
Alternatively, Atmel have a pretty interesting looking zigbee implementation with their "bitcloud" software platform (free zigbee pro stack!! woo! and they have a free ARM toolchain!) but I've found the getting started info around the bitcloud stuff is really lacking, and while I can get the code setup and compiling, I'm not confident to buy enough of their evaluation gear for a zigbee pro mesh network to test it in real life yet.
PS: if you're getting started with short range wireless, i can't recommend this book highly enough. http://www.amazon.com/Essentials-Short-Range-Wireless-Cambridge-Series/dp/0521760690/ref=sr_1_2?ie=UTF8&qid=1336091059&sr=8-2
It contains very good introduction to the different technologies available, and the strengths and weaknesses of all of them (and wireless in general) Plus it will leave you in a good position to start understanding the features you really need for the system you're designing.
some of the zigbee/xbee modules simply behave as wireless serial, no programming required just turn them on. Others require programming. It depends on what your needs really are. the ones that behave like wireless serial have an AT command set if I remember right so you can adjust some things, like for example if you want more than two (more than one wireless point to point connection) you can specify which two talk to each other...

What is the difference between a Relay Controller and a Microcontroller?

What is the difference between a Relay Controller and a Microcontroller?
I'm looking into Arduino boards and am just getting into electronics, so I wanted to know the difference.
I know this is not a programming question, but I am developing in PHP and would like to know what the difference is before I start to code to make sure I'm going down the right path.
Those two devices are very different. Depending on exactly what you're trying to do, you may be able to use either, however. You'll have to tell more about your goal.
If you're switching high-current or high-voltage loads on and off, you'll need some sort of relay (or perhaps a large FET). If your current and voltage requirements are sufficiently low (5V, 40ma), you may be able to drive your load directly with the Arduino's output pins.
The Arduino is a microcontroller. That means it's an entire computer, just simplified. It has RAM, registers, an ALU, etc. Microcontrollers are generally specialized such that instead of interfacing to peripherals using some kind of bus like in a desktop computer processor, they have I/O capabilities built in, often simply in the form of outputs that can be set high (the input voltage, usually 5V) or low (0V) programmatically. The Arduino probably uses its own programming langauge, although there may be more than one language available for it (I've never used one). I doubt PHP is one of those langauges.
The relay controller is exactly what the name implies -- a simple circuit that controls some relays. Relays are electrically actuated switches. There's no intelligence in the relay controller. It can't be programmed; it must be controlled externally via USB. If you're attempting to interface with it from PHP on a desktop/server computer, this is probably your best choice. You're right that it's expensive. You could probably build your own for a fraction of the cost, especially if you're willing to use the parallel port on your computer (googling for how should give simple instructions). It's worth noting that that relay controller, and presumably most others, likely contain some kind of microcontroller with the I/O pins connected to circuitry that increases the current and/or voltage to the point where it can drive the relay, which in turn switches the load.
Hmm... only very vaguely programming related :) I think we may need another StackOverflow for electronics. Maybe SparkOverflow?

Resources