bkubicek / Marlin

Reprap FW optimized for gen6
17 stars 1 forks source link

LCD interrupt driven library. #3

Open bkubicek opened 13 years ago

bkubicek commented 13 years ago

For Sprinter/Merlin, an improved LCD library would be very needed. The user would call a printing routine, and this routine writes in a n*m char buffer, and then transmit using a timer interrupt to the lcd in 4-bit mode. It were very easy, if in the timer interrupt a delay could be used for the lcd-enable pin toggling. However, this delay could cause lost steps in the motor controlling. A LCD update rate of 2-3 times per second would be sufficent, maximum display size is probably 4x20.

If somebody of you wants to test his arduino skills and creates such a library, I would offer a LCD/SD/button beta unit as a return, as soon as my CNC mill works again.

I know there exists a similar library somewhere hidden in the nets yet, but the code was extremly complicated and not useful for this purpose IIRC.

bradleyf commented 13 years ago

I'm experimenting with two different optimized LCD libraries, mostly to get the "Tiny LCD" functions working properly. Current LCD libraries introduce too much delay, which causes tiny stepper pauses and serial comm delays

jundery commented 13 years ago

Last night I started playing with some new code for this too. It doesn't look entirely like the existing libraries I've seen, I am trying to use a double buffer so the user writes a screenful of data that the interrupt routine writes that while the user can write to the second buffer.

This code has the disadvantage of needing the user to lock, release the buffer and write an entire screenful, but the ISR is a trivial pin setting routine with no delay. Each time it is called it toggles the enable pin, every other time it sets 4 data pins and finally at the end of the screen it sets up to use the next buffer when it is ready (picking it up immediately if it is or going to a state where the ISR just return). The ISR only has to synchronize with a minimal part of the users lock and release buffer routines (and it does this by the ISR "skipping" a call,) all the actual print functionality is independent of the ISR due to the double buffering.

bradleyf commented 13 years ago

Jundery: That sounds like the leading horse for this. I tried to find something today, but am going to have to give up on this particular issue. Looking forward to seeing your solution.

jundery commented 13 years ago

I got this code running, I'd like to test some more this evening but then I should submit a pull request (once I've read up on git some more).

jundery commented 13 years ago

I've looked at the Marlin LCD and as I don't have a LCD on my Ultimaker to test with I am not going to attempt a merge but I dropped the code at https://github.com/jundery/InterruptLcd if you want a look.

bradleyf commented 13 years ago

Jundery: This looks really nice. I adjusted the pin settings for UM motherboard and it works well on the 16x2 lcd I have.

I think it's worth a try integrating into Marlin -- I'd get started on it, but in Bernhard's last commit, he reversed all the changes I made to make his lcd code to make it more generic and less specific to his proprietary console. So I'll let him chime in first on merging it in.

bkubicek commented 13 years ago

this was not really on purpose, I must have overlooked it in the difs. If is was in configure.h, my git was confused, because the line end mode changed to windows, and so evey line was marked as changed. I will try to get it into again. To make it work, I will try to create an LiquidCrystalInterrupt object, that has mostly the same calls as the arduino library, so compatibility is maximized.

jundery commented 13 years ago

I just pushed a fix for a dumb bug where if the updates were fast I wasn't releasing a "critical section".

bradleyf commented 13 years ago

B: I understand. I'll make changes, if necessary, after your next commit. I'll try to make sure my editor doesn't flip the line endings. I just ordered a 20x4 LCD to upgrade my 16x2.