We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
"Do you interrupt routines call functions that are also called by the main function?" Nope. "Do you receive any errors or warnings when you link?" Only "L16: Uncalled segment" warning. I'm happy with those, they're uncalled functions. Thanks for helping.
What happens if you all ways pass the vprintf statement a constant negative number? I am still interested in your Timer & Serial interupt priorities. The "using" statement refers to which register bank is associated with the ISR. Priority are set by you. You need to set bits in the IP (interrupt priority register). Sounds like they are at the same level. Just acomment on "I'm happy with those, they're uncalled functions." This is not quit true. The memory for their local variables though not used, are allocated and not shared by the rest of the program. If you would like more data space for your buffers, I would get rid of them.
"What happens if you all ways pass the vprintf statement a constant negative number?" I'll find out as soon as I get the new rcv code running. As I said earlier (actually, late last night!) I think I was blowing the stack, so I had to fix that problem first. "I am still interested in your Timer & Serial interupt priorities. The "using" statement refers to which register bank is associated with the ISR. Priority are set by you. You need to set bits in the IP (interrupt priority register). Sounds like they are at the same level." Understand. A code snippet will help here, I think: The serial port setup: /*------------------------------------------ Setup serial port registers. ------------------------------------------*/ SM0 = 0; SM1 = 1; /* serial port MODE 1 */ SM2 = 0; REN = 1; /* enable serial receiver */ TI = 0; /* clear transmit interrupt */ RI = 0; /* clear receiver interrupt */ ES = 1; /* enable serial interrupts */ PS = 0; /* set serial interrupts to low priority */ and now the fixed time interrupt :- TMOD &= ~0x0F; // clear timer 0 mode bits TMOD |= 0x01; // set 16-bit no prescale mode TL0 = (TIMER0_COUNT & 0x00FF); TH0 = (TIMER0_COUNT >> 8); PT0 = 1; // set high priority for timer 0 ET0 = 1; // enable timer 0 interrupt TR0 = 1; // start timer 0 (I omitted the EA=1, but it is in the code.) As you can see, the priority bits are taken care of. Point taken on the uncalled functions issue. I will certainly clean them up shortly. Right now I appear to have enough stack space, and I'm trying to get my new serial decoder working. I have a 17 byte fixed-format string coming in, and I have a checksum error for some reason. I'll report again as soon as it's working. Many thanks for the help, I appreciate it.
Sorry about the multiple posts. The forum software reported a timeout error, but accepted the post anyway. Seems I'm not the only one with bugs ;->
Well it helps, if one is accumulating a checksum, to do so BEFORE stripping off the parity bit ... More to the point, it seems that getting more stack room solved my problem with vsprintf. I've spent all my embedded years on x86 and 68k, where stack space was the least of my problems. This x51 stuff requires a whole different discipline and strategy. Many thanks to those who offered help. Kudos, too, to Keil for a great optimizing compiler - I guess they take the 'micro' out of 'microcomputer' :-) On to the next problem ...