I'm currently taking a microprocessors course that uses the MSP430g2553 and I've noticed that the example C code our professor writes makes extensive use of global variables.
What would be the reasoning behind this?
(I've always been told to use globals only when absolutely necessary, so I assume something about the structure of microprocessors makes them necessary.)
UPDATE: I forgot to include sample code. Here's an early example c program we saw in class:
#include <msp430g2553.h>
volatile unsigned int blink_interval; // number of WDT interrupts per blink of LED
volatile unsigned int blink_counter; // down counter for interrupt handler
int main(void) {
// setup the watchdog timer as an interval timer
WDTCTL =(WDTPW + // (bits 15-8) password
// bit 7=0 => watchdog timer on
// bit 6=0 => NMI on rising edge (not used here)
// bit 5=0 => RST/NMI pin does a reset (not used here)
WDTTMSEL + // (bit 4) select interval timer mode
WDTCNTCL + // (bit 3) clear watchdog timer counter
0 // bit 2=0 => SMCLK is the source
+1 // bits 1-0 = 01 => source/8K
);
IE1 |= WDTIE; // enable the WDT interrupt (in the system interrupt register IE1)
P1DIR |= 0x01; // Set P1.0 to output direction
// initialize the state variables
blink_interval=67; // the number of WDT interrupts per toggle of P1.0
blink_counter=blink_interval; // initialize the counter
_bis_SR_register(GIE+LPM0_bits); // enable interrupts and also turn the CPU off!
}
// ===== Watchdog Timer Interrupt Handler =====
// This event handler is called to handle the watchdog timer interrupt,
// which is occurring regularly at intervals of about 8K/1.1MHz ~= 7.4ms.
interrupt void WDT_interval_handler(){
if (--blink_counter==0){ // decrement the counter and act only if it has reached 0
P1OUT ^= 1; // toggle LED on P1.0
blink_counter=blink_interval; // reset the down counter
}
}
ISR_VECTOR(WDT_interval_handler, ".int10")
According to MSP430 data sheet, it has up to 512 KB flash memory (for program storage) and 66 KB ram (for data storage). Since you haven't provided any code sample, it is highly possible that your prof may have wanted to use the ram in an optimal fashion. There may be some functions declared, using the same data as an input or he just defined variables in global region without regarding any performance issue and totally unintentional (which is I don't think so, but it is a probability too). The important point you should care is, always try to use these limited resources in an efficient way, especially on an embedded device.
There is nothing special about microcontrollers that makes global variables necessary. Global variables are undesirable in embedded systems for all the same reasons they're undesirable in other systems. Jack Ganssle explains the reasons in his blog post on globals.
Yes, microcontrollers have a limited amount of RAM but that's not an excuse to use global variables freely.
Ask your instructor why he/she is using global variables. Perhaps your instructor is more concerned with teaching you about microprocessors than demonstrating good software design.
Related
I'm trying to emulate an Arm cortex M33 using QEMU, using the an505 model. I've used this git repo as a starting point.
I've successfully built the project and even managed to debug into it however now I want to measure the cpu cycles consumed - without any luck.
Firstly, I tried to access the DWT registers like so:
#define ARM_CM_DEMCR (*(uint32_t *)0xE000EDFC)
#define ARM_CM_DWT_CTRL (*(uint32_t *)0xE0001000)
#define ARM_CM_DWT_CYCCNT (*(uint32_t *)0xE0001004)
main()
{
if (ARM_CM_DWT_CTRL != 0) { /* See if DWT is available */
ARM_CM_DEMCR |= 1 << 24; /* Set bit 24 */
ARM_CM_DWT_CYCCNT = 0;
ARM_CM_DWT_CTRL |= 1 << 0; /* Set bit 24 */
}
}
however ARM_CM_DWT_CTRL appears to be 0, indicating that the DWT register is not configured. This code is working on the actual M33 hardware I have. I've checked the an505 doc and I can't see anything wrt DWT. Is this therefore a lost cause? Is it not likely that the FPGA would implement the DWT register?
I moved on to using the SysTick API as described here however when I access SysTick->VAL it equals 0.
I've also tried to read from STCVR = 0xE000E018 as per the instructions here but also, this returns 0.
Am I missing something fundamental here?
QEMU is not a cycle accurate model. We also don't implement the DWT unit.
The SysTick timer in QEMU's implementation will essentially measure real-world time. This is not a very good guide to what real-hardware performance will look like.
If you want to measure the performance of code then your best bet is usually to do it on the real hardware that you care about. Getting performance information out of an emulation is tricky at best. This old answer to another question has a runthrough of some of the difficulties.
I'm using an STM32H743. I have an external clock signal coming in on a GPIO pin, and I want to very accurately measure elapsed time between each rising (or falling) edge in the external clock signal. So I set things up so that TIM4 is triggered by the external clock, and TIM5 is triggered by the internal oscillator.
I wrote an IRQ so that whenever TIM4 triggers, an interrupt runs that captures TIM5's value. It seems to work OK, but I'm wondering if I can do it through DMA to avoid all the context switching and free up the CPU. Basically I want to set up a DMA so that each TIM4 event initiates a DMA transfer that copies the TIM5 counter value to a circular buffer somewhere.
I've searched through forums and the DMA documentation but I'm hazy on whether a timer register can be a valid DMA source. I was thinking maybe I could do something like this:
hDma->PAR = (uint32_t) &htim5.Instance->CNT;
hDma->M0AR = (uint32_t) myBufferPtr;
hDma->NDTR = myBufferSize;
hDma->CR |= (uint32_t)DMA_SxCR_EN;
But I'm not sure if this can work.
Short version: Can I use the timer's CNT register as a DMA transfer source? Would it be a peripheral-to-memory transfer? Or a memory-to-memory transfer? Are there other flags I need to make this work? Or is it not possible? Or is there another STM32 feature that would make it easier to count time between pulses?
Disclaimer
I must confess that my long practical experience with STM32 by now stayed with mainstream controller families like STM32F0, STM32F3, STM32F4 and STM32L4.
Therefore I'm answering based on what those controllers would offer you in your situation.
The STM32H7 series is much stronger, let alone it offers several additional DMA technologies like DMA2D, MDMA and lots of other stuff that I'm not sure about.
But I think a simplified answer might also help you for now, so I'm daring to write it.
Can I use the timer's CNT register as a DMA transfer source? Would it be a peripheral-to-memory transfer? Or a memory-to-memory transfer? Are there other flags I need to make this work? Or is it not possible?
I would expect this to work.
I don't see a reason not to read the TIMx_CNT register in a DMA transfer.
The CNT register is definitely a peripheral address so you have to configure it as a peripheral-to-memory transfer.
I believe that the peripheral/memory separation refers to the bus from which the DMA controller fetches the data (or to which bus one it delivers them) in the bus matrix implemented in every STM32.
Or is there another STM32 feature that would make it easier to count time between pulses?
Yes, there is:
Many of the TIM peripherals (not all are the same) offer you a feature called "Input Capture" that connects the channel (sub-)peripheral of the TIM instance to the input and has the main part of the (same!) TIM peripheral do the internal clocking.
A prerequisite of this is, that the pin you'd like to measure has a TIMx_CHy alternate function, not "only" a TIMx_ETR one.
The TIM peripherals offer a wealthy range of different configuration options - and a complicated mess as long as you haven't got used to it.
As an introduction and a good overview, I recommend two application notes from ST:
AN4013 Application note. "STM32 cross-series timer overview", Rev.8
Which timers you have on your µC, and which features are offered by which one.
AN4776 Application note. "General-purpose timer cookbook for STM32 microcontrollers", Rev.3
How to use the timers you have. Check out section 2.6, input capture is on page 27.
Looking up those two, I found a third one you might want to check out for better precision, related to HRTIM timers:
AN4539 Application note. "HRTIM cookbook", Rev.4
It is easily done using STM32CubeIDE configurator:
configure timer, enable input capture channel, enable DMA (mode
circular, peripheral to memory,data width word/word). Enable
interrupts.
Prepare buffer for storing captured counter values
Start IC in DMA mode before main loop
For high speed operation you may copy data from timerCaptureBuffer
to timerCaptureBufferSafe inside these callbacks. For example, DMA memory to memory transfer to minimize time spent in HAL_TIM_IC_CaptureHalfCpltCallback and HAL_TIM_IC_CaptureCallback interrupts. Process adjacent captured values stored in timerCaptureBufferSafe after DMA memory to memory callback signals data is ready. You may use signaling flags so timerCaptureBufferSafe will not be overwritten.
Here is an example:
#define TIM_BUFFER_SIZE 128
uint32_t timerCaptureBuffer[TIM_BUFFER_SIZE];
uint32_t timerCaptureBufferSafe[TIM_BUFFER_SIZE];
// ...
HAL_DMA_RegisterCallback(&hdma_memtomem_dma2_stream2,
HAL_DMA_XFER_CPLT_CB_ID,
myDMA_Callback22);
// ...
HAL_TIM_IC_Start_DMA(&htim2, TIM_CHANNEL_1, uint32_t*)timerCaptureBuffer,TIM_BUFFER_SIZE);
// ...
void HAL_TIM_IC_CaptureHalfCpltCallback(TIM_HandleTypeDef *htim)
{
HAL_DMA_Start_IT(&hdma_memtomem_dma2_stream2,
(uint32_t)&timerCaptureBuffer[0],
(uint32_t)&timerCaptureBufferSafe[0],
sizeof(timerCaptureBuffer)/2/4);
// ...
}
void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)
{
HAL_DMA_Start_IT(&hdma_memtomem_dma2_stream2,
(uint32_t)&timerCaptureBuffer[TIM_BUFFER_SIZE/2],
(uint32_t)&timerCaptureBufferSafe[TIM_BUFFER_SIZE/2],
sizeof(timerCaptureBuffer)/2/4);
// ...
}
void myDMA_Callback22(DMA_HandleTypeDef *_hdma)
{
//...
}
I have several interrupts in the system, including TC capture, external interrupts and ADC conversion interrupts. There's one vector in particular that, when executed, will prevent ANY vector from executing even after the reti() instruction.
The TCB2 Capture interrupt vector (Vector 25) is the only vector in the system that stops everything leading to a WDT reset.
Global Interrupt Flag is 1, and the INTFLAGS for the activated interrupts get set correctly when an interrupt occurs. But no vector is executed.
This applies for all interrupts.
I've tried changing the vector a little, making sure the reti() instruction is present and making sure the vector table didn't change.
I also already made sure the code kept executing normally after the reti(). The only thing that seems not to work are vectors.
volatile uint8_t new_input_regs = 0x00;
/*[Other code, including other vectors without this issue]*/
void __vector_25() {
new_input_regs = PORTD_IN; //Get PORTD input values
TCB2_CTRLA &= ~(0x01); //Clear TC enable and flags
TCB2_INTFLAGS = 0xFF;
asm("WDR"); //Reset the WD timer
event_type = EVENT_INPUT_INTERRUPT; //Set the event
reti();
}
After this executes, all interrupts stop working until reset (This also causes a Watchdog Reset eventually due to no interrupts executing).
More info about the register and vector table here: https://imgur.com/a/SpLKrgT
Thanks to the comment, i've noticed the ISRs were too optimized, even skipping retis and merging vectors in one single block of assemble with no returns. The default vector functions (Like __vector_25() used above) do not work as expected, leading to un-terminated ISRs and missing reti() even when manually written. This lead to completely unexpected behaviour.
I've changed the vector definition to ISR(_VECTOR(25)) and removed reti() at the end of functions. Interrupts have resumed working as they should.
Thanks for the help.
I'm developing software for an NXP LPC1788 microcontroller, and I'm using the embOS RTOS. Whenever a message is received over USB, I want to use the OS_PutMailCond() function to store the USB message in a mailbox which a handler function is waiting on. In other words, I want to make message handling interrupt-driven.
The embOS user manual can be found here. Page 145 describes the OS_PutMailCond() function.
Whenever a USB message is received, it triggers the USB interrupt service routine on the LPC, but to let embOS know that it's an ISR I have to place OS_EnterInterrupt() and OS_LeaveInterrupt() at the start and end of the ISR respectively. This is necessary if I want to call embOS functions within it, including OS_PutMailCond().
The problem is that if I put OS_EnterInterrupt()/OS_LeaveInterrupt() anywhere within the USB ISR, the USB stops functioning properly and Windows informs me that the device has malfunctioned.
I have no idea why this is the case. We've tried something similar for handling messages over CAN, as shown below, and it works fine.
void CAN_IRQHandler(void)
{
OS_EnterInterrupt();
...
if (MBfieldCANframeInitialised)
OS_PutMailCond (&MBfieldCANframe, &recMessage);
OS_LeaveInterrupt();
}
OS_EnterInterrupt() and OS_LeaveInterrupt() are described on pages 252 and 253 of the linked manual. From the additional information section of the former:
If OS_EnterInterrupt() is used, it should be the first function to be
called in the interrupt handler. It must be used with
OS_LeaveInterrupt() as the last function called. The use of this
function has the following effects, it:
disables task switches
keeps interrupts in internal routines disabled
EDIT
I've investigated further and found out that using OS_EnterInterrupt() and OS_LeaveInterrupt() within the USB ISR (and other ISR's like the one for the GPIO when a rising or falling edge is detected on a pin) causes an OS error. The error value is 166, which means "OS-function called from ISR with high priority".
I'll update if I find out anything else.
Problem solved. It turns out the guy that made this work for the CAN ISR changed the code of one of the embOS source files to set the CAN ISR priority level from 0 to 29 (higher level = lower priority). I did the same thing for the USB ISR:
void OS_InitHW(void) {
OS_IncDI();
//
// We assume, the PLL and core clock was already set by the SystemInit() function
// which was called from the startup code
// Therefore, we don't have to initailize any hardware here,
// we just ensure that the system clock variable is updated and then
// set the periodic system timer tick for embOS.
//
SystemCoreClockUpdate(); // Update the system clock variable (might not have been set before)
if (SysTick_Config (OS_PCLK_TIMER / OS_TICK_FREQ)) { // Setup SysTick Timer for 1 msec interrupts
while (1); // Handle Error
}
//
// Initialize NVIC vector base address. Might be necessary for RAM targets or application not running from 0
//
NVIC_VTOR = (OS_U32)&__Vectors;
//
// Set the interrupt priority for the system timer to 2nd lowest level to ensure the timer can preempt PendSV handler
//
NVIC_SetPriority(SysTick_IRQn, (1u << __NVIC_PRIO_BITS) - 2u);
NVIC_SetPriority(CANActivity_IRQn, (1u << __NVIC_PRIO_BITS) - 3u);
NVIC_SetPriority(CAN_IRQn, (1u << __NVIC_PRIO_BITS) - 3u);
NVIC_SetPriority(USB_IRQn, (1u << __NVIC_PRIO_BITS) - 3u);
OS_COM_INIT();
OS_DecRI();
}
I found this in the embOS documentation:
Why can a high priority ISR not use the OS API ?
embOS disables low priority interrupts when embOS data structures are modified. During this time high priority ISR are enabled. If they would call an embOS function, which also modifies embOS data, the embOS data structures would be corrupted.
I have a problem with set-up interruption flag in AVR AT90S2313. Normally interruption is setting-up through hardware counter. I want to setting this flag in programming way when I want (at the specific moment). I'm writing all code in C:
SEI(); //enable globall interupt
TIMSK | = (1<<TOIE1); //enable interrupt from timer 1
TIFR | = (1<<TOV1); //enable interruption (setting bit) - IT DOESN"T WORKS!
So, in the last line it should be programming interruption but nothing is happening and I don't know why. Any idea? Thanks in advance.
TIFR registers are special in that writing a 1 to a bit sets it to 0.
Edit in response to a comment:
You shouldn't be doing anything with the register as far as I can tell from what little information you have supplied. That is, don't try to use the interrupt mechanism to run the handler. At the point in your code where you want to trigger the interrupt, just call the handler yourself. You may also want to be adjusting the enable bits or clearing flags at the same time -- I don't know what you are trying to do.
If you want the handler to run as if it were acting in response to an interrupt, then you will want to disabled interrupts first. The usual way to do this is
void function_to_trigger_handler()
{
uint8_t sreg = SREG;
cli();
my_interrupt_handler();
SREG = sreg;
}