There are a few things that still need to be commented, furthermore,
usage of the library needs to be explained in more detail. Also things
are still somewhat unorganized as the lcdLib library is packaged up with
the lcdOutput application for testing. Also a tiny USART library is
included but has nothing to do with the lcdLib except that its used by
the lcdOutput demo program. When the lcdLib library is ready it will be
split into its own repository with accompanying examples (one of which
may be the USART echo example (lcdOutput.c as of this commit).
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
At some point perhaps switch to using doxygen to output nice
documentation. This will require using doxygen conventions, which aren't
currently used but easily adapted to.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
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>
After changing the transmitBytes function and renaming it, missed
changing the function definition in the header file to match the new declaration.
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>
Removed the repeated #defines for LCD_DBUS*[,_PORT,_DDR,_PIN] used for
both FOUR_BIT_MODE and EIGHT_BIT_ARBITRARY_PIN_MODE.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
After trying FOUR_BIT_MODE to ensure it worked properly, forgot to
comment it out so that the default mode is enabled as expected and
documented.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
Tested mode 1 (default 8-bit mode), and mode 2 (8-bit mode with
arbitrary pins for the data lines).
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
1. Default mode (8-bit data bus, control lines on any PINs)
2. 8-bit arbitrary pin mode (8-bit data bus on any PIN, control lines on
any PINs)
3. 4-bit mode (4-bit data bus, control lines on any PINs)
Default mode is tested and working. The others still require testing.
Signed-off-by: Collin J. Doering <collin.doering@rekahsoft.ca>
