Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port U8glib to Raspberry Pi #171

Open
GoogleCodeExporter opened this issue Feb 27, 2016 · 52 comments
Open

Port U8glib to Raspberry Pi #171

GoogleCodeExporter opened this issue Feb 27, 2016 · 52 comments

Comments

@GoogleCodeExporter
Copy link

GPIO Programming: http://elinux.org/RPi_Low-level_peripherals

There seem to be two options:
Low level gpio programming (mmap/linux)

Other option would be to use this lib:
https://projects.drogon.net/raspberry-pi/wiringpi/


Original issue reported on code.google.com by [email protected] on 26 May 2013 at 5:52

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

U8glib runs well on the Raspberry Pi - well, I've only used it on the PCD8544 
but I don't see why any SPI type LCD display wouldn't work equally as well.  I 
ported it over so I could have some easy to use routines for a project that I'm 
working on.

For ease of porting I used wiringPi.  The question is, other people will find 
what I've done useful, but how could it be released?  I could send it on up to 
something like github, but it would be better to work with the find chaps that 
continuously work on U8glib to keep it updated.

Original comment by [email protected] on 2 Sep 2013 at 2:21

@GoogleCodeExporter
Copy link
Author

maybe you can attach your work to this issue. Once i find time, i can include 
it into the repository.

Original comment by [email protected] on 3 Sep 2013 at 11:16

@GoogleCodeExporter
Copy link
Author

How would you like it - a patch-set against a known release?

Original comment by [email protected] on 3 Sep 2013 at 3:28

@GoogleCodeExporter
Copy link
Author

patch set would be ok (against which version?)

Original comment by [email protected] on 3 Sep 2013 at 4:40

@GoogleCodeExporter
Copy link
Author


I've attached the files, an example file and a picture to show that it works.

Also, the instructions (below) are more detailed than I'm sure you'll need, but 
may help other people with this if they want to do it before you've released it.


You'll obviously need to install wiringPi on your RPi


$ wget https://u8glib.googlecode.com/files/u8glib_arduino_v1.13.zip
$ unzip u8glib_arduino_v1.13.zip
$ cd U8glib
And depending on where your patch is:
$ patch -p1 < ../rpi_u8glib.patch 
$ make

$ g++ U8gLogo.cpp -o U8gLogo -l wiringPi -l U8glib -I include -L .
$ sudo ./U8gLogo


I use this with M2tklib (https://code.google.com/p/m2tklib/ - also ported) to 
have nice menus.

Limitations:
1. It's hard coded to use CS0 for the SPI (as mentioned in U8gLogo.cpp).
2. I've only tested it with the PCD8554 LCD display.
3. There is an include directory with a couple of random header files from the 
Arduino camp which I've put in to make it compile.  I've not bothered to look 
into these more as as it stands the library does all I want it to do.
4. There is a printf tucked away I forgot to remove in a layer I wasn't sure 
what to do with.  

Any questions - please ask!

Original comment by [email protected] on 4 Sep 2013 at 8:19

Attachments:

@GoogleCodeExporter
Copy link
Author

Thanks for providing the patch. 

Original comment by [email protected] on 4 Sep 2013 at 8:28

@GoogleCodeExporter
Copy link
Author

Has this been added to the main code base yet? Or do I still need to download 
the patch and apply it separately?

Original comment by [email protected] on 3 Dec 2013 at 7:14

@GoogleCodeExporter
Copy link
Author

Unfortunately i still do not own a Raspberry Pi. So testing is not possible for 
me.

Original comment by [email protected] on 3 Dec 2013 at 7:37

@GoogleCodeExporter
Copy link
Author

olikr...: I'd like to buy you a Raspberry Pi so you can add official support 
for it :) Where do you live?

Original comment by [email protected] on 5 Dec 2013 at 3:05

@GoogleCodeExporter
Copy link
Author

It is not only that i do not own a Pi, but currently i do not have time to add 
support for a complete new system. Additionally my hope is, that the new "arm" 
release of u8glib can be ported easily to the Raspberry Pi.
Still you are free to contact me through e-mail (see source code)


Original comment by [email protected] on 5 Dec 2013 at 6:55

@GoogleCodeExporter
Copy link
Author

still pending...

Original comment by [email protected] on 22 Jan 2014 at 7:08

@GoogleCodeExporter
Copy link
Author

Hi I have a ST7920 12864 lcd, i followed your steps above but changed the 
constructor call in the .cpp from 

//U8GLIB_PCD8544 u8g(10, 3, 11);        // SPI Com: CS = 10, A0 = 3, Reset = 11

to 

U8GLIB_ST7920_128X64_1X u8g(13, 11, 10);    // SPI Com: SCK = en = 18, MOSI = rw = 
16, CS = di = 17

Unfortunately running the program does not display anything. Any comments?

Original comment by [email protected] on 3 May 2014 at 5:37

@GoogleCodeExporter
Copy link
Author

from my side, i did not yet worked on the pi, so i also do not know how to 
support here.

Original comment by [email protected] on 3 May 2014 at 8:54

@GoogleCodeExporter
Copy link
Author

hi, i am new to this and expirimenting with a OLED and Pi. I bought the 4-pin 
model. i am curious if it is possible to attach it direct to the Pi using 
u8glib ? Problem with this display is that i cannot get it to live, don't even 
know if it's broken, is there some method to test ?

Original comment by [email protected] on 30 Aug 2014 at 10:43

Attachments:

@GoogleCodeExporter
Copy link
Author

There is still no official support for the Pi. In fact, i do not own this 
hardware.

Original comment by [email protected] on 3 Sep 2014 at 7:31

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

@richardtepas: I am sorry for deleting your last comment. I can not validate 
the link and also the answer is very specific to one display type. Probably it 
is better to place the link on an Ras-Pi forum.

Original comment by [email protected] on 7 Sep 2014 at 1:00

@GoogleCodeExporter
Copy link
Author

@richardtepas:  It IS possible to get the 4-pin I2C OLED module to work with 
the Pi.  I had to do some additions and modifications but got it working.  I'll 
see what I can do to create a patch file(s) 

Original comment by [email protected] on 30 Sep 2014 at 4:18

Attachments:

@GoogleCodeExporter
Copy link
Author

that would be great! cannot see it exactly on the photo. how did you wire it up 
?
thanks a lot !

Original comment by [email protected] on 1 Oct 2014 at 7:25

@GoogleCodeExporter
Copy link
Author

这个可以驱动ks108吗?

Original comment by [email protected] on 1 Oct 2014 at 9:37

@GoogleCodeExporter
Copy link
Author

unfortunately my chinese is not as good as at was these days..............

Original comment by [email protected] on 2 Oct 2014 at 4:21

@GoogleCodeExporter
Copy link
Author

In that photo I had used external pull-ups.  But they aren't needed if you use 
the internal pull-ups for the RPi.  Since that photo I've wired it up directly 
using the following pins:

I2C Display   Raspberry Pi
--------------------------
VCC           1 
GND           9
SDA           3 (wiringPi Pin 8)
SCL           5 (wiringPi Pin 9)

Need to get a diff from the standard 1.16 so I can upload a patch.  

Original comment by [email protected] on 7 Oct 2014 at 3:41

@GoogleCodeExporter
Copy link
Author

So even though I'm using U8glib on an ARM (Raspberry Pi), I've opted to use the 
"Arduino" libraries because I'm using C++ and was use to using U8glib with AVR.

Make sure you've got wiringPi installed.

$ wget http://dl.bintray.com/olikraus/u8glib/u8glib_arduino_v1.16.zip
$ unzip u8glib_arduino_v1.16.zip
$ cd U8glib
$ patch -p1 < /tmp/u8glib_1.16.RaspberryPi.patch
$ make

I installed the library
$ cp libU8glib.a /usr/lib
$ cp U8blib.h /usr/include


To compile the logo:
$ cd examples/U8gLogo
$ make                   // Edit Makefile for U8glib/include directory.  I 
uncompressed U8glib 1.16 in /opt/U8glib
$ ./logo

Original comment by [email protected] on 7 Oct 2014 at 4:10

Attachments:

@GoogleCodeExporter
Copy link
Author

nice patch. I try to add this to the repository.

Original comment by [email protected] on 7 Oct 2014 at 5:07

  • Added labels: Milestone-1.17
  • Removed labels: Milestone-Future

@GoogleCodeExporter
Copy link
Author

U8G_I2C_OPT_NO_ACK is not supported for the i2c port, right?

Original comment by [email protected] on 7 Oct 2014 at 5:17

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

ToDo (u8glib project)
- checkin patched files
- test ssd1306 (modified, but not clear what has changed)
- create release folder for raspberry pi, create release construction script
- create install instructions, is WiringPi required? Check copyright issues.
- update device wiki page, support only for spi and i2c with ssd130x
- create bintry folder, check for suitable icon (copyright?) 
http://www.raspberrypi.org/trademark-rules/

Original comment by [email protected] on 7 Oct 2014 at 6:06

@GoogleCodeExporter
Copy link
Author

U8G_I2C_OPT_NO_ACK should be supported.  Actually though it didn't seem to make 
any difference with mine.  Perhaps because it was ignored?  But I did have to 
modify the include files so I could initialize with U8G_I2C_OPT_NO_ACK.

I'm glad it was helpful.  It seems as if there are quite a few of these OLED 
displays out in the wild now.  Thanks so much for making this wonderful library!

Original comment by [email protected] on 7 Oct 2014 at 1:33

@GoogleCodeExporter
Copy link
Author

The modifications I made to the ssd1306 file were in the initialization 
strings.  Quite minor in changes, but wouldn't work until I found the right 
init string.

Original comment by [email protected] on 7 Oct 2014 at 1:36

@GoogleCodeExporter
Copy link
Author

i guess i need to check whether the modification to the init strings will still 
work with my displays.

Original comment by [email protected] on 7 Oct 2014 at 6:05

@GoogleCodeExporter
Copy link
Author

The change happend to U8glib.h is not clear to me. The virtual function has 
changed from 0022 to 1.0. Is there an issue with wiringPi?

Original comment by [email protected] on 7 Oct 2014 at 6:11

@GoogleCodeExporter
Copy link
Author

hmm.. some files are distributed under LGPL, which is not as flexible as BSD 
license. This needs to be documented.
All in all, this is the new todo list for this project:

ToDo (u8glib project)
- checkin patched files, except for the c++ classes (because they will not be 
backward compatible)
- C++ files need to be analysed together with wiringPi. Maybe ADURINO define is 
not correct or some extra #ifdef is required inside U8glib.h
- test ssd1306 (init sequence modified, must be checked against the existing 
hardware)
- create release folder for raspberry pi, create release construction script
- create install instructions, WiringPi probably required. 
- Extend copyright documentation: Some files are under LGPL
- update device wiki page, support only for spi and i2c with ssd130x
- create bintry folder, check for suitable icon (copyright?) 
http://www.raspberrypi.org/trademark-rules/
- analyse U8G_I2C_OPT_NO_ACK topic. I still think it is not supported (actually 
it is violation of the I2C specification)

Original comment by [email protected] on 7 Oct 2014 at 6:21

@GoogleCodeExporter
Copy link
Author

Yeah, actually I don't think I did this correctly. Instead of
modifying u8g_dev_ssd1306_128x64_adafruit3_init_seq, I should have created
something like u8g_dev_ssd1306_128x64_adafruit4_init_seq and then used a
#ifdef for raspberry pi and set it to the adafruit4 init sequence.

Thoughts?

Original comment by [email protected] on 7 Oct 2014 at 7:08

@GoogleCodeExporter
Copy link
Author

Well I made this change because the additional include files wouldn't work
unless I made those changes.  You're talking about these, right?

#define ARDUINO 200

and

-    void write(uint8_t c) { tx += u8g_DrawGlyph(&u8g, tx, ty, c); }
+    size_t write(uint8_t c) { tx += u8g_DrawGlyph(&u8g, tx, ty, c); return
1;}

I believe those are the only changes I made.  Actually the diff had a few
other lines, but they just joined lines.  Should have cleaned that up
first.

Original comment by [email protected] on 7 Oct 2014 at 7:12

@GoogleCodeExporter
Copy link
Author

lot of activity !, nice ! hope i have some time next week to see if i can make 
my OLED work with this information. What is the meaning of the wiringPi pin
do u use another pin in combination with wiringPi ?

I2C Display   Raspberry Pi
--------------------------
VCC           1 
GND           9
SDA           3 (wiringPi Pin 8)
SCL           5 (wiringPi Pin 9)

Original comment by [email protected] on 7 Oct 2014 at 7:23

@GoogleCodeExporter
Copy link
Author

No.  I suppose I shouldn't have put the wiringPi pin's in there.  It's the same 
pin, but wiringPi library has a different pin definition (pin name vs physical 
pin).  Ignore those and you'll be ok.  :)

I2C Display   Raspberry Pi
--------------------------
VCC           1 
GND           9
SDA           3 
SCL           5 

Original comment by [email protected] on 7 Oct 2014 at 8:35

@GoogleCodeExporter
Copy link
Author

If you can get past the blur cam (tried to focus on the RPi pins) then this is 
the pinout I used.

Original comment by [email protected] on 7 Oct 2014 at 8:46

Attachments:

@GoogleCodeExporter
Copy link
Author

Also, thanks a lot from my side for the information and activity here. It makes 
me confident, that there is some need for the Pi Port.

Original comment by [email protected] on 7 Oct 2014 at 10:15

@GoogleCodeExporter
Copy link
Author

small update, i took over the following files


patching file U8glib.cpp                minor change, no problem    copied
patching file U8glib.h              strange, seems that wiringPi.h  copied
        Does wiringPi.h define the ARDUINO constant correctly?
patching file utility/u8g_com_i2c.c         modified, ok
patching file utility/u8g_com_io.c          modified, ok
patching file utility/u8g_com_raspberrypi_hw_spi.c  ok
patching file utility/u8g_com_raspberrypi_ssd_i2c.c ok
patching file utility/u8g_delay.c               modified, ok
patching file utility/u8g.h                     copied
patching file utility/u8g_state.c                   copied


i did not took over this until now:
patching file utility/u8g_dev_ssd1306_128x32.c  ???, not transfered
patching file utility/u8g_dev_ssd1306_128x64.c  ???, not transfered

Original comment by [email protected] on 12 Oct 2014 at 10:59

@GoogleCodeExporter
Copy link
Author

这个怎么移植ks108

Original comment by [email protected] on 13 Oct 2014 at 2:25

@GoogleCodeExporter
Copy link
Author

我不知道关于ks108。但如果是SPI或I2C我想它会正常工作。

Pi

Original comment by [email protected] on 13 Oct 2014 at 2:57

@GoogleCodeExporter
Copy link
Author

i move this t 1.18. Still i do not own the Pi

Original comment by [email protected] on 13 Dec 2014 at 4:56

  • Changed state: Started
  • Added labels: Milestone-1.18
  • Removed labels: Milestone-1.17

@GoogleCodeExporter
Copy link
Author

I too have one of the cheap four pin 128x64.
I'd tried the Adafruits drivers for the Pi (Python)
which did not work.
I then installed wringPi and 1.16 as per post #24
getting the logo program to compile was fun. I needed to add two libraries in 
the Makefile and the syntax on gcc only allows one (I think) this worked...
  INCLUDE=/home/pi/U8glib/include -I/home/pi/U8glib
however sudo ./logo did not work either.
At no time did I have a /dev/i2c-1 (or 0)
I have SPI and IC2 enabled (not blacklisted) via raspbi-config.
I'm used to linux adding devices at boot time so expected the device to be 
created if the unit was not DOA. I wondered if this was normal because of the 
lack of ACK thingy.
I Googled for the missing device and hit Gordon's site.
I simply needed to run `gpio load i2c` to load the device.
With this in place both adafruits and U8glib's logo sprang into life.

At least now I know I can patch four wires correctly and my unit is not dead.

Many thanks for your work here.

Original comment by [email protected] on 24 Dec 2014 at 4:33

@GoogleCodeExporter
Copy link
Author

I was able to get the Adafruit python drivers working for the pi, but I would 
really prefer to use the U8Glib if possible. I've been using U8Glib on arduino 
for a few months now and with the font support I would like to continue using 
U8Glib on the Raspberry Pi. Hopefully 1.18 is released very soon!

Original comment by [email protected] on 3 Jan 2015 at 10:13

@GoogleCodeExporter
Copy link
Author

Actually i may not be able to do anything for v1.18.
It alread has been shifted to the next release and probably shifting might be 
continued.
Main reason is: I do not own the Pi and i am not able to test or debug 
anything. This makes development almost impossible. I tried to add any of the 
modifications from above to U8glb, but without having them tested, it is 
difficult to say  whether they work or not.

So the situation is this: As long as there is no software developer & test 
engineer joining this project, there probably will be no release for the pi.

From my perspective the following things should be done:
- Make a full and good description how to install u8glib for Pi (wiki page here 
in this project)
- Apply all required changes to u8glib, check in everything
- Test the U8glibinstallation and test some examples
- Ensure that there are no conflicts with other variants of u8glib. It should 
still run with the Arduino Environment.

Still a lot of work is done, but i do not have the time or budget to do this.

Original comment by [email protected] on 3 Jan 2015 at 10:53

@GoogleCodeExporter
Copy link
Author

st7920无法工作

Original comment by [email protected] on 17 Jan 2015 at 7:22

@GoogleCodeExporter
Copy link
Author

After entering the make command my wifi dies. I tested this 3 times on a fresh 
install of Raspian Debian Wheezy. When I check the wpa_gui it tells me "could 
not get status from wpa_supplicant". Anyone else have this problem?

Original comment by [email protected] on 6 Feb 2015 at 10:52

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

I'd just like to report that I managed to get DOGXL160 working using 4 wire SPI 
and the patch from #24 (thanks!) I've used two-parameter constructor to make it 
use hardware SPI.

I'm currently trying to make it draw whole screen in one sweep (it currently 
does 13 or, when using X2 driver -- 7 sweeps) since Raspberry has plenty of RAM 
and we don't need it to draw everything multiple times. I hope it will make it 
faster since it's not really fast right now.

Original comment by [email protected] on 17 Mar 2015 at 11:02

@GoogleCodeExporter
Copy link
Author

#50, that'd be great.  I am using 4-wire SPI and got much better refresh rates 
by changing the bus speed.  What worked well for me was to change from 500 kHz 
to 3.2 MHz.  Check utility/u8g_com_raspberrypi_hw_spi.c on or near line #77

Original comment by [email protected] on 17 Mar 2015 at 11:16

@GoogleCodeExporter
Copy link
Author

#44,can you send me source code for python?

Original comment by [email protected] on 27 Jun 2015 at 12:34

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant