Most, if not all, microcontrollers have a vector table for all the exceptions that are encountered when the program is running. I am quite confused as to whether the bootloader also has its own vector table for executing the reset handler?
I have written a bootloader that has been ported between a number of different embedded processors used within comms products (MSP430, AVR32, DSP56300). This loader had quite limited functional requirements
Hardware initialisation.
Validate the main code image using a checksum or cryptographic signature.
Transfer of control to the main application if the validation passes.
Provide a minimal command interface over a serial port to allow for firmware update.
Reentry point to allow the main application to trigger a new firmware load.
This transfer of operation between the two programmes held in non volatile memory on the same processor meant that I had to provide a re-direction of the interrupt functions between the two completely separate applications. The Interrupt table for the MSP430 is held in FLASH and so cannot be modified easily. It also holds the reset vector that must always point to the start of the bootloader code so erasing and rewriting this area runs the risk of completely bricking the unit.
The solution in this case was to have an interrupt service routine in the bootloader that redirected through a vector table located at a fixed location within the application memory space. Using this method added one indirect jump instruction to each interrupt handler resulting in a minimal extra processor load for each interrupt that is processed. The bootloader was written to not use any interrupts relying on polling the serial port status for all of the communications. If the bootloader needed to use interrupts then the vector table can be moved to RAM and initialised by the bootloader or application as required. (My processor did not have enough RAM to allow this)
There was a simple data structure at a fixed location in the main application code that contained entries for each possible interrupt/exception and the start address of the application code (you could consider this as the application code reset vector). As long as the application provided this data structure in flash and correctly populated it could be compiled and build completely separately as if it was the only application on the processor.
A bootloader is just a program there is no magic there, as with any other program if it needs a vector table the programmers create a vector table. Certainly if it needs to run from reset then it must conform to the hardware/processor rules for that. The processor nor any of the other logic has any way to know that that collection of bits, that collection of instructions is a bootloader or not. It just runs it.
I assume you are talking about the many, but not all, flavors/brands of microcontrollers that have bootloaders programmed at the factory?
Within an mcu there is a processor core with a memory bus. The many items in the chip, ram, flash, gpio, spi, timer, uart, adc, etc all live on that bus like having more than one house on a particular street. Each of these items on the processor bus have address decoders looking for their address on the bus to know when to take or provide data/information. The application flash and bootloader rom are no different, not special. As easy as it is to do in software it is as easy in hardware to have some sort of if-then-else that allows the application flash to answer the processor at the vector table addresses, that flag that drives the then or else cases can be an input pin to the part. Tie the pin high and hit the reset and the part boots from one memory, tie the pin low hit the reset and the part boots from the other. There are other solutions out there that are perhaps not driven by an input pin to the part but by the bootloader software.
Sometimes the processor core itself has a signal that the chip vendor drives however it wants, that within the processor core it does an if-then else, perhaps the then case is 0x00000000 is where it looks for the vector table, and the else case 0xFFFF0000.
At the end of the day though a bootloader is just another program, written by someone for this chip, no different than the program you write for the chip other than the fact that if it is a factory programmed rom bootloader then the programmer for that bootloader might have additional information/documentation for that part that we dont have. But being a bootloader is not magic it is just a program, a collection of instructions. our application can be a bootloader as well, with several possible different applicaitons based on what our bootloader finds, their bootloader can boot our bootloader which then chooses from several applications and runs one of them. All within one part...
Related
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.
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).
I have a project with a Arduino Uno where I need to store a char** that is too big for EPROM.
I am currently trying to do it with serial but I could also use a AVRISP programmer if needed (Not preferable)
So far I have looked into the avr/boot.h API but I am not really sure how to use it properly or if it is even the correct way to do it.
The arduino (specifically atmel 328 versions) only allow you to write to flash memory when the bootloader allows it.
The standard bootloader allows you to write to flash when a new program is being installed, but does not allow runtime programs to write to flash.
Solution: Install a bootloader that does allow you to run functions that enable you to write to flash.
Here is a bootloader (featured on hackaday) for an arduino that allows you to write to flash memory during runtime http://majek.mamy.to/en/writing-to-internal-flash-on-arduino/
Here is the hackaday post on the subject
https://hackaday.com/2015/07/03/arduinos-and-other-avrs-write-to-own-flash/
From the ATmega328P datasheet, "Boot Loader Support" section, "Application and Boot Loader Flash Sections" subsection, "Application Section" subsubsection:
... the SPM instruction is disabled when executed from the Application section.
Therefore there is no way to write to flash from the running program. Use an external memory device if you need to store more data than fits on-board.
I don't believe that's correct. The 328p does have the ability to control what some instructions about where they are allowed to access. I didn't see anywhere that this wasn't possible and in some configurations it (328p) can write flash under it's own control.
I searched the data sheet for 'SPM instruction is disabled' and hit only on the ATmega 48a/48pa. Having confused myself many times with that datasheet reading about the wrong controller. This didn't ring a bell.
Copied directly from the datasheet (660 pages):
"The ATmega 48A/48PA has no separate Boot Loader section, and the SPM instruction is enabled for the whole Flash if the SELFPRGEN fuse is programmed (“0”). Otherwise the SPM instruction is disabled."
The 328p has 'Lock Bit Byte' sets all of these controls, generally speaking.
These also control what access they have.
I would think you'd want to put it into eeprom (which IS different)...
Jack
We have a custom-built microcontroller card (ST32 / ARM Cortex M3) which has a camera attached. The camera captures 10-bit greyscale at 1280x1024 resolution. We need to send that image data back to a PC host over serial. That's quite a big chunk of data; at 115200 baud transfer would be 3 minutes, assuming everything goes fine. Anything I implement to ensure robustness would seem to slow that process down (eg split into blocks, checksum the blocks, ask for resend if corrupt). So was wondering how people might make a good compromise between speed and integrity.
We are currently seeing real transfer times of about 6 minutes. We had to set the UART baud rate at a weird value - 1036800 - because at 115200 there were issues (PC is running at 115200). I'm more software than hardware so any thoughts as to why that might happen would be helpful!
Start by doing some easy compression on your image.
Either run-length encoding or delta encoding will give you less data to send.
There are much better algorithms like TIFF but you may want to trade off the complexity of TIFF-ing your buffer for easier software on the embedded side.
Then you can afford something simple like Xmodem for your compressed data.
That has the useful property of being a standard protocol too.
That might lead you to using a terminal+xmodem transfer style interface to your host.
That would make debugging the interface pretty simple too.
Tim Williscroft's answer about compressing your data is a nice first step.
Now from the serial protocol side, the real transfer rate depends a lot on how you configure and implement your software both side. The baud rate is not the only thing to care about:
Are you using hardware flow control? If using hardware flow control, you will be able to significantly increase the baud rate (x10) without generating overrun errors.
From the STM32 are you using DMA, interrupts or even worth polling method to manage the data transmission? I don't know the exact STM32 reference you are using but on the STM32 I used, the UART transmission FIFO was limited to 1 byte. So you are merely obliged to use DMA if you have performance issues.
Still from the STM32 side, you can greatly improve performances taking care on the bus accesses (and possible conflicts arbitration) your application is doing.
Moreover on STM32, all clocks are configurable. Using an external high speed oscillator (if one available on board) may be a good way to improve performance over the internal RC oscillator. Also take care about internal bus clock configuration!
Now from the PC side, the performance may be impacted depending how your application bufferize & treat the received data.
The first thing to do is to look where the time is taken:
Observe your UART signal with a scope. As you said the transfer takes twice the theoretical time, you shouldn't see a continuous signal. Without hardware flow control it is the STM32 that takes time to output data. With hardware flow control, also look at the flow control signal to determinate which side causes the pauses (it may be both).
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?