AXE133 ported to 14M2 using hardware UART needs no delay between chars upto 4800 baud

[Flenser]

EDIT (2/5/2017): Updated version 3.0 of this code capable of operating at 9600 baud is available from post #2
EDIT (3/5/2017): Replaced the circuit attachment. The original circuit had a mistake, pin 1 was not connected directly to the 5V supply

I have ported the RevEd AXE133 code to the 14M2 by using the 4-bit interface to the LCD.

I have also modified it to use the hardware UART instead of the SERIN software serial command. Running at 32MHz a serial backpack using this code can keep up with serial commands sent at 4800 baud. It does not need a delay between each character sent, as the code using SERIN does.

There is one exception. The message function (253,x) writes 16 characters to the LCD and the sending program must delay after sending a message command or some transmitted bytes will be lost. My 4-bit AXE133 code takes around 1.07ms to process each character so the sending program should delay at least 19.8ms. (2.2ms for processing the "253,x" command and 17.6ms for processing the 16 characters in the message).

[Flenser]

This is an update of my code with performance improvements.

Running at 32MHz a serial backpack using this code can keep up with serial commands sent at 9600 baud. It does not need a delay between each character sent, as the code using SERIN does.

The exception for message function (253,x) still applies, as it did for the original version.

[hippy]

#MACRO GET_CHAR(label, bytevar1)
label:
	peeksfr PIR1, TEMP_BYTE_B0
	if TEMP_BYTE_B0.5=0 then goto label
	peeksfr RCREG, bytevar1
#ENDMACRO

Untested on actual hardware, buy you should be able to optimise that to save having to specify a unique 'label' for each usage with ...

#MACRO GET_CHAR(bytevar1)
	Do
	   peeksfr PIR1, TEMP_BYTE_B0
	Loop While TEMP_BYTE_B0.5=0
	peeksfr RCREG, bytevar1
#ENDMACRO

You would have to time it but you could possibly improve the speed of your ...

#MACRO LCD_OUTPUT(bytevar1)
	pinsB = bytevar1 / 4 | %000001
	low LCD_ENABLE	
	pinsB = bytevar1 * 4 | %000001
	low LCD_ENABLE
#ENDMACRO

With ...

#MACRO LCD_OUTPUT(bytevar1)
  TEMP_BYTE_B0 = bytevar1 & $F0
  ReadTable TEMP_BYTE_B0, pinsB
  low LCD_ENABLE
  TEMP_BYTE_B0 = bytevar1 & $0F
  ReadTable TEMP_BYTE_B0, pinsB
  low LCD_ENABLE
#ENDMACRO

Table $00, ( %000001 )
Table $01, ( %000101 )
Table $02, ( %001001 )
      etc
Table $0F, ( %111101 )
Table $10, ( %000101 )
Table $20, ( %001001 )
      etc
Table $F0, ( %111101 )

[Flenser]

Hippy,

Thanks for the two suggestions, both will be useful.

The timings I measured using the do-loop measure exactly the same as the if-goto coding for both the test = true and test = false cases so I can simplify my macro by removing the label parameter.

The readtable suggestion is also useful and I can use it to save a significant amount of time.

My original code:

pinsB = b0 / 4 | %000001		186.5 uS
pinsB = b0 * 4 | %000001		163.5 uS
Total					350 uS

Using readtable as you suggested loses out against the efficiency of being able to code multiple arithmetic & logical operations in a single statement:

b1 = b0 & $F0, ReadTable b1, pinsB	198.5 uS
b1 = b0 & $0F, ReadTable b1, pinsB	193.5 uS
Total					392 uS

However, once you got me thinking of how I might use readtable, I realized I could pre-calculate all the possible portB bit-patterns for one of the nibbles and my code would need just one readtable statement to output that nibble.
Choosing the high nibble, because the division is slower than the multiplication, I get a massive saving of 111 uS:

ReadTable b0, pinsB			75.5 uS
pinsB = b0 * 4 | %000001		163.5 uS
Total					239 uS

Table $00, ( %000001, %000101, %001001, %001101, %010001, %010101, %011001, %011101 )
Table $08, ( %100001, %100101, %101001, %101101, %110001, %110101, %111001, %111101 )
...
Table $F0, ( %000001, %000101, %001001, %001101, %010001, %010101, %011001, %011101 )
Table $F8, ( %100001, %100101, %101001, %101101, %110001, %110101, %111001, %111101 )