This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

interrupts messin' with vsprintf ?

I have a 1ms fixed time interrupt scanning and debouncing a couple of switches, and a 1200 baud port receiving blocks of 17 chars 4 times a sec.
Asynchronously at 5 times/sec, I'm assembling an 8 character string to display on an 8 character DM display.
This code now uses a vsprintf statement, and occasionally the output string gets leftshifted one character in the buffer.
Surrounding the vsprintf call by EA=0 and EA=1 solves the problem, but the resulting delay to my fixed time interrupt messes up the switch scan.
Anybody have any clues on why vsprintf is getting upset, and how to get around it?
Thanks in advance.

Parents
  • I did check the arg sizing - yes, I've been burned by that before myself.
    Here's what I'm going to do next:-
    I have a classic serial rcv interrupt handler loading a circular buffer, and an async unloader with its own buffer getting info to display. This is using up tons of space, and I only have 17 bytes of stack left.
    As I have a fixed format coming in the serial port, I'll combine the two functions into the interrupt routine, which will save some buffer handling time and a gob of memory, relatively speaking ;-> The interrupt time will go up slightly, but I only get four 17-char blocks every second @ 1200 baud, so I should be OK.
    I've got to get the stack under control, otherwise I don't have a snowball's chance of success.
    Thanks again for your suggestion.

Reply
  • I did check the arg sizing - yes, I've been burned by that before myself.
    Here's what I'm going to do next:-
    I have a classic serial rcv interrupt handler loading a circular buffer, and an async unloader with its own buffer getting info to display. This is using up tons of space, and I only have 17 bytes of stack left.
    As I have a fixed format coming in the serial port, I'll combine the two functions into the interrupt routine, which will save some buffer handling time and a gob of memory, relatively speaking ;-> The interrupt time will go up slightly, but I only get four 17-char blocks every second @ 1200 baud, so I should be OK.
    I've got to get the stack under control, otherwise I don't have a snowball's chance of success.
    Thanks again for your suggestion.

Children
No data