I got my first Arduino last week and have come up with the project of creating a word processor. I've created a github repo to host the code. Keep in mind that I've never written in C before, so parts of this may be done inproperly. I actually haven't tested this version of the code yet, I have to wait until this evening, however the compiler didn't show any errors. (GitHub link at end of post)
I will post photos of the current (very rudimentary) setup this evening.
If anyone has any advice, I'm looking forward to hearing it. I hope to be an active and helpful member of this forum as I gain experience here. Thanks!
From a casual glance at the code, it appears that the "delete key" function overwrites the previously typed character on the LCD display with a blank, but doesn't actually delete the last character input. It had already been output to the SD card, so an actual delete action is no longer possible.
To delete input characters before committing to output requires at least a line buffer.
jremington:
From a casual glance at the code, it appears that the "delete key" function overwrites the previously typed character on the LCD display with a blank, but doesn't actually delete the last character input. It had already been output to the SD card, so an actual delete action is no longer possible.
To delete input characters before committing to output requires at least a line buffer.
Good point, thanks!
AWOL: if (cursorVertical = 1) {Assign ('=') vs compare ('==')
OP, I like your thinking...
As a learning experience this has a lot of traps & hidden gotchas - will make you think! and certainly learn!
Since you’re on the way now, apart from the potentially complex UI issues, you must consider how you’re using RAM as Robin2 commented.
The SD card is a good idea too, but relatively clunky for a non-linear process like WP.
Perhaps implement a RAM buffer that acts as a ‘window’ into the SD, and only update those ‘differences’ when you move. Although that could be tricky if the contents don’t always match the window size...
Or, maybe a scratch buffer that maintains chunks of text, and a pointer for each chunk to it’s position within the SD file. Only when the buffer is flushed would the SD contents be reconciled ? Also tricky, but relatively logical to cleanup the target file before the scratch buffer fills up.
lastchancename:
Perhaps implement a RAM buffer that acts as a ‘window’ into the SD, and only update those ‘differences’ when you move. Although that could be tricky if the contents don’t always match the window size...
SD library already has and uses a buffer, default size 512 bytes. Why not use that unless you don't know it's there?