Running out of inputs and outputs

[Froggs]

Running out of inputs and outputs

Help please. First some context. I’m new to all of this but a long Easter week end has seen some quick (and successful) learning and prototyping. This is what I want to achieve.

Using 18* DS18b20 sensors with output to 6* LCDs using SEROUT (and FRM010 firmware). I have ‘invested’ in 28X2 chips for my learning experience. (My prototyping works on just 2 DS and 1 LCD; but I’m confident that I can ‘grow’ the code).

I understand that I have a few options which include:

a> 28X2 = 22 config. i/o pins (if so configured this means use all i/o pins for base functionality as above). This will not allow room for additional functionality/ extensibility?
b> 40X2 = 33 config i/o pins (this allows room for additional functionality/ extensibility as above)? [but I don’t have any yet!!]
c> assumption a above is that each DS18 would be on own i/opin. I could ‘pair up’ sensors and create (say 8*) multiple 1-wire bus (in my example freeing up 8 pins)? I had planned not to use the 1-wire bus because of the caveats on 1-wire topology; cable length, etc reported in this forum and on the data sheets..

Then I get less certain of my options

d> perhaps I could use i2c for my LCDs. I haven’t read into this too much but I don’t see that that will free so many pins, and may make the code more ‘complex’?
e> perhaps I could use i2c for 28X2 chips.. and ‘share’ the inputs/ outputs thereby? but again for my level of leaning this is unchartered territory?
f> some other kind of multiplexing some how?????

So my question to this forum is to ask the learned and knowledgeable to comment on their preferences for the approaches identified above (or perhaps alternatives that I have not yet considered)

One further question. Given the nature of the sensors and LCDs proposed should I be concerned about [current] load?

Thank you!

 

[Dominic B]

I've not used i2c with LCDs, but I think that still requires the one input per LCD

I'd probably set up the two 28X2s with a serial connection between them, say with one chip with the DS and the other with the LCDs, all the data can then be sent through serin/out between the PICs. The first chip just needs to send out what the LCDs are to display and the second chip will then record this and act on it. It depends on how much is going to vary on the LCD, if all they need to show is a changing value, then that's easily done (any other text will be fixed). If it's more complex, it might be more complex to achieve

 

[Froggs]

Thanks for your comment. To clarify:

LCDs are 16*2

Each line is in the format CCCCCCvvvvCCvvvv where C is constant v is variable (in my example DS reading #1 #2 [and sign]). Constants are specific to each line. Each LCD line has its own constant which at the moment is one of the fixed ‘messages’ for that LCD.

 

[westaust55]

You would need to do some searching for i2c based LCD modules.

I think you may find them to be scarce in particular with multiple i2c slave addresses.

Certainly the rev Ed AXE033 has i2c as well as serial capabilities but only one slave address making conenction of multiple LCD module complex.

If you do find something suitable then all the i2c devices can (provided they all have different slave addreses) be placed on a single network subject to not ending up with excessive wiring/bus lengths.

Others have used multiple DS18B20 temp sensors on a single line by using the one-wire commands as opposed to the READTEMP command.
I leave it to you to try an initial search on this forum as the information is there.

 

[Froggs]

westaust55

Indeed I have searched this forum and elsewhere and found much discussion; hence my 'caution' wrt the 1-wire bus (hence possible proposition is 8 busses each with 2 sensors)… Perhaps I will experiment with this for a few days.

I guess what I am trying to promote in this thread is 'pointers' to what the more knowledgable would consider a better approach giving consideration to optimising time, cost, reliability, sense etc. Albeit I welcome a challenge. My coding skills are limited to 30 year old RPGII and more recently macro VBA.. but PICAXE basic syntax growing fast!

NB. I am using the AXE033 but had not appreciated the i2c limitations of it.

Thank you

 

[kevrus]

I think the 'one wire' for the DS18B20 sensors is the way to go. Not sure on the limitations but i've read 5 sensors on one line without any issues. It's worth a try to see how many will work, I couldn't try any more as 5 was all I had.

 

[inglewoodpete]

o-w and i2c bus lengths

There have already been a few replies regarding multiple devices on one-wire and i2c busses, so I won't add to those.

I have an 8-metre 1-wire bus in my house and successfully read 3 DS18B20s over it (note that I use a separate power wire). I don't know what the limit would be. Check the data sheets!

On the other hand, the i2c bus is limited to 1 to 2 metres under normal conditions. I have got i2c to work in a multi-drop bus up to 16 metres using P82B715 i2c extender chips at the master and at each drop. This was in an electrically noisey environment. The master and slave i2c chips were all 28X1s (firmware A.5 or later) with each slave configured with its own i2c address. Note that the extended i2c bus is limited by cable capacitance rather than distance.

Peter

 

[MORA99]

I have 6 sensors, each with 5 or 10 meters of wire, and the 3 of them is located another 20meters from the board, using a passive hub.
Its with a different chip than picaxe, but the limits should be the same.

Otherwise you can use 74HC4051 chips to get 8 inputs for the price of 3outputs(this can also work for 1-wire, but you need a resistor on each of the 8inputs), or 74HC595 for 8outputs at the same price (clk, data, latch), 595 can be cascaded so 2 chips give 16outputs but still just 3 pins.

There is also I2C chips that give you 16pins that can be configured on the fly as input or output, that only requires 2 pins, and additional chips dont require extra pins, since they both live on the I2C bus.

 

[hippy]

I agree, using a single I/O for all DS18B20 and using OWIN/OWOUT commands is a good choice.

You could also control multiple LCD by routing serial through a 1-to-N selector and address each in turn. That doesn't save as much I/O but, as Dominic B says, you could use another PICAXE ( say 20X2 ) allowing the master to use one output and send commands indicating for which LCD with that slave PICAXE directing data to appropriate LCD's.

For DS18B20 reading and LCD control you've then reduced requirements for the master PICAXE to just two I/O.

 

[Froggs]

Thanks guys. Some interesting debate. I note remarks from Pete in an old thread http://www.picaxeforum.co.uk/showthread.php?t=5028&page=2 and other methods look interesting too. Seems like more reading for me and using parts & approaches anew! To add: 10 sensors (5 pairs) will be with 6m: Remaining sensors (singles) <> to 40m

 

[inglewoodpete]

Thanks guys. Some interesting debate. I note remarks from Pete in an old thread http://www.picaxeforum.co.uk/showthread.php?t=5028&page=2

Froggs, note that that thread is dated 2006, before the X1 and X2 series PICAXE chips became available.

The X1 and X2 chips both have the owOut and owIn commands. By using a suitable electrolytic capacitor and introducing a small delay between the o-w Setup and Read commands for the DS18B20, it may be possible to use phantom power feed. It's not something that I've tried. Maybe others can comment on this.

 

[Froggs]

Pete. Thanks. I guess that shows my lack of &#8216;history&#8217; with Picaxe!

All. Looks like some good ideas promoted. Thanks again. Certainly some new thinking for me. From what&#8217;s proposed thus far, I feel more comfortable with Dominic B&#8217;s proposal using Serin/out (only because I'm new to this but think I understand more of what is happening). But that still begs some questions; if somebody could provide a useful pointer please on handling the data between chips.

In my original concept I would have moved sensor reading from the input pin to a [single] program variable (looping through pins & LCD outputs etc) using a common subroutine.

But to use 2* 28x2 chips: I have some questions? Ie:

Am I limited to serin/serout. Or where does sertxd/serrxd come in?

> Do I have to serout/in b0,b1,b2~ etc (ie looping through lots of program variables)
OR
> Can I move each reading into a data table [array] and output; then serial transfer the entire array and then [in the other chip] read in the entire array and &#8216;chop&#8217; it up again into its constituent readings? I can&#8217;t see that this exists but perhaps scratch pad and pointers is along the right track? Pseudo code then would be along the lines of:

Sensor Chip
> Process DS readings to construct [text string]
> output 28x2 output serial string [text string]
LCD Chip
> input 28x2 input serial string [text string]
> process [text string] identifying each &#8216;reading&#8217; as required

Again thank you.

 

[Froggs]

Some more thoughts (on i2c)

I have not discounted serial links, but want to understand (all?) my options.

While researching on ‘linking’ two picaxe chips [28x2], I turn now to i2c and suspect the world has moved on a bit from when some of the documentation was published?

Essentially I’m reading the manual part 2 Basic Commands version 6.9 published June 2009 and from various references (inc other data sheets) this points me to the i2C tutorial [axe110_i2c] version 1.2 Oct 2003; but no reference therein to the hi2c~ commands.

My question is what is best practices (ie what & when (when not)). Any pointers remarks please

 

[hippy]

Yes, the I2C tutorial was written before HI2C support arrived. In general, when controlling I2C slave devices ( as most are ), simply replace I2CSLAVE with HI2CSETUP, I2CREAD and I2CWRITE with HI2CIN and HI2COUT. We will be updating the tutorial.

The "HI2CSETUP I2CSLAVE" slave command also allows latest PICAXE to become slave devices. Issue that command and enter a "DO:LOOP" and the PICAXE is instantly a 128 or 256 byte I2C RAM. Add more than "DO:LOOP" and the PICAXE can handle data written to it and create data which can be read.

It's hard to say there are any recommended practices in multi-PICAXE systems using I2C as it depends on what one wants to achieve, but I guess they would include -

* Have a good understanding of I2C comms
* Have practical experience of I2C comms
* Start with I2C eeprom first
* Understand Device Addresses
* Start with one master, one slave
* Don't hammer the bus or slave, give it time to do work
* Don't expect data to be read or written correctly, ensure a mechanism (protocol ) that this will happen.
* Develop a small project to test and prove your understanding before going onto something more complicated.

An ideal goal I'd say to understand and get experience with the complexity of multi-PICAXE I2C is a system which has three PICAXE, all connected to a single I2C bus, each with a coloured sticker ( red, yellow, green ) and a push button. Each has three LED's ( red, yellow, green ) and each lights the LED's when the button associated with the particular stickered PICAXE is pressed.

When you've got that working, I'd say you could probably get any multi-PICAXE I2C system working.

 

[Froggs]

An ideal goal I'd say to understand and get experience with the complexity of multi-PICAXE I2C is a system which has three PICAXE, all connected to a single I2C bus, each with a coloured sticker ( red, yellow, green ) and a push button. Each has three LED's ( red, yellow, green ) and each lights the LED's when the button associated with the particular stickered PICAXE is pressed.

I like that idea. A challenge for the week end then!

 

[westaust55]

and with respect to your original post heading: Running out of inputs and outputs""

with i2c comms, once you have some experience with it, you can easily add an IO expander succ as the MCP23017 with provides a further 16 IO points configured as two 8-bit ports. Even has interrupt capabilities via a single digital input (3rd wire needed) back to a pICAXE so flag when an IO pin used as an input has changed state.
Thus more IO without needing to resport to a second PICAXE.
Of course, realistically, the i2c can only be done with X, X1 and X2 parts.

 

[Froggs]

You have to walk before you run.. I'm still crawling. Thanks for your comments.

 

[Froggs]

When you've got that working, I'd say you could probably get any multi-PICAXE I2C system working.

Hippy.

I&#8217;m struggling! I took on board the challenge as per your post. I constructed 3 physical circuits [boards 0&1&2] to accomplish this task. [This provides a constant working hardware environment so my assumption is that the variable part of my challenge is the software!]. The boards are identical. Basic download circuits, 28x2, 4Mhz resonator, SDA & SCL are linked (jumpered as required). I confirm the bus is pulled to +5v with 4k7 resistors (once only).

All 3 physical circuits work (RYG leds & switch) independently with simple stand alone program & [h]i2c program with the same master/slave address (ie if switch on circuit board 0 pressed flashes only G led on circuit boards 0&1&2 [else all RYG leds flash]. SO it seems to me that the construction side is OK

I CAN confirm that (a slightly modified) example on Page 61 manual v 6.9 06/2009 does work.

But I have problems. hi2cout I can get to work. But using hi2cin drives me to distraction. I just get 255 value which as the manual tells me is incorrect setup. I enclose a code snippet and apologise in advance for its &#8216;mickey mosue nature.. but this is a test bed? Clearly there is &#8216;stuff&#8217; in the code that will not be relevant for this post but it is the entire program that I am playing with. So ONE PROGRAM ONLY & gosub based on variable value determines what executes on which chip/ physical circuit.

I have searched this forum for help.. and tried to use the guidance where I have found this in my &#8216;playing&#8217; but to no avail. I have tried to use the manuals & the tutorial&#8230; but not with any success.

What am I doing wrong? Please. Any help will be very much appreciated. I think that I just got hold of the wrong end of a blunt stick!

;-----------------------------------------------------------

   #picaxe 28x2
   #No_Data
   #No_Table
   #Terminal 9600
   
   
   pause 500
 
 ;----------------------------------------------------------
 
   let b10 = 10   '<<<<<<<<<<<<<<<<<<MASTER
'  let b11 = 11	'<<<<<<<<<<<<<<<<<<SLAVE1
'  let b12 = 12	'<<<<<<<<<<<<<<<<<<SLAVE2    

main:
if b10 = 10 then gosub x_10Master
if b11 = 11 then gosub x_11Slave1
if b12 = 12 then gosub x_12Slave2

end

x_10Master:

hi2csetup i2cmaster, %10100000, i2cslow, i2cbyte
x_10MAIN:

gosub press_it

gosub slave_in 

hi2cout [%10100000],0,(b20)  'write value to slave 1
pause 10
hi2cout [%10110000],0,(b20)  'write value to slave 2
pause 10

gosub flash_it
debug
'etc....
goto x_10MAIN

x_11Slave1:

if 		b11 = 11 then let b31 = "Y"		'<this here for testing gosub slave_in 
elseif 	b12 = 12 then let b32 = "R"		'<this here for testing gosub slave_in 
endif

hi2csetup i2cslave, %10100000
X_11MAIN:
get 0,b20

'gosub press_it
gosub flash_it
debug
goto X_11MAIN
return

X_12Slave2:
if 		b11 = 11 then let b31 = "Y"		'<this here for testing gosub slave_in 
elseif 	b12 = 12 then let b32 = "R"		'<this here for testing gosub slave_in 
endif

hi2csetup i2cslave, %10110000
X_12MAIN:
get 0,b20

'gosub press_it
gosub flash_it
debug
goto X_12MAIN
return

flash_it:
	if b20 = "x" 	then gosub flash123
 	if b20 <> "x" 	then gosub flashOTHER
return

flashOTHER:
if b20 = "G"	then gosub flashGREEN
if b20 = "Y"	then gosub flashYELLOW
if b20 = "R"	then gosub flashRED
return

flash123:
high b.5
pause 500
low b.5
high b.6
pause 500
low b.6
high b.7
pause 500
low b.7
return

flashGREEN:
high b.5
pause 500
low b.5
return

flashYELLOW:
high b.6
pause 500
low b.6
return

flashRED:
high b.7
pause 500
low b.7
return

press_it:
let b21 = pinC.0
if  b21 = 1 then let b20 = "x"
elseif b21 <> 1 and b10 = 10 then let b20 = "G"
elseif b21 <> 1 and b11 = 11 then let b20 = "Y"
elseif b21 <> 1 and b12 = 12 then let b20 = "R"
endif
return

slave_in:
hi2cin [%10100000],1,(b31)  'read value of slave 1
pause 10
hi2cin [%10110000],2,(b32)  'read value of slave 2
pause 10
return

 

[hippy]

I haven't studied the code but suspect you are up against 'system design issues' which is what makes this apparently straight forward idea somewhat more complicated in practice.

I'd suggest starting with just one PICAXE in master mode, the other two in slave mode. Get that working first. Then expand. You'll have to trim your code down to the bare basics if you want people to keep track of what's happening as it's going to get complicated quite quickly. You're probably going to have to document what the PICAXE is doing and why as well as indicating what states the other PICAXE are in at that time.

At the very least you are going to have to add some mechanism which stops two PICAXE trying to access the bus at the same time ( or detects whan that has happened ), and to communicate, one PICAXE must be in master mode the other must be in slave mode. They cannot just change mode as and when they feel like it without having a potential consequence on someone else.

You're effectively defining the rules and protocol for a three-way, three person conversation. Have to prevent someone talking when not being listened to or be able to detect when that's occured.

I haven't thought on how I'd attempt this project, but I do know it will probably require a lot of thought. Perhaps more role playing scenarios than actual doing.

 

[Froggs]

Hippy. Thanks

I understand about the three way communication protocol issues & from what has been posted on the forum that multi master i2c bus is something of a task; but tell me on the basis of your proposition..

I'd suggest starting with just one PICAXE in master mode, the other two in slave mode. Get that working first.

That’s what I thought I had done AND Failed at that… So the situation is:

I have one master & two slaves:

The master issues Hi2cout to two slaves [that bit works OK]
The master issues Hi2cin [I am trying to get the value from the slaves.. but that gives me ERROR 255 in variable]

That’s what I don’t understand. Or am I trying to attempt the hi2cin from the wrong device?

 

[hippy]

It should work. Maybe drop back to simple code and ...

Two PICAXE, one writes/reads to the other, slave does nothing
Add another slave which does nothing, only access the first as before
Swap access to be to the added slave
Access both slaves

Forgive me if you've already done all that, but it's going to be an incremental process. moving forward, and then going back when something doesn't work to confirm that what did work still works.

 

[Chavaquiah]

I didn't read the thread from the start so forgive me if I'm missing something obvious...

Are the slaves running the actual code you transcribed, including the DEBUG statements? I also have troubles at times with Picaxes as slave i2c devices - seems quite a few commands affect their hability to respond to i2c requests.

If you haven't already, I'd suggest trying a very simple program first on the slaves, no debugs or serins or anything that might prevent them from servicing i2c.

 

[westaust55]

Froggs,

Have a look at this thread where I am experimenting with 1-Wire.
http://www.picaxeforum.co.uk/showthread.php?t=15306

Currently I have 5 x DS18B20 temp sensors (thats all I have at hand) on a single PICAXE input and there is no reason why there cannot be far more.
I have posted example code to search for and save all the 1-Wire device serial nos and other program example to change the resolution and read from all the DS18B20's.

 

[Froggs]

...

Are the slaves running the actual code you transcribed, including the DEBUG statements? I also have troubles at times with Picaxes as slave i2c devices - seems quite a few commands affect their hability to respond to i2c requests.

If you haven't already, I'd suggest trying a very simple program first on the slaves, no debugs or serins or anything that might prevent them from servicing i2c.

(1) Yes. The exact code as transcribed. (2) Yes 'troubles'. I thought that I was imagining the problems... maybe I am...(3) and I will revert to simpleR code; and I will persevere.

It should work. Maybe drop back to simple code and ...

Yes I will do that... but I'm not sure how simple I must go.. Anyway I will have a play

Have a look at this thread where I am experimenting with 1-Wire. http://www.picaxeforum.co.uk/showthread.php?t=15306

Currently I have 5 x DS18B20 temp sensors (thats all I have at hand) on a single PICAXE input and there is no reason why there cannot be far more.
I have posted example code to search for and save all the 1-Wire device serial nos and other program example to change the resolution and read from all the DS18B20's.

After a quick preview I think that this may well be useful for my eventual goal... but I'm now committed to get the i2c bit working... 'as a challenge'.

Many thanks guys for your input

 

[hippy]

It could get tricky in places and there may be unexpected pitfalls to work round. I set about getting two PICAXE to swap control between each other as master and slave and that took a bit of effort. "HI2CSETUP OFF" turns out to be important in bus handover. Code attached.

This uses location 0 of Eeprom to give each PICAXE a unique ID, $10, £20, $30 up to $E0. You have to load each with a suitable "EEPROM 0, ( $x0 )" before the code here. The code here has #No_Data / #No_Table so what's written into Eeprom is never lost. The numbers don't have to be consecutive but there must be an ID of $10 somewhere to kick-start things.

Once running they wait for scratchpad location 0 to become 1 which indicates they can have the bus. The one with ID $10 grabs the bus initially as first master. Each then passes control on in turn. Only tested with two PICAXE ( 20X2 and 28X2 ) but should work with more. No guarantees though. Each lights a LED+R on C.0 when they have the bus.

 

[Froggs]

Hippy

Thanks for that.

(1) Re 255 error. I have made some progress on my own by stripping down to VERY simple code (its surprising what the abscence of a 'return' does on a sub; even if the gosub was itself commented out?! !!!

(2) I will study your bit [a bit later... real work has to take priority]. But looks useful.

Thank you

 

[Froggs]

Success!

Hippy (& other guys)

Success! The original challenge was:

An ideal goal I'd say to understand and get experience with the complexity of multi-PICAXE I2C is a system which has three PICAXE, all connected to a single I2C bus, each with a coloured sticker ( red, yellow, green ) and a push button. Each has three LED's ( red, yellow, green ) and each lights the LED's when the button associated with the particular stickered PICAXE is pressed. When you've got that working, I'd say you could probably get any multi-PICAXE I2C system working.

So I have achieved this using only one master & 2 slaves using just HI2c +in +out in the master and put/get in the slaves etc. Only NOW do I understand the correct context & construct of the command. So it was a useful exercise.

Hippy. Your post yesterday encouraged me to look progress multi master. Always up for it… I will endeavour to achieve the same result with multi master.

Hippy: It could get tricky in places and there may be unexpected pitfalls to work round. I set about getting two PICAXE to swap control between each other as master and slave and that took a bit of effort. "HI2CSETUP OFF" turns out to be important in bus handover. Code attached.

I’ll let you know how I get on (I expect it will be a few weeks?!)

As a side note; I think I recall you saying that the I2c tutorial (written before H) required revision. Well I have learnt a lot from this exercise.. so as a basis for tutorial… and the extended context/ capability of the device perhaps a tutorial around this approach might be worthwhile? Food for thought anyway.

Again. Thanks

 

[hippy]

Well done for coming this far. There will always be some issues with typo's, wrong commands, and logical errors like that missing RETURN which get in the way at first which can add frustration. Get over those hurdles, get something working reliably, and it's much easier to move forward - and with a backup position to fall to if you need check the hardware is still working as expected.

Once you get on to multi-master operation there are two different ways you can do things; pushing data into the others or pulling data from them. I don't know if there's any particular advantage to either approach, and you can probably have a mix of each. As with most things there are a number of ways to achieve the same result. I wish you equal successful when you do get to that.