ARM port has lots of arduino andavr code in it - could use a cleanup

[GoogleCodeExporter]

I'm trying to get this adafruit display

http://www.adafruit.com/products/1431

to work with a teensy 3.0 (kinetis K20DX128). I tried the new ARM port (thanks 
for that!) and my impression is that all hardware specific programming takes 
place in u8g_arm.h and u8g_arm.c. Yet the library contains lots of files 
specific to arduino and AVR. Could this be cleaned up or is there too much 
interdependency between those files?

Also, is it true that the remaining parts of the library could be made 
completely generic? This would result in 3 distinct layers: Graphics (drawing 
functions), display drivers (for example the SSD1351 functions and structs) and 
hardware (how to actually transfer data to and from the display). Such a 
library could be used for practically any controller with I/O, be it parallel, 
serial, bitbanged or hardware.

Original issue reported on code.google.com by avrbegin...@googlemail.com on 14 Oct 2013 at 9:54

[GoogleCodeExporter]

For the arm portall AVR and Arduino specific code is removed by #if/#ifdev 
preprocessor commands. Nevertheless, i agree that some files can be removed 
completly. I will try to do this for the next release.

The separation into three layers should be there already and i assume, that the 
ARM port could be used with any controller.

For the ARM port: If you find something that is specific to any controller 
except for u8g_arm.[hc], then let me know. This would be a bug.

As of now i rate this issue as enhancement (remove arduino/avr specific files 
from the arm port)

Original comment by olikr...@gmail.com on 14 Oct 2013 at 7:15

• Changed state: Accepted
• Added labels: Milestone-1.15

[GoogleCodeExporter]

Thanks! However, may I suggest also removing the preprocessor directives that 
distinguish between AVR, arduino and ARM? It's a release for ARMs - you might 
even call it generic, this would be even more precise if it really is generic - 
so it should not try to do extra things for AVR and arduino. They have their 
own releases, which is great and the AVR release worked for me.

I'll post here when I managed to use the ARM release v1.14 with the 
controller/display combo above. I have not yet found anything ARM specific 
outside of u8g_arm.*, but the preprocessor directives _are_ puzzling.

Original comment by avrbegin...@googlemail.com on 14 Oct 2013 at 7:59

[GoogleCodeExporter]

removing the Arduino/AVR specific files will also remove many conditional 
compiler flags. However, some will remain in u8g.h.

I will think about replacing "arm" with "generic".

Original comment by olikr...@gmail.com on 14 Oct 2013 at 8:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Works as intended:

- teensy 3.0 (mk20dx128)
- adafruit ssd1351 128x128 OLED display
- teensyduino libraries
- custom SPI code in u8g_arm.c

I'll happily provide the code if you want. It's a hackish setup, though.

Original comment by avrbegin...@googlemail.com on 14 Oct 2013 at 9:52

[GoogleCodeExporter]

Great. You can always add code hier as an issue. Other users can access it here 
from the issue list and benefit from our work. I do hesitate a little bit 
because i am unable to test it.

Original comment by olikr...@gmail.com on 14 Oct 2013 at 10:13

[GoogleCodeExporter]

ToDo:
remove specific arm and arduino files from the arm release (create release 
script)

Original comment by olikr...@gmail.com on 22 Jan 2014 at 8:08

[GoogleCodeExporter]

generic version --> issue 236

Original comment by olikr...@gmail.com on 24 Jan 2014 at 6:57

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

removed arduino and atmega com files from the release. testing required

Original comment by olikr...@gmail.com on 24 Jan 2014 at 7:14

• Changed state: Started

[GoogleCodeExporter]

Original comment by olikr...@gmail.com on 24 Jan 2014 at 7:51

• Changed state: Fixed