I am implementing an I2C slave in c with PIGPIO and I have run into a snag. I want to send numbers. The struct is

typedef struct
   uint32_t control;          /* Write */
   int rxCnt;                 /* Read only */
   char rxBuf[BSC_FIFO_SIZE]; /* Read only */
   int txCnt;                 /* Write */
   char txBuf[BSC_FIFO_SIZE]; /* Write */
} bsc_xfer_t;

I can send data to the slave as unsigned char array and it is working fine. However the data coming back from the PI is variable and incorrect. I have done some more testing on the PI to confirm the data is correctly added to the buffer. However that was not extensive I will do more.

I think I have nailed it down to the txBuf in the struct being unsigned. All the Arduino stuff is using uin8_t (unsigned char).

On my Arduinos I have just been using a union to do simple conversions

typedef union {
  uint8_t bytes[4];
  uint32_t number;
} _UINT32;

Reading in the values work cleanly but sending them back doesn't.

Has anyone got any ideas how to deal with this?

  • Sorry it was very late and I had spent many hours trying to find a solution I'l edit the question – Yardie Sep 17 '19 at 3:33
  • So to clarify, the Pi, operating as an I2C save with some (arduino?) host can receive data from the host OK, but the Pi sending data back to the host doesn't work. Is that correct? Have you tried the python I2C slave demo? abyz.me.uk/rpi/pigpio/examples.html#Python_bsc_arduino_py – Fred Sep 21 '19 at 22:24
  • We do not flag questions with [SOLVED] in the title. Instead accept your own answer after two days. That's the right way to mark questions as solved. – Ingo Sep 22 '19 at 18:22

Ok after a long weekend I have a PI as a I2C slave. In C not Python (don't much like python myself but many people do). Also the python slave treats the buffer as a string so sending long numbers requires conversion to and from strings. I was after a method to send raw unsigned bytes.

I can now envison an ATTiny master controlling a PI slave. Sort of David and Goliath like.

The data transfer issue was relatively straight forward once I understood it better. Which took a long time.

This is fundamentally a FIFO issue. The chip sends the data in it's buffer. So you end up writing the data for the next request.

One trick that took me ages to work out was

bscXfer(&xfer); xfer.txCnt = 0; // if you don't add this the data continually gets added to the FIFO buffer with each call.

  • Yes it is obvious once you see it.
| improve this answer | |
  • Please accept your own answer with a click on the tick on its left side. Only this will finish the question and it will not pop up again year for year. – Ingo Feb 24 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.