Use pre-processor macros to allow for simple entry of ANSI escape
sequences.
Many escape sequences don't require all characters in all cases.
Example: Cursor movement (up down, forward and back) all take one
parameter (natural number) that defaults to 1, and can be omitted in
this case. Calling the associated macros with 1 will generate the
correct escape but not the smallest one. Now for these single argument
cases (there are others also) the macro of choice can be used with an
empty argument which will generate the smallest ANSI escape sequence.
Eg, the following are equivalent: CUD() === CUD(1)
Another example is use of CUP (cursor position). It takes two arguments
which both default to 1. Similarly to the CUD example above, CUP(1,1)
generates a valid ANSI escape sequence, just not the smallest one. The
smallest one can be achieved by omitting the arguments to CUP: CUP(,).
For more information on ANSI escapes see wikipedia:
https://en.wikipedia.org/wiki/ANSI_escape_code
This is just an initial proof of concept and is not complete;
namely:
- Not all ANSI escapes are implemented
- Macros don't error check for the user; that is, invalid escapes can be
generated (Eg. the argument to ED is constrained to 0, 1, or 2 but
this is not checked by the ED macro)
- Macro's can generate invalid ANSI escapes when the argument that's
given is not a natural number (specified as ASCII)
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Working for clear screen, Backspace, and newline. Still needs to be
implemented to match the columns and rows of the LCD (which will require
that lcdLib.c provide access to currentLineChars and currentLineNum via
functions like getCurrentRow and getCurrentColumn.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Before this commit the cursor would be incremented (automatically by
hardware) after printing the last character on the line, which would
leave it the next line in memory, which doesn't necessarily correspond
to the next physical line on the display. This would be corrected when
the next character is received but is incorrect behavior; the cursor
should always be at where the next character is to inserted. This was
due to an off-by-one logical error. This commit solves this bug.
Along with the bug fix, keycodes from the serial terminal are now
deciphered correctly and the corresponding key or keys are sent to the
LCD accordingly.
Further work is required with regards to updating the serial
console (the connected client) so that their serial console looks
exactly like the LCD they are connected to.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Move code that checked for escapes from the writeStringToLCD function to
the writeCharToLCD function.
Note: There seems to be an issue connecting to USART when the programmer
is not connected. This is likely a wiring issue related to ISP.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
The writeStringtoLCD function now wraps text correctly and proceeds to
the next line when '\n' is reached in its argument.
Note: during debugging of this feature it was noticed that the function
loop_until_LCD_BF_clear is broken, as previously suspected. This forces
delays to be placed in the clearDisplay and returnHome functions and
could cause other undefined behavior if timing requirements aren't met.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Collin J. Doering