Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Pic 2 Pic i2c communication

Status
Not open for further replies.

HerbertMunch

New Member
Hi all.

Im creating a temp sensor project.
I want to have 2 devices (both pic based), 1 as the master, and 1 as the slave.
The number of slaves is going to be variable, but im just starting off with 1.
Im using c18 with Pic18f4550s, and wish to use I2c bus to allow master to talk to slaves.

I intend to make the project scalable, by allowing more functions to be added to each slave at a later date.

i need to come up with some sort of "language" that all devices can use to speak to each other.
For instance I want to be able to query a slave devices capabilities, and then react based on the slaves response.

Does anyone have any thoughts on constructing such a language, that will allow for structures of information to be sent serially?

It would be nice to have some sort of struct to serial and serial to struct conversion routines, but i need something quick to implement:rolleyes:

Many thanks
 
Last edited:
Do you need a multi processor design ?
Could you use dallas 1 wire sensors ?

You did not say what language you were using.
Take a look at
It should do what you want. I am not sure about the size of the library. Let us know if it will work.
 
hi mate,

I want to do it that way so that i can delegate processing work and reduce the amount of wires needed (i.e it would take the same amount of wires travelling to the main unit to do 10+ sensors as it would 1. 4 wires total for many sensors)


I looked at that page about serialisation, but it doesnt mention pics.

Thanks.
 
Last edited:
When you initiate the slaves, you could load the buffer with a config setting like..

Psuedo code:
slaveconfig(1) = b'abcdefgh'
a = 1 ;temp sensor present/not present
b = 1 ;eeprom present/not present
c = 0 ;humidity sensor present/not present
etc.

Then have the master read each slaves buffer at startup to discover their capabilities.
Not sure about how you would do that without first knowing the slaves address first tho.
 
Chris,

FWIW the 1 wire bus is a serial multidrop bus. You can hang quite a few (forget the number) of sensors on a single twisted pair.

It would be nice to have some sort of struct to serial and serial to struct conversion routines, but i need something quick to implement

The library I suggested is written in C. It takes an instance of a C struct and converts it into a series of bytes that can be sent over a serial connection and reconstructed on the other end. Maybe that is not what you were looking for?

Serialization in C^top^

Tpl is a library for serializing C data. The data is stored in its natural binary form. The API is small and tries to stay "out of the way". Compared to using XML, tpl is faster and easier to use in C programs. Tpl can serialize many C data types, including structures.
^top^
Applications^top^

Here are some ways that tpl can be used:

As a file format.

As a way to pass structured data over a pipe or socket.

As a message format for message-passing programs.

As a way to replace complex parameters to functions, without using structures.
 
You might check out DF4OR's Icom CI-V pages. CI-V is a TTL level serial protocol (short distances) using standard RS-232 async' baud rates on a bi-directional one wire bus. It's used on several different Icom Amateur Radio products and add-on communications products.

Mike
 
You're welcome.

I thought it was an interesting protocol model with its two byte <preamble>, <to> and <from> address bytes, <cmd> and <data> bytes, and an <end-of-packet> byte. Unfortunately it also limits you to using data which does not include the <preamble> or <end-of-packet> bytes.

Regards, Mike
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top