Word Processing Program

Hello everyone,

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!

-Chris

GitHub Repo:

https://github.com/cgpurbaugh/ARDOWRITER

What Arduino are you using?

With 2k of SRAM on an Uno there is not much room for wordprocessing.

…R

Robin2:
What Arduino are you using?

With 2k of SRAM on an Uno there is not much room for wordprocessing.

...R

It's a Mega 2560 R3

Even 8k is not a lot, when you’ve got program variables as well as text.

You are bound to learn a great deal!

jremington:
You are bound to learn a great deal!

LOL

...R

So, I've been able to get the program working somewhat. It will open a file, you can write to it, and it saves as you write.

I've not yet added the ability to create multiple files, but I doubt that will be too difficult.

 if (cursorVertical = 1) {

Ooops.

Pete

el_supremo:

 if (cursorVertical = 1) {

Ooops.

Pete

What’s the oops?

if (cursorVertical = 1) {Assign ('=') vs compare ('==')

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.

AWOL:
Even 8k is not a lot, when you’ve got program variables as well as text.

1985: ‘QuickBrownFox’ for Vic-20

6502 processor, 1 MHz, 8K ram, program on ROM cartridge. Arduino beats this by a lot!

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 ('==')

I see. Thanks!

ChrisTenone:
1985: 'QuickBrownFox' for Vic-20

6502 processor, 1 MHz, 8K ram, program on ROM cartridge. Arduino beats this by a lot!

I ran HES Forth79 on my VIC20. I was able to write Forth words that WROTE Forth words on that VIC!

As far as Mega2560 RAM limits.... 512K external RAM giving 8 banks of 56K heap space, just under $30.

cintar:
Keep in mind that I've never written in C before, so parts of this may be done inproperly.

So you wrote a lot of code in a language you don't know to run on hardware you don't know and expect it's not going to be hard to fix?

You should get to know both before laying out your design and then work that up a part at a time, debugging all the way.

If you want to make a decent text editor you will need to write for better terminals than Serial Monitor though it's enough for EDLIN or VI.

GoForSmoke:
So you wrote a lot of code in a language you don't know to run on hardware you don't know and expect it's not going to be hard to fix?

You should get to know both before laying out your design and then work that up a part at a time, debugging all the way.

If you want to make a decent text editor you will need to write for better terminals than Serial Monitor though it's enough for EDLIN or VI.

The purpose of the program is to learn the language and hardware. So far I think it's working.

If the purpose is to learn language and hardware, surely there are more interesting and actually useful programs you could write.

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.

A tricky and Quite Interesting challenge!

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?

Honestly, didn’t think about that, but it still creates issues around text fragmentation and keeping the whole buffer in sync with the SD pages.

Good point tho’