Go Down

Topic: KS0108 GLCD on I2C (Read 16081 times) previous topic - next topic


Hi again.
I have start to coding slave and see something missing in Special chars function... It has only '\n' support. How about to add '\b' and '\r' chars?
'\b'ackspace and carriage '\r'eturn are useful chars if you counting something and it's better/speedy than using some high level functions.
Wait a minute I can't see '\t'ab character support also  :o

I skipping functions that require PGM_P ( like Puts_P ) since we don't have such strings in slave device program memory. But we needed to support them in master device. Right? Is PGM_P str is compatible with char* ? Or do I needed to convert it? I don't play them before. I wish I could convert them easily when I writing masters code.

SelectFont functions make me thinking... I use enumerations for selecting fonts that stored locally and see that there is no memory for including all fonts 16796 bytes but 14336 allowed!).
If we remove arduino bootloader from slave (arduino don't required for such a device I think) We got some bytes > 1K.  And removal of heartbeat function (I usually wanted to have heartbeat on MCUs. :) ) and serial library, It's fits in the device. But I don't implement drawbitmap function also. Might be use function pointers to get some space also, But  we needed to remove some of the fonts again i think. Also serial library or OneWire (that I wanted to see it) will require more bytes.
So atmega328 chip is required for including everything, but we needed to remove some fonts from atmega168 targets. Which fonts are we will crop by default? Which ones are used mostly?(I don't know really) I will place font header includes to top of slave code so user could uncomment which one they needed to use. But I want to hear font list from you that from important to petty one...

Could we transfer new fonts from master to slave RAM before using? On atmega168, there is no RAM such fonts like Arial14.(Currently 711 bytes available on) And storing fontset to flash on demand will degrade flash on MCU with time or with missuses... If we use atmega328, it's ram is could used such a purpose but we could also store all fonts into flash! :D

I don't know how could we handle gText things!!! I import DrawArea functions to slave. But I think we needed to create some instances of gText on slave to play with it, right? What do you think about it?

Also DrawBitmap function make me thinking. Because wire library code allows you up to 32 byte to transmit continuously.  If you send 33.rd one, It will discarded. I needed to divide data to 32 bytes before send and needed to write it to screen directly since there is not enough RAM for frame buffer. Also images are stored in the PGM data. I think I needed to rewrite DrawBitmap code for the master and the slave. I think it will be fun to code DrawBitmap :)

What do you think about those functions and do you have some advice about implementations of them?


Started Master's code. Handled all other problems but gText.
Currently I see 13.79 fps on 20Mhz slave device for GLCDdemo drawings from master :) which is good enough...

I am not sure how to handle gText commands and definitions. There is no problems if users doesn't create another instance of gText. But users could also define gText area in their programs. Not sure about how to handle this...

I wanted to have transparent library layer for glcd. If user wanted to port it's code to serial library, just change of library name and addition of device address is needed to enough for the port.


I would not bother supporting user created gText classes on the master. You can support the vast majority of applications by creating a few instances on the slave. Have a look at the GLCDDemo sketch in the beta download to see how you can create and access an array of text areas.

An existing sketch that creates gText instances would configure an existing instance on the slave (using the modify method) instead of creating a new instance.

The glcdDemo would be a good test harness for the API. It uses four user created gText instances


Sep 02, 2010, 03:56 am Last Edit: Sep 02, 2010, 11:03 am by E.U.A.. Reason: 1
I know but problem is identifying which gText object used by user at master device. You cannot know which object used it with only function name... So you needed to send gText object ID to slave on every text related command... Now I created gTextcmd class and moved text related function to it from GLCDcmd class. This will handle text related functions and will add a ID to each object that I create at master. On slave, I can create and remove gText objects on the fly with this ID. This requires change on some of Text commands structure...  :-/ I am happy since there is no documentation to change :)
I also don't work on return from slave device. So functions that require return don't implemented yet. I wish competed the job on weekend. :D

Edit: It looks like Arduino doesn't support new and delete command. :( Couldn't I create new class instance with code? I looks like I needed to define them at beginning. Seven of them is enough for everyone I guess...

Edit2: New problem. When defining new gText areas, we cannot send messages to slave device via Wire interface to tell gText object created.  There is no problem if you make definitions in loop function. But you cannot define gText's before setup as I understand...

It's not problem if we don't have initialization arguments, since we don't needed to tell slave device to create one(since 6 of them created already). But some of gText constructors has parameters. They must be set also... I don't understand why Wire interface doesn't sent the messages. Is it because "setup" function not called yet? But Serial library works here!
I also called Wire.begin() from Constructor function of gTextcmd but master device emits nothing.  >:(

I inspected deeply and detected that Wire.endTransmission() function does not returning... Any idea to fix this or work around?

Edit 3: I used work around to fix problem. Just storing constructor commands of gText's on preSend buffer if GLCD not initialized. When GLCD initializing, I send this commands from buffer to slave. So it looks working now. I don't run whole GLCD demo, just pieces of it. But will test more pieces of it...

Edit 4:I put some other test. And see that just textArea gives errors I don't know why. There is some bad code, I don't implement << and printf's on correct way. Just convert them to the "puts" commands. Try to understand how could I put << and printf support to my derived class... Any help will be appreciated.


Hi, can you talk about how can I handle "print" and "<<" stuff? Every other things looks working properly now (I needed to implement funtions return values also but I think it's easy part...) and I wanted to complete this sub-project. "BigDemo" shows correctly except prints and "<<". GLCDDiags fails because it requires low level things like chip selection.I assume users will not require such functions. :).

I think it's not good way to handle "prints" within multiple overload of "print" and "println" function on gTextcmd class. I also look end of gText.cpp file but I don't understand... Could you help? Thanks


The Arduino style print functions are derived from the Arduino print class that is inherited by gText from the glcd_Device class.

So you need to look at the print class in the Arduino core directory to see the actual print functionality.
gText only implements the write method to output a character, the real work is inherited from the print class. Implementing this across an API is tricky because gText does relay on accessing a single instance of the x and y coordinate values and these are in the glcd_Device class. One approach could be to create an API version of glcd_Device that has the i2c code instead of the actual hardware interface. Unfortunately, I have a book deadline that will be absorbing all my time for the next few weeks so won't have any spare bandwidth to be of much help.


Sep 04, 2010, 01:39 pm Last Edit: Sep 04, 2010, 04:03 pm by E.U.A.. Reason: 1
Oh thanks for pointing arduinos Print class. I look deeper and see that glcd_Device already uses it. So I add inherited Print class to gTextcmd directly and overwrite the write(c) function as PutChar(c) does the job well, cleans the code fix some other issues :)
Now just ">>", stream support and return values of some functions are missing now. And after library is ready for heavy test from the public :) Thanks for supports.    8-)

Completed. Just cleaning code. :)


I released the sources at this thread.

Thanks for help. :)

Go Up