Most efficient GPIO/SPI possible in C

[Conjur]

I am working on an LCD CLI, that runs completely separate from the main interface (events and Hdmi). It's purpose is to provide a control interface for the pi (power, volume, crashed Kodi recovery, etc)

Currently from C, I am using wiringPi and the bcm2835 libraries for GPIO control, feeding the ILI9469l, and reading the XPT2046..

Being a mostly static display, I have it running from interrupts and init, only running the program when actually needed.

However, for touch events, the program gets ran 50+ times, reading the touch location, and updating the display accordingly. This leads to a lot of Un needed overhead, loading the wiringPi and bcm2835 libraries each time.

What is the minimal code needed to send and receive 3 bytes from a 4wire spi interface? I have tried the minimal_spi approach, but it hangs on waiting for SPI_TXD and SPI_CS_DONE.. Is this documented anywhere?

Also, outside of WiringPi, I have not been able to read or write GPIOs reliably..

I may have the variable names wrong, I am at work, and do not have the code in front of me.

V/r,
Mike

[joan]

You are suggesting that you run external programs linked with wiringPi and/or bcm2835 50 times a second?

If that's the case surely it's your program which is inefficient. Re-design and find a way of leaving the libraries resident.

[Conjur]

Not 50 times per second; 50 times per use.
Initial touch interrupt, screen update, release interrupt, screen update (and periodic updates depending on the button pressed) I can get away with only running it twice per event ; but constant screen feedback considerably improves the feel of the device.

I am looking for a method to not load the libraries, and write /read from /to the registers directly.

Memory is at a premium, and wasting 2mb of it to keep un needed libraries resident is just wasteful.. The control interface goes days between use, I just would like to make it more efficient when it is used.

[joan]

Not 50 times per second; 50 times per use.
Initial touch interrupt, screen update, release interrupt, screen update (and periodic updates depending on the button pressed) I can get away with only running it twice per event ; but constant screen feedback considerably improves the feel of the device.

I am looking for a method to not load the libraries, and write /read from /to the registers directly.

Memory is at a premium, and wasting 2mb of it to keep un needed libraries resident is just wasteful.. The control interface goes days between use, I just would like to make it more efficient when it is used.

In that case perhaps you should sort out what is going wrong with minimal_spi. If it is my minimal_spi that is now incorporated into pigpio and should work. Perhaps you should cut&paste the needed working code from pigpio.c.

[Conjur]

I found the source of the issue with the copy of your minimal_spi code that I pulled from the forums.

the hardcoded memory locations were setup for an earlier version of the raspberry pi; apparently the mapping changes from 0x2000 0000 to 0x3F000 0000 on the RPI 2/3.

now, as a bit of a perfectionist; I am stuck with an unknown. RPi's usually run with a 250MHz core clock. I run my development RPi3's core clock at 400MHz, and my actual TV RPi2's at 250MHz; is there a simple method of reading the current core clock speed from C, without pulling it from the config.txt or scraping the output of 'vcgencmd measure_clock core'?

V/r,
Mike

[joan]

I found the source of the issue with the copy of your minimal_spi code that I pulled from the forums.

the hardcoded memory locations were setup for an earlier version of the raspberry pi; apparently the mapping changes from 0x2000 0000 to 0x3F000 0000 on the RPI 2/3.

now, as a bit of a perfectionist; I am stuck with an unknown. RPi's usually run with a 250MHz core clock. I run my development RPi3's core clock at 400MHz, and my actual TV RPi2's at 250MHz; is there a simple method of reading the current core clock speed from C, without pulling it from the config.txt or scraping the output of 'vcgencmd measure_clock core'?

V/r,
Mike

I can't help with that. In my experience PLLD has always been 500MHz and the SPI timings are correct on all Pi variants. I don't think PLLD is affected by overclocking or throttling, but I don't get into those situations and can't be sure.

[Conjur]

I can confirm that core_freq affects the SPI clock. When I have the core freq at 400, the lowest SPI divider I can get to work is 12 (33.3Mhz), with pixel data corruption at 10 (40MHz). At 250, it works great at 8 (31.25Mhz), with pixel data corruption at 6 (41.6MHz).

I have no good reason to run a higher core clock on the one system, so I suppose o could just retard it back down to 250; but would prefer to fix the issue by just calculating the divider from the current core clock speed.

V/r,
Mike

[joan]

Oh dear. Is this a Pi3? If so you can force the core clock to 250MHz I believe. If it's a Pi3 problem then it is disappointing.

[Conjur]

Oh dear. Is this a Pi3? If so you can force the core clock to 250MHz I believe. If it's a Pi3 problem then it is disappointing.

My development pi is a pi 3b, the ones on the TVs are all 2b's.

As far as I know, the default core speed is 250Mhz on both. I changed the 3 to 400. I would still like to know how to read /measure the current core speed, for portability, as I am likely not the only person to change my core speed..

BTW, after putting in the appropriate register locations for the 3B, you minimal spi code works amazing (with a few modifications to reduce variables by plugging in static numbers. I am just shy of 14Fps on my Chinese 3.5" tft

[joan]

You would be better off posting a new question about querying the core clock speed. People who know are then more likely to notice the question.