I have been working on 4x40 support, however right now it is not practical. I have been using built in LCD support from my compiler, from my first look I dont think it is possible to use this on a 4x40 since there is two controllers in a 4x40. I do not have time right now to develop my own LCD routines to write to a 4x40. I think I could use two PICs (since you have 2) to make it work. I will have to look into this further, hopefully its not a dead end either.
Remember that the 40x4 that I told you, is for a parallel connection (0x378), not serial! Do you remember that draw that you sent to me? If my LCD supports serial connections, it´s perfect!
This transmitters and receivers, I made a little test... and works perfectly!! My test is with a MC145026 and 27, if the led valid transmit is on... it´s ok!
That's a rather good point: doing a wireless transmitter basically requires a serial connection. So if you want to use a normally parallel module, you'll have to have the PIC or AVR converter between the LCD and your FM receiver.
In your case J, doing 40x4 will definitely take some work, since it requires writing your own routines. However, the actual difference between these two sets of routines will be minimal.
Since mine is already written from scratch, the only thing that needs to be done is to perform the initialization routines with both enable lines high (since we never check the busy, this is okay to do). Then you just need to change your go_to_position routine to toggle which enable line is being used (a global boolean) depending on which line you go to.
Of course, this has its limitations, such as not working properly if a write runs off of one line onto the next, but then again this never works properly anyway with the HD44780. That's why, as part of the Matrix Orbital emulation, I have global variables keeping track of the line and column that the cursor is at, so that auto-wrap and auto-scroll can be implemented. Then the previously-mentioned change will always work, since every write will call go_to_position if a wrap is necessary.
Hopefully that gives you an idea of what you'll need to change in order to implement it. Once you write the routine to handle writing a single byte to the LCD, the rest is very simple. One hint: make some sort of write_byte command that takes two arguments; the values for the control pins and the values for the data pins. Write a seperate routine for checking the busy flag, since there are times (like during initialization) where we don't want to check the busy flag.
Actually, as far as using my routines it can be done fairly simply. I would have to use a bit of external hardware on the pic though, it would toggle the enables lines back and forth depending on what LCD I want to write too. I have seen this done with one 7408 and one 7404 logic ICs.
I am not quite sure what you what you mean by parallel? You want to be able to hook this up to the parallel port? Or you mean that your LCD is parallel?
I used a demux IC to toggle between the different controllers. I can say right now is that it works somewhat. It will display a few screens fine then it just goes blank. I will be working on it more. I think it is just a matter of rewriting some of the LCD functions. I would assume that the functions are completely different since it is a two controller lcd, namely the home function.
By the parallel/serial thing, yes, I meant that a regular LCD has a parallel (4/8-bit) interface, as opposed to something like a Matrix Orbital which is serial. Obviously you can just feed serial as-is into the modulator/demodulator and expect it to work, whereas it's basically impossible to do that with a parallel connection.
For some reason it never occured to me that you could just edit the routines that your compiler provides to you. Typical mistake of mine: always reinventing the wheel.
However, I am curious about your use of external logic to use the 40x4 display. The way I was planning to do it, you would need no external logic other than an extra pin for the enable line on the second display. Otherwise all of the control and data lines would be shared between both modules. The only logic that would be required would be in software, and this would be very minimal. As I mentioned, this would consist of sending some commands (like initialization or custom characters) to both controllers, while sending other commands (like writing a character, or moving to a position) to both controllers. Also, the only time you would have to change which controller you were writing to is when a command was used that moved the cursor (like home, or set DDRAM address), but it would be obvious which one should receive the command, since moving to a different line always requires a call to set DDRAM address (because of the 1-3-2-4 line addressing). Hopefully that makes sense. When I get a chance to work on mo-avr some more, you'll get a chance to see what I mean.
Rev, it seems to work, however I noticed some characters would be placed on the wrong part of the line. It is very buggy, but I think it will work. As a work around right now the demux is my best option. I think it would take too much time right now to rewrite LCD routines (at least more time than I have). I still am only using two lines, one enable and one select.
I will work on this some more tonight. I havent quite pinned down the erratic behavior with the 4x40. I believe it is something to do with switching back and forth between the LCD and certain commands. Writing new lcd routines may be the only way to do it (hopefully not).
The 4x40 is not cooperating. I got it to display 2 screens back and forth. Sometimes a few characters will be garbled but smartie fixes it quickly when it updates the screen. I figured out that with a 20MHz crystal it barely wants to work. With a 4MHz crystal it is a lot better. This leads me to believe that there is a high propagation delay to the Demux I am using.
I will work on it some more but the more I do the more I think the LCD routines need an overhaul for 4x40 use. I am trying to avoid this but I dont want to spend alot of time on not rewriting them either.
I am going to go back to working on the 40 pin bootloaded chip. It is coming along nicely and I should have a new version available very soon. It supports pretty much everything EXCEPT 4x40.
Do you remember that draw that you sent to me? If my LCD supports serial connections, it´s perfect!
