I am trying to understand timer interrupts in Arduino.
I am finding a major difficulty in retrieving documentation.
Sources online refer to apparently "magical" constants (like TIMSK1 for example) but I am unable to find where they are defined.
Do they come from some sort of header file?
Is there some reference documentation anywhere?
You've already answered, but I'd like to fill in some gaps, perhaps.
Those symbols are not magical, they are the names of the processor and I/O registers and values for the bit-fields inside those registers. As you found, the processor datasheet explains the layout of the I/O registers. This is standard for all microcontroller vendors.
Here's the home page for the Mega328P: https://www.microchip.com/en-us/product/ATmega328p
since the datasheet PDF might change some day. Note that farther down the page there are many very helpful "application notes" that describe how to do things...
How does a C program, or an Arduino script, get the values of the registers and fields? From the vendor supplied header files. See here for Microchips "packs": http://packs.download.atmel.com
The compiler that comes with the Arduino IDE distribution has included the headers for the boards it supports. They're buried pretty deeply - we go to the datasheet to find the register and field names, not usually to the header files.
For the mega328, the header file is here (macos): ~/Arduino.app/Contents/Java/hardware/tools/avr/avr/include/avr/iom328p.h
I'm not sure why you said "(although not explained in full detail)". There's really not much to it - it just holds a few bits that enable interrupts when certain things happen in Timer/Counter 1.
From the 328P datasheet 01/2015, TIMSK1 is described on page 90 "All interrupts are individually masked with the Timer Interrupt Mask Register (TIMSK1)." The register layout is on page 112. And its position within the I/O register set on page 278. A programmer doesn't need more than that! :-)
(I wish I could attach a pdf... it has a big table of the registers, fields, interrupt vectors, DIP pins, ... all generated from that header file.)
After some search I found that in the the ATMega processor manual those constants are named (although not explained in full detail)
One possible location of the manual is:
https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf
What I know is as below and correct me if wrong, For the automotive bootloader based on any microcontroller, we will have
Startup code (Flash)
Primary bootloader (Flash)
Secondary bootloader (RAM)
As far as a power-on sequence is considered I know that,
From the startup code (provided by the micro vendor, Freescale, ST
Micro, etc.,) the control will be transferred to PBL (Primary
bootloader) using jump or function pointer.
PBL will download the SBL (Secondary bootloader) into RAM, which will
contain the flash driver, capable to download the application.
SBL will download the application into the flash area.
But what will happen before startup code is being executed or just after power on?
I know that each controller will have some sort of code to execute after power on POST (power-on self-test) but still not clear with sequence to operation till bootloader execution comes into execution.
It would be a great help if someone can provide a sequence of operations to reach startup code?
I find it this not uncommon confusion interesting.
POST is software in general, but your question is so vague. Usually when someone talks about POST they are talking about their x86 based computer, that is just software, happens well after the part you are confused about, and is in no way whatsoever required for a computer/processor to run, it has a purpose, adds value so it is there.
Microcontrollers in general do not have primary bootloaders nor secondary, they simply start running your application. Of the dozens/hundreds I have used/examined trying to think of any that have a primary or secondary. Can't think of any off hand. Certain brands in particular do have bootloaders that are usually programmed by them and you cant change or some that you can. How you get into the bootloader varies by brand, often a strap, sometimes a non-volatile bit in a register.
First off processors and the chip around it are dumb, very dumb. Only do what they are told by the humans. Incredibly simple machines. And while the difference between an mcu and a full blown system are at this view pretty much identical, the mcus are simpler and more reliable (for various reasons). The root of the answer starts with the processor or processor core or core or whatever term
might help you. In an mcu this is just one lego block in the whole of the chip, not necessarily even the largest block in the chip. When you look at arm based chips like the stm32 and others with a cortex-m (or older ones with ARMV7TDMI) that lego block is purchased ip from arm, the rest of the chip is either other purchased ip from one or more vendors or in-house made logic. the sram certainly and the flash probably is ip that the chip vendor buys for the specific process on the specific foundry (just like other cell library items, simple gates like AND, OR, NOT and more complicated gates).
Whatever processor core this is, it has an architecture and instruction set. While we know some architectures are implemented using microcode, unlikely that the mcus are, makes no sense the more cisc like might, but the arms and mips and such definitely not. But for this understanding it doesn't matter being microcoded or not there are bit patterns that drive the processor, machine code. We have all heard that chips are made of transistors, and they are. The transistors are part of the simplicity, the basic ones AND, OR, NOT gates you can look up on Wikipedia. You can (inefficiently) build the rest out of those fundamental blocks. A particular instruction tickles the logic, the transistors in a certain way to cause a chain of events, ones and zeros in a specific sequence that do the thing you asked. Logic is not limited to implementing processor instructions, most logic is not part of the decoding and execution of a processor instruction, most if it are equally dumb items. An sram is a lot of packed in bits (four transistors wired up a certain way per bit) with an address and data bus, the logic of an sram lights up rows and columns of these bits when writing or reading. Then there is more logic in front of that sram that decodes an address bus, etc.
As mentioned in the other answer, when power comes up then reset is released, the flip flop based items in the chip which are the registers we read in the manual plus countless others that are behind the scenes are set to their reset value which is done by wiring of the transistors. A number of state machines start which are similar to programs, but are hardwired. wait for reset to go high, once reset goes high then if this input to the state machine is this and that input to the state machine is that then I can move to the next state. The rules to get from one state to the next are implemented in logic. A chip with memory and flash for example might do a bist on the ram first, likely not in an mcu, doesn't make sense, this is logic not software doing this, this is not the post you think of in your laptop/desktop/server. The flash or ram or adcs or other logic might require some number of clocks to settle their logic before reset is released (the reset on the edge of the chip is not necessarily hard wired to all items in the chip, usually it is gated, delayed, etc). So there is a power on state machine that manages this, when the chip is ready then the processor itself will be released, this can be a few or dozens of clock cycles later. The clock itself has to settle, and the logic is designed to wait for that.
When the processor is released from reset it again may have some number of clocks to settle things in its design, it will have a state machine or many that start up the various blocks, and then based on the architectural design of that processor it does one of two things, fetches its first instruction from a known address (address within the processors address space which isn't necessarily the address in the chips view), or it uses a vector table approach and it reads a value from a known address, and that value read is the address of the first instruction and it fetches that instruction. Up to the first fetch there is no software, it is logic.
Depending on how the chip vendor has designed the chip, how they have defined the address space, and understand that addressing within a chip or board design is not some flat universal thing, to the programmer it is, but in reality it isn't. There are many busses with addresses and those address spaces are specific to that portion of the design. When you see the stm32 or others with a bootloader and a strap (boot0/boot1 pin), the logic on the other end of the processor bus may see a fetch at the well known address (meaning both the folks that implement the logic and the folks that write software for the logic know that this is the specific address where things start and if you don't put stuff there it won't boot/work) but as mentioned the chip vendor can do whatever they want with that and often do. As a programmer this can be easily understood as logic isn't any more magical than software:
if strap == 0 return flash_bank_0[address&mask]
else return flash_bank_1[address&mask]
For a certain address range that is decoded in front of this code, but also both banks may be directly addressable:
if address[24]==0 return flash_bank_0[address&mask]
else return flash_bank_1[address&mask]
And this way you can have what you see in the stm32s, that both address 0x00000000 and 0x08000000 or in other vendors chips 0x00000000 and 0x01000000 for example map to the same (flash) memory.
The reason being is that the cortex-ms is vector based, there is a table of addresses that point you at code rather than just instructions at known addresses (like the full sized arms arm7, arm9, arm11, cortex-a). The way you use that is you set your address for reset in the table to be 0x08000000 based so when the processor reads at 0x000000xx it is told to fetch instructions from 0x0800xxxx and it does. When the strap is the other way it finds a different flash which may or may not have a fixed space it may only be visible from the if-then-else. (pretty easy to see with a cortex-m and an SWD debugger and software).
The stm32s will have logic that if the strap is set to run the user application will fetch my guess is four words, if the first one or a specific one is all ones or for some chips all zeros (very often flash/rom resets to ones, because there is a logic in version saving a transistor, so the bit is a zero, but we see it as a one, the bits are all inverted, but this is not a hard and fast rule, just very common) the logic/state machine will, for the stm32 realize there is no user application and will load the bootloader. Now it is very possible the design actually always boots the bootloader and there is software there that looks at the application flash, but I think myself and others on this site decided that is not the case, but none of us work there nor have the visibility into the design. In either case the processor then starts executing what it finds and it is very dumb it is told fetch from this address and it does, the programmer had to make sure that stuff is at that address, and each and every instruction has to be laid out in order properly like train tracks, any gaps or mistakes and the trail goes off the rails, otherwise the train is stupid it just follows the tracks. As humans we call the software post or bootloader or application or whatever. It is just software. Once the processor is started if some software loads and runs other software the processor doesn't know it is stupid it just keeps performing the instructions it is fed as it rolls down the track.
Short answer:
Power ramps up to a chip specified level. At a chip specified time reset should be released. This releases state machines to get the chip ready as needed and release the processor. The processor based on its design either fetches its first instruction from a known place or it reads from a known place and that user planted value is the address where the first instruction lives. After that per the architecture of the chip the execution of that first instruction and fetching of more based on that instruction continue until it crashes or is turned off or put in reset.
There is no magic.
There are a number of good open cores out there that you can simulate with free tools and see (with free tools) the internal signals that make that chip work, you can see the post reset activity leading up to the first fetch and then all the execution from there.
Without knowing which microcontroller you are using, this should be general enough:
The hardware in the microcontroller resets several registers to their documented values. This includes the PC, the program counter.
If the microcontroller has configurable reset vectors the value can be chosen from a few alternatives, other controllers always use the same value.
The code at the location the PC points to is the startup code.
Note: It's always a good idea to read the data sheet of the controller!
I have a Cortex M0+ (SAML21) board that I'm using for performance testing. I'd like to measure how many cycles a given piece of code takes. I tried using DWT (DWT_CONTROL), but it never produced a result; it returned 0 cycles regardless of what code ran.
// enable the use DWT
*DEMCR = *DEMCR | 0x01000000;
// Reset cycle counter
*DWT_CYCCNT = 0;
// enable cycle counter
*DWT_CONTROL = *DWT_CONTROL | 1 ;
// some code here
// .....
// number of cycles stored in count variable
count = *DWT_CYCCNT;
Is there a way to count cycles (perhaps with an interrupt and counter?) much like I can query for milliseconds (eg. millis() on Arduino)?
I cannot find any mention of the cycle counter register in the ARMv6-M Architecture Reference Manual.
So I'd say, this is not possible with an internal counter like it is in the bigger siblings like the M3, M4 and so on.
This is also stated in this knowledge base article:
This article was written for Cortex-M3 and Cortex-M4, but the same points apply to Cortex-M7, Cortex-M33 and Cortex-M55. Newer Cortex-M processors at the higher end of performance, such as Cortex-M55, may include an extended Performance Motnioring Unit that provides additional preformance measuring capabilities, but these are outside the scope of this article. The smaller Cortex-M processors such as Cortex-M0, Cortex-M0+ and Cortex-M23 do not include the DWT capabilities described here, and, other than the Cortex-M23, do not include ETM instruction trace, but all Cortex-M processors provide the "tarmac" capability for the chip designers.
(Emphasis mine)
So other means have to be used:
some debuggers can measure the time between hitting two breakpoints (or between two stops), the accuracy of this is usually limited by interacting with the OS, so can easily be in the order of 20 ms
use an internal timer with high enough clock frequency to give reasonable results and start / stop it before and after the interesting region
toggle a pin and measure the time with a logic analyzer / oscilloscope
According to the CMSIS header file for the M0+ (core_cm0plus.h), the Core Debug Registers are only accessible over the Debug Access Port and not via the processor. I can only suggest using some free running timer (maybe SysTick) or perhaps your debugger can be of some help to get access to the required registers.
Can anyone tell me what major and minor (contained within the advertisement packet of BLE signals) are used for? I've heard that it's used for differentiating signals with the same UUID, but that raises questions like "why use two" and "is that just how certain receivers use it". It would be useful to have a decent explanation of it.
As per #Larme's comment, I presume you are asking about iBeacon advertisements - these are a special use of BLE. Bluetooth Low Energy service advertisements have a different format and don't include the major/minor.
The iBeacon specification doesn't say how to use major and minor - this is defined by the people that implement solutions using iBeacon. Two numbers just gives more flexibility.
A lot of effort went into making BLE use very little power. Accordingly the iBeacon advertisement has to be quite small in order to minimise the transmission time. I guess the designers decided two 16 bit numbers was a reasonable compromise between power consumption and a useable amount of information.
A typical retail use case could use the major to indicate a store (New York, Chicago, London etc) and the minor to indicate the department (shoes, menswear etc). The app that detects a beacon can then pass this information to a server which can send back relevant information - the user's location on a map or specials for that department etc. This was discussed in the guide that #Larme linked to.
A solution that presented information on museum exhibits might just use the major number to determine which exhibit the person was near and ignore the minor number. The minor number would still be in the advertisement, of course, the app just wouldn't use it for anything.
I'm working with some simple VGA driver code for use with the Xilinx Spartan 6 FPGA (via a Papilio Pro board). The code expects to have 4-bits of output per color, and so defines logic vectors for each color. However, my setup doesn't happen to provide the full 4 bits per color so I wanted to find a creative way to control this via the UCF.
The original UCF defined 4 pins for each color. In the case of blue, I only have two pins, so I chose to map the two I have to blues MSBs, thus:
NET Blue(0) IOSTANDARD=LVTTL; # N/C
NET Blue(1) IOSTANDARD=LVTTL; # N/C
NET Blue(2) LOC="P92" | IOSTANDARD=LVTTL; # to a pin
NET Blue(3) LOC="P87" | IOSTANDARD=LVTTL; # to a pin
(I totally omitted the first two constraints at first, and it still compiled and worked but complained about the inconsistent voltage standards (the absent ones defaulted to IOSTANDARD = LVCMOS25), thus throwing "WARNING:Place:838 - An IO Bus with more than one IO standard is found.")
The main warning is the one I'd like to know how to eliminate, preferably within the UCF:
WARNING:Place:837 - Partially locked IO Bus is found.
Following components of the bus are not locked:
Comp: Blue<1>
Comp: Blue<0>
What's the right way to map a net without a programmable pin location to a default value (logic '1' or '0', or perhaps a tri-state value) within the UCF in such a way as to eliminate this "Partially locked IO Bus" sort of warning?
My goal is that, in a setup with more or fewer bits per channel being driven by pins, only the UCF should need to change (not the source code). What I did works, despite the warnings... I'd just like to do it better and properly eliminate these warnings.
You've asked for pins within the top level of your code (on your entity). The tools therefore have to provide them. Hence you have to map them (otherwise it'll pick some random ones for you, which you usually don't want)
If those pins really have nowhere to go on the board and never will have, then remove them from the design completely (UCF and HDL).
Otherwise, you have to LOC them. You could add a PULLDOWN in the UCF to them to ensure they go to a low value.