An LCD is important for a microchip controlled preamp. Ok, it is possible to control the preamp without one, but knowing the current volume level, cutting/boosting channel levels, switching inputs, switching surround modes all becomes a bit more difficult. All good systems have an LCD anyway!
The LCD I choose wasn't that easy to program, especially as I only intended ever to use text on it. However this is a graphic display Vikay VK5121 LCD module with 32x120 dots. Writing ASCII text codes to it won't work!
I must admit, I needed help with this and after deep searching I found this link. It is exactly what I need to get the features of this LCD up and running - except I would need to convert from the CCS PIC C compiler syntax to the C2C PIC C compiler syntax - as they are not the same!
For completeness, I have the converted source code for the C2C compiler, see lcd.c and lcd.h.
Many thanks to the author for providing this - otherwise I might of had to get some new LCDs!
I added some extra functions, and changed a few things too.
Firstly, my version stretches the text... this is so it is easier to read (like a bold format), but halves the amount of text you are able to fit on the LCD line.
If you don't like this, change the following.
for (x=0; x<10; x++) to change to for (x=0; x<5; x++)
char_row = x/2; to change to char_row = x;
That will restore it back to the original configuration.
I also added lcdString() which allows a C string to be sent to the LCD, and lcdLine() which goes to an LCD line (0-3), deletes it ready for writing new text.
RS232 communication was initially going to be used solely for communication with a PC, however as the project progressed, this form of communication was going to provide a second role (or a main role I suppose!).
This role was the basis of communication between the two microprocessors that were actually used in the first completion of the final product.
Yes, as I went through the stages of the build, it actually became pretty obvious that the amount of functions were not only going to exceed the limitation of a PIC16F874 microchip (which was 4K), but also going to exceed that of a PIC16F877 microchip (8K)!
This hit the upper limit since my choice of programming language wouldn't support an newer versions.
The only way to go was... parallel computing! I purchased a second PIC16F87 (since the EEPROM wasn't needed for both PICs) and split my code into inputs and outputs, with the processing kind of split based on how much program memory each section of code was using.
The same RS232 commands that PIC 'one' (the input and generally master PIC) was designed to send to a PC, it also sent to PIC2. This included the current state of the output relays, and volume, and any text to send to the LCD.
This worked quite well, but occasionally the program would crash if volume changes happened too fast. This was found to be caused by PIC one sending out byte commands before PIC two had finished processing the previous commands. PIC two would then only get a fraction of the command, and lock up.
I could have wrote more clever code to deal with 'rubbish' half commands, but I thought the neater solution would be to have a single wire link between PIC two and one which would signal PIC 2 is ready for more commands.
The code on PIC one would wait until PIC 2 would respond before sending out more commands.
Bingo, no more lock ups!
Whilst not an elegant solution and one I would like to aviod in any rebuild, it did work, and since this was part of a university project too, I had a deadline to meet and I couldn't u-turn on my plans to use the C compiler, and start using assembler.
Anyhow, RS232 communication did prove a little tricky - but fortunately there was source code examples on the C2C site which gave me a good head start into finishing a working example.
It doesn't stop there though - I had to write a program on the PC to send and receive the same byte codes down the RS232 link. Again, pretty tricky, especially since my language of choice (java J2SE) had no native support for serial/parallel port comms.
I got a good enough result in the end though, but it was a little bit flawed and I won't feature it any further. There will be details upcoming of a rewrite using USB HID for the PC probably using a .NET language to look out for.