Okay, here is a skeleton program and an ISR for an SCI receive with buffer and XOFF. I did not handle framing or noise errors and I'm assuming that the transmitter is not busy (I polled the transmitter ready bit, which I wouldn't normally do in an ISR).
#include <hidef.h> /* for EnableInterrupts macro */#include "derivative.h" /* include peripheral declarations */#define RX_BUF_SIZE 16#define RX_TOP_THRESH 14#define RX_BOT_THRESH 2void init(void);void rxISR(void);unsigned char rxBuffer[RX_BUF_SIZE]; // receive bufferunsigned char rx_read_index, rx_write_index; // read & write indexesunsigned char rx_buff_rem = RX_BUF_SIZE; // free buffer remainingunsigned char xon_xoff; // xon/xoff statusvoid main(void) { init(); EnableInterrupts; while (1) { __RESET_WATCHDOG(); asm wait; }}void init() { SCC1 = 0x40; // enable SCI SCC2 = 0x2C; // enable rx, tx, rx int SCBR = 0x03; // set BAUD}#pragma TRAP_PROCvoid rxISR() { SCS1; // dummy read SCRF flag to clear rxBuffer[rx_write_index++] = SCDR; // write incoming byte to buffer rx_buff_rem--; // decrement buffer remaining if (rx_write_index == RX_BUF_SIZE) // if end of buffer is reached rx_write_index = 0; // then start at beginning if (rx_buff_rem == RX_BOT_THRESH) { // if buffer size reaches xoff threshold while((SCS1 & 0x80) == 0x00); // wait for Tx ready SCDR = 0x13; // send XOFF signal }}And here is the disassembled HC08 code for the ISR: (KX8)
0000 8b [2] PSHH 34: SCS1; // dummy read SCRF flag to clear 0001 b600 [3] LDA _SCS1 35: rxBuffer[rx_write_index++] = SCDR; // write incoming byte to buffer 0003 be00 [3] LDX rx_write_index 0005 b600 [3] LDA _SCDR 0007 8c [1] CLRH 0008 e700 [3] STA @rxBuffer,X 000a 5c [1] INCX 000b bf00 [3] STX rx_write_index 36: rx_buff_rem--; // decrement buffer remaining 000d 3a00 [4] DEC rx_buff_rem 37: if (rx_write_index == RX_BUF_SIZE) // if end of buffer is reached 000f a310 [2] CPX #16 0011 2602 [3] BNE L15 ;abs = 0015 38: rx_write_index = 0; // then start at beginning 0013 3f00 [3] CLR rx_write_index 0015 [5] L15: 39: if (rx_buff_rem == RX_BOT_THRESH) { // if buffer size reaches xoff threshold 0015 b600 [3] LDA rx_buff_rem 0017 a102 [2] CMP #2 0019 2606 [3] BNE L21 ;abs = 0021 001b [5] L1B: 40: while((SCS1 & 0x80) == 0x00); // wait for Tx ready 001b 0f00fd [5] BRCLR 7,_SCS1,L1B ;abs = 001b 41: SCDR = 0x13; // send XOFF signal 001e 6e1300 [4] MOV #19,_SCDR 0021 [5] L21: 42: } 43: } 0021 8a [2] PULH 0022 80 [7] RTI I wouldn't call myself an HC08 assembly expert, but this looks pretty good to me. I count 35 bytes, and in the most common case there will be 57 CPU cycles (counting the 16 interrupt overhead cycles - so really 41 cycles).
I'm now expecting a severe lashing from the Freescale community. 
rhinoceroshead wrote:. . . He said C compilers used to be written very poorly but nowadays even the best assembly programmers can rarely beat them because the compilers have gotten so good.
Well here is an important reason why that is incorrect or at least misleading. The purpose of C (or other high level languages) is so that you can define the general process flow quickly, according to how C definition intended it. It tends to take away special low level capability of the individual CPU, or other process flow that was not compatible with C. Many are sort of brainwashed into thinking only "like C", and don't realize what kind of power they give up by choosing C for their app. Or next they write special "C" which is not fully C because it adds syntaxt to control special features. More to learn, more complication.
Typically the assembly programmer is capable of rewriting the application taking advantage of low-level, i.e.
- carry and overflow bits other than in typical mathematics
- incompatible program flow such as special composition of conditional code
- special handling and starting of a relocatable function, such as copying to RAM and executing on the stack
They are probably not doing so because they don't see that the added benefit would outweigh the cost of developing the whole app twice (I agree). Then the questions to ask,
- Did it really cost less building with C limitations than if it were built only in Asm by someone familiar with Asm applications?
- Has the developer selected a more expensive part (overkill) just to ensure room to program in C, increasing the cost of every copy of the softare sold?
I've been wondering in the last few posts which one you were arguing for: C, or Asm. I had forgot to add the third option, "or just CodeWarrior"
I think it's pretty clear now that you are saying "pay them what it takes and rely on CW". We as a society are good at creating "Microsoft-like" companies.Really, I'm not trying to attack any one C compiler (that was not the subject)... however, note that it is no excuse for GCC to not improve optimization just because it is geared toward implementing a major OS on the target MCU. More so, this makes optimization more necessary. So I think the problem there is that the optimizations are just not done. Who to trust, and for what?
