I have a project where one arduino pro-mini, lets call him master, is reading info from a sensor via I2C,
then sending that data out to a NRF24 radio.
Then promini #2, lets call him Fred, has the companion NRF24 radio, he gets the data packets and then writes the data in people readable form to a 1306 OLED.
So master pro-mini has the wire library and the NRF24 library, works great.
But Fred is another issue. I am recieving the data just fine, and can read it out over a serial com port.
The above combo works like a champ if i use the Adafruit OLED library, however when i tried to port the code over to use the U8glib library, it is giving strange results.
The radio still works fine, however the display is not happy. I'll try to describe what is happening, here is the "draw" command i am sending the display:
void draw(void) {
u8g.setFont(u8g_font_gdr30n); //u8g.setFont(u8g_font_unifont);
u8g.setPrintPos(0,29);
u8g.print(DATA);
then i just call this with the
do {
draw();
} while( u8g.nextPage() );
command in my loop() after the radio had collected the "DATA"
The DATA is getting to the OLED, however its as if something is going wrong with the "u8g.setPrintPos(0,29);" command, it first draws the data where it should, but on the next write it draws it again only down a few pixels. this continues on so what i end up with is the data scrolling down the oled and overwriting itself several times before the display will clear and the process starts over again. As if somehow the first argument of the "setPrintPos(x,x)" ( in my case "0") is getting values other than "0".
anyone else seen this issue?
As i said the adafruit lib works great, so i am thinking that it may have something to do with the fact that the adafruit lib uses a SW SPI, where the U8Glib lib is using the hardware SPI (and sharing it with the NRF24 module) .
If i run any of the U8Glib examples by themselves it works great, so i doubt its a hardware issue.
Some of the things i have tried:
-moved the"setPrintPos(x,x)" command to the setup() routine... no good
-bootstrap forced the CS pin of the OLED high and low (digital write) in the loop..... no good
-put delays in everywhere ........no good
-stopped and restarted the SPI in various places in the loop ........no good
- moved the "do draw{" command before, after and in the middle of the radio.read command ...no good
-held my tongue "right" 42 times....no good
any help is greatly appreciated.
I am going to try and write up a small simple sketch to post so maybe the gurus can look at it...