Raspberry Pi from PIC communications

rovtech · Joined: 24 Sep 2006 Posts: 285

I wish to send an array of data from a PIC to a Raspberry Pi 4b.
First I investigated I2C and found it can only send one byte at a time if the PIC is a slave.
Even as Master I am limited to 127 bytes.

I considered USB and Ethernet but it became clear that these are not simple to use.

A search on the Python forum found a lot of questions but no simple answer.
This link is at too high a level for me and there is no working code:
https://pythonhosted.org/pyserial/shortintro.html#short-introduction
This thread does not show the working code either:
https://www.ccsinfo.com/forum/viewtopic.php?t=54205&highlight=raspberry++serial

An example should not require more than 5 lines of code for each device.

This is helpful.
https://forums.raspberrypi.com/viewtopic.php?t=307094

This uses WiringPi (WiringPi is a C library that provides a convenient way to access the GPIO pins on Raspberry Pi boards. It's designed to be similar to the "wiring" system used on Arduino, making it easier for Arduino users to transition to Raspberry Pi projects. It renumbers the GPIO pins)
https://www.mathworks.com/help/matlab/supportpkg/use-the-serial-interface-on-raspberry-pi-hardware.html
This has examples for WiringPi and SerialPi but is vague on what the Pi is connected to (PC). There is no code for the other end.
https://www.waveshare.com/wiki/Raspberry_Pi_Tutorial_Series:_Serial

Does anyone have a link to working code to receive an array of data from a PIC to a Pi. No ASCII characters that have to be translated, just 8 bit binary.

My other option is to use parallel data transfer with a couple of bits for handshaking. It uses a lot of pins.

temtronic · Posted: Tue May 06, 2025 9:52 am

OK, I have to ask.... what's wrong with simple, good old reliable 'RS-232' ?
Providing you have a comport( UART) at both ends, it's darn reliable. Even if bitbanged, communications can be very reliable( I can get 15 miles no problem)

dyeatman · Joined: 06 Sep 2003 Posts: 1956 Location: Norman, OK

A number of years ago I sent a fairly large array data via I2C 8 bits at a time.
Of course this be an issue if speed is required.

In my case speed was not an issue. The first bytes were "setup
data" bytes, of which two had the total number of bytes being sent (up to
65K) and two with the starting address in the array (so I could send partial
data if needed). I then used the offset from the beginning of the array and
copied the remaining (count) bytes into the array in order. If I had two
different segments I sent two separate streams.

This worked for me for more than 10 years on a industrial control system with
no issues until we phased out the system

Maybe this approach would work for you.
_________________
Google and Forum Search are some of your best tools!!!!

rovtech · Joined: 24 Sep 2006 Posts: 285

Yes dyeatman, i2c was my first thought. I used it for years in my ROV.
I may still go that way. How does each end know what to expect? A slave PIC uses an Interrupt Service Routine. I don't understand what Python does.
I need to send two arrays of 512 bytes in 4 msec. I have a PIC installed in a Heathkit Curve Tracer and I need to send settings and digitized curves to a RaspberryPi 4b for plotting.
I would like to adapt it to show real time displays of an HP4193A Vector Impedance Analyzer and an HP4192A Impedance meter.

Yes Temtronic, RS232 has 1 or 2 start bits and a stop bit. Sounds easy but I need to see the protocol and an example of the software at each end.
How does each end know what to expect? One could be expecting ASCII with CRLF control bytes. I could spend weeks writing it but someone must have done this and that is what I'm asking for. Not an example with hundreds of lines of code that does other wonderful things I don't understand and I'm not interested in.

This schematic shows how far I went down the rabbit hole. I wanted a fast dual ADC (28 MSPS), then a PIC with lots of memory to store the data (maybe 8 kbytes or more), then enough pins to control everything. The project is an XY DSO that can be used to replace 1975 vintage pen plotters (paper and ink). It would be nice to make it versatile for other projects, hence the added complexity. Now I need to work out the things I don't understand. I'm a hardware guy, not a real programmer.
https://drive.google.com/file/d/1SUMeJ8wPJh5_twpTLxo1x-SfKuNpzXeY/view?usp=drive_link
Yes, the PIC won't do 28 MSPS but it can control logic chips that can.

Ideally I don't want to modify the RaspberryPi too much with a bunch of wires hanging out. It does have USB and Ethernet ports but they are beyond my skills, unless someone has done it.

dyeatman · Joined: 06 Sep 2003 Posts: 1956 Location: Norman, OK

Here is a Python I2C receive routine that may help:

rovtech · Joined: 24 Sep 2006 Posts: 285

Thanks dyeatman; that gives me an idea of how Python works but isn't this all done in Python functions. I have found many snippets but no complete working examples showing both ends. I saw an Arduino example which would be difficult to convert to PIC (for me). The problem with i2c is that the PIC needs to be Master to send up to 126 bytes and the Pi does not support clock stretching. As Slave the PIC can only send one byte at a time.

UART seems to be a better choice as temtronic suggested. I don't know what the protocol is. RS232 has drivers for long lines that can be dispensed with for short distances (12 inches). The DB25 connector is not needed either. However proper RS232 has:

TXD & RXD which would be TX and Rx on the Pi and PIC. An interface is still required to switch the lines for bi-directional operation.
Example from my ROV: https://drive.google.com/file/d/1eZLK37uOr6xSMz0qtptk10BYL_UbB-lM/view?usp=drive_link
RTS & CTS: Request to Send (RTS) is activated by the transmitter when it needs to send data, and Clear to Send (CTS) is activated by the receiver to indicate readiness to receive data.
DTR & DSR: Data Terminal Ready (DTR) informs DCE that DTE is ready for communication, and Data Set Ready (DSR) indicates that DCE is ready
DCD: Data Carrier Detect (DCD) shows that DCE is connected to DTE
RI: Ring Indicator (RI) is activated when an incoming call is detected

At least RTS and CTS would be needed and there should be routines written to handle this. I shouldn't need to reinvent this. I need an example for both PIC and Pi.

dyeatman · Joined: 06 Sep 2003 Posts: 1956 Location: Norman, OK

Also, you likely know with RS232 the characters must all be converted to ASCII
before sending and converted back on the other end which is somewhat a pain...

In my case I sent each byte, not a group of bytes and it worked fine (and I was
totally unlimited to the number of bytes I could send). I just picked the start
point in the array and started sending. This way I could update 1 byte, a
group, or all as needed. BTW, I also sent a terminator byte at the end to tell
the other end I was done. This way there was no time limit on how fast I had
to send one or more bytes. It just kept adding them into the array at the next
location until I told it I was done but I had to be sure I sent that
terminator command or it started overwriting memory!
_________________
Google and Forum Search are some of your best tools!!!!

rovtech · Joined: 24 Sep 2006 Posts: 285

I don't think it has to be ASCII with RS232. It can be any 8 bit byte.
Without functions for each of the Pi and PIC and a connection diagram it is a waste of time.
I also have a PL2303 USB from UART board. There are lots on Ebay but the software is usually missing. I do have a routine for Hitec on MPLAB but it is uncommented and there are no instructions on connecting it.

dyeatman · Joined: 06 Sep 2003 Posts: 1956 Location: Norman, OK

Don't forget the control characters.
Since you have no way of knowing the data you can't just send it raw.
_________________
Google and Forum Search are some of your best tools!!!!

rovtech · Joined: 24 Sep 2006 Posts: 285

I have done it with the harware handshaking. I remember ASCII and pink punched tape.... Anyway it sounds like a PITA.
This is the sort of thing I was looking for, but for a PIC which does not have the Arduino libraries.
https://roboticsbackend.com/raspberry-pi-arduino-serial-communication/

rovtech · Joined: 24 Sep 2006 Posts: 285

Would it be easier to use SPI?
I have never used it so I would like to know:
Are there limitations like those of I2C?
Can unlimited data be sent from a slave in a stream?
Example software for a SIMPLE connection would be appreciated.
I can look for Pi examples if this looks hopeful.

Ttelmah · Joined: 11 Mar 2010 Posts: 19827

You seem to be wanting to make things complex. All of these interfaces
are single bit serial interfaces. SPI is the fastest, but needs three tires.
I2C is simple, bidirectional and reliable. Has the advantage of allowing more
than two devices on a single pair of wires. Normal UART serial is probably
the easiest, and if it is only going a few inches can be run very fast without
special interfaces. Can be sent really long distances if you use suitable drivers.
All only send a bit at a time, but the PIC can assemble these into bytes for
you and with suitable code can handle packets any length you want on any
of these interfaces. I2C as standard can handle up to 126 bytes per
transaction. Serial can handle any length packet for which you have memory.
SPI the same.
Your original I2C would work fine. It is only you who seem to think you can't
do more than one byte back.