Hello Pedro
I’d have to check exact addresses but you have the correct idea. If you use Linux to set muxing so pins are I2C this eliminates investigation of that’s even possible from PRU just have Linux do it.
This then leaves
Also, configuration registers must be set in another registers to make I2C2 work properly
Then you read and write to a register as you said to transmit or receive
The config register’s usually allow polled or interrupt to be generated.
Polling is probably easier
The PRU examples may have both I haven’t looked at the code.
The important part is understanding exact adresses of all registers and which bits are being polled or checked.
You look at the code and header files and calculate what addresses are being Access. Look in TRM see address code using and say ok he’s polling for data on bit 5 or oh here he’s transmitting a byte.
Of course you need a device wired up to communicate.
Probably the simplest test is to read a status register from the slave device that contains known data from it’s data sheet.
You could code that by modify an example provided in cookbook.
Just steal all the init config code and modify example to poll forever reading the slave status register for known value if you get that working first time I’d be proud.
It’s more than likely this code will not work as Linux didn’t mux like you wanted let be positive.
Of course simplest way of it all works is you use exact what he’s using for linux in cookbook and same slave device and wire it correctly
It’s worth buying everything he has exactly same hardware who knows maybe then he can help:crazy_face:
if you post.
To me the important parts are understanding exactly what the PRU examples are doing specific to register addresses and correlation that the addresses match the TRM and you understand the bits being manipulated in registers by cross reference TRM.
Every device driver uses same idea.
The power of this is then you can write an I2C device driver for ARM core as well of course address change in TRM
To be honest a device driver on a bare Bones ARM core is much more straight forward.
Using PRU now you have to decipher whether linux set up I2C mux correctly on ARM.
That’s really backwards having 2 processor’s configuring a device. Especially the way it’s done in Linux
Now factor in you need the data to be shared outside the chip you have all the Linux virtual address crap it’s a mess.
Did you know they have SOC same arm cores plus DSP. both cores can run in hard realtime fast no PRU both DSP and and ARM can use I2C and share Data in shared memory very simple to understand and fast you know why?
You don’t have an albatross called Linux on the arm
The downside is these RTOS cost $$$$$ or using bare Bones you need device driver’s
Linux is good but it’s meant for Stuff that’s not hard realtime that’s probably why the PRU was added.
Anyway you have what you have to use so better to be positive and work through it unfortunately I know zero about DTS dtbo etc etc.
I do know uboot.
Let’s accumulate as much I2C c code as possible for BBB is good.
You do know they may have both interrupt and polled I2C examples for ARM and maybe PRU in starterware?
These are Best to understand how I2C is done as far as address of registers and values in config register’s.
I’ll do some digging for c code examples it be good refresher course for me. I did this for 32 year’s I’m old hahaha I miss it.
Keep us posted 
