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
  • Three tasks as stated, correct: timer at high priority "using 1"; serial at low priority "using 2", eveything else "using 0" by default.
    Some folk refer to non-interrupt as fg, some as bg. It seems to depend on your point of view or focus at the time! To try to avoid the religious argument, I refer to non-interrupt as "asynchronous" (i.e. to any specific hardware event).
    Anyhow, vsprintf is not called from any interrupt, only from a function called from an infinite loop in main().
    "First character dropped":
    The first character is always a space where a minus sign would be, so I'm not sure if the character is dropped, or whether it is left-shifted. I'll try to find that out. No characters EVER appear to be missing from within the string, however.
    I "know" only because
    a)it appears that way on the 8-char display.
    b) because the protocol decoder never reports a chcksum error.
    Continuing from last night's discussion, at this moment I'm debugging changes I proposed to make to the serial input interrupt handler, where I remove the second buffer and handle the "protocol" in the interrupt, thus getting stack back. I'll report when it's running.
    Thanks for helping !!!

Reply
  • Three tasks as stated, correct: timer at high priority "using 1"; serial at low priority "using 2", eveything else "using 0" by default.
    Some folk refer to non-interrupt as fg, some as bg. It seems to depend on your point of view or focus at the time! To try to avoid the religious argument, I refer to non-interrupt as "asynchronous" (i.e. to any specific hardware event).
    Anyhow, vsprintf is not called from any interrupt, only from a function called from an infinite loop in main().
    "First character dropped":
    The first character is always a space where a minus sign would be, so I'm not sure if the character is dropped, or whether it is left-shifted. I'll try to find that out. No characters EVER appear to be missing from within the string, however.
    I "know" only because
    a)it appears that way on the 8-char display.
    b) because the protocol decoder never reports a chcksum error.
    Continuing from last night's discussion, at this moment I'm debugging changes I proposed to make to the serial input interrupt handler, where I remove the second buffer and handle the "protocol" in the interrupt, thus getting stack back. I'll report when it's running.
    Thanks for helping !!!

Children
No data