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>
Collin J. Doering