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 to XC8 #514

Open
RozeDoyanawa opened this issue Sep 30, 2020 · 3 comments
Open

Port to XC8 #514

RozeDoyanawa opened this issue Sep 30, 2020 · 3 comments

Comments

@RozeDoyanawa
Copy link

RozeDoyanawa commented Sep 30, 2020

Hi,
I'm trying to implement this on my PIC18 microcontroller. I know this is somewhat out of topic and attempts have been made in the past. However, I'm still trying.

However, a bit of an issue I've ran into while writing a Device Descriptor,
The new K42 architecture of a PIC pushes nearly all I2C communication to hardware.
The programmer simply waits for the bus to be free, then writes the byte count and slave address to two separate registers. This is followed by a loop of writing byte by byte to a 2-byte output buffer. Hardware automatically handles ACK/NACK and Start/Stop conditions. Stop condition is automatically sent on the 9th edge of a byte when Count is 0 and "restart" is not set. There is NO way to force a stop bit afaik.

The issue here is that the whole library assumes user have control over the Start/Stop conditions. Ie. u8g_i2c_start/u8g_i2c_stop/u8g_i2c_send_byte. Whereas the new K42 would only take a single u8g_i2c_send_bytes(slave, data, length) to handle everything.

The number of bytes is not currently passed to u8g_i2c_start, which complicates matters.

Any suggestions?

@olikraus
Copy link
Owner

olikraus commented Oct 1, 2020

First of all you need the professional version of the development environment to use u8g or u8g2. Especially you need link time optimization feature which is not there in the free versions of XC8 (at least it had been like this in the history).

Regarding I2C, my suggestion is to use u8g2 instead. Instructions should be more clear for any porting activities for u8g2 instead of the old u8glib.

For u8g2 there are two examples on how to carry out the I2C communication: https://github.com/olikraus/u8g2/wiki/Porting-to-new-MCU-platform#hardware-i2c-communication

@RozeDoyanawa
Copy link
Author

RozeDoyanawa commented Oct 1, 2020

Yeah, one of my ideas was to buffer the data, but it generates so much overhead.
I will instead first try to manipulate the CNT to see if I can force trigger stop commands.

Also, I'll stick to version 1 for now, cause I've cut out tons of code and more or less will only paste required functions. I've gotten it to compile on the free version of XC8 for now, but I'm only interested in a VERY limited subset of functions. Namely u8g_DrawStr. And because I'm only writing for a single architecture, I can cut out all the unnecessary parts manually instead of trusting the compiler will do it. Down to 11kb program memory and 520 byte data.

Also, my first attempt was to just add the whole library, but I had to close XC8 when it started approaching 100GB of RAM-usage. Unfortunately, I don't have nearly enough RAM to compile the full library. I would assume the same applies to version 2 as well.

Edit: The fact that compilation does not even reach the link-stage before suiciding with huge RAM usage suggest this library is even more incompatible with XC8

@olikraus
Copy link
Owner

olikraus commented Oct 1, 2020

Edit: The fact that compilation does not even reach the link-stage before suiciding with huge RAM usage suggest this library is even more incompatible with XC8

The problem is probably the font data. U8g not only relies on like time optimization, it also requires, that the c-compiler cuts down all definitions of a file into deparate link objects.

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

No branches or pull requests

2 participants