@Rich, I have voluntarily simplified your words... to make the message as clear as possible and prevent another misunderstanding.

But still I have subtly edited my post to be more correct...

PLEASE wait till i am done before anyone says it can or cant be done

I try to explain it easy for other to understand

AND i know alot about them since i have used them alot at work with my designs ,only coding i left for other departments and my circuit was perfect with them.

ONLY one design was change by them a little.

I am more of a expert on using multiplex chips,since of my long time testing and designing.

ON RICH coding it may or maynot be a problem until its fully tested ,but like in the other post instead of using 16 digital ports multiplexing can use two 8 multiplex chips and you getping info is solved

BUT also there is parallax that uses one digital line,and i have a simple circuit to make SRF04 work just like a parallax one wire PING sonar

THIS design may or may not work for all types of inputs ,very hard to tell will testing it first. I dont think i might have a problem with the coding since it looks simple

BUT there are many many other uses on ezb THAT CAN USE IT.

HERE is good question why does the internal circuit in EZB MICROPROCESSOR that uses multiplexing in design can use it to address the digital 20 ports and not the CD4067 ,same type of chip design?

ARC was built to use the EZ-B. The EZ-B is fully supported in ARC in all of it's functions. ARC was not built to support other microprocessors.

The main difference is your circuit is not addressed via the D0 to D19 ports. It isn't as though it adds D20 to D28 or D20 to D36. Therefore the functions built in to ARC will not work correctly with your design. Code and/or set digital controls are required as I have already pointed out.

All answers to your questions can be found in my posts. You may need to read between the lines a little but the reasons are there.

And again, not once have I said it will not work other than the ultra sonic sensor and GetPing if it is on two of these additional ports. I guess you aren't very good at reading, I can suggest some books to help, The Cat In The Hat is a good start.

For the record, I have not said I would not help with the scripts. Anyone who intends on using this design despite it's limitations is more than welcome to ask for assistance with the scripts to select the correct port number. Each script, each function and each robot will be different so I would not expect generic code to be posted in this "tutorial".

Edit to help the coding question just after I posted: A typical example script for selecting the desired port would be;

# Enable sub port 11
Set(d0,on)
Set(d1,on)
Set(d2,off)
Set(d3,on)

#Enable sub port 5
Set(d0,on)
Set(d1,off)
Set(d2,on)
Set(d3,off)

Each and every port needs the correct combination of ons and offs to set the correct port. It is done via a binary method so port 0 is 0000 or all off, port 15 is 1111 or all on, port 1 is 1000, port 2 0100, port 3 1100, port 4 0010 etc. Understanding binary to decimal is a huge part in selecting the correct sub port.

Once that is done then you send the command to the microprocessor i.e.

Servo(d4,50)

I'm sure you can see how much extra code is needed, how much more complex it becomes and how the conflicts may occure should two or more scripts run at the same time both needing to communicate with a device on the microprocessor.

End Edit

Now I am done with this topic. Do not refer to me if you do not wish for me to reply.

For anyone else, if they require my assistance please contact direct at [email protected] or start a new topic. I will not even be checking this topic again (and with that in mind please refer back to my earlier posts when deciding if you will use this circuit or not, I'd hate for you to be unsatisfied with the results).

Lots of love, hugs and kisses, Rich.

@Robomaker, don't get me wrong, having the possibility to add more digital ports to EZB could be interresting in big robots and big projects. But an easy integration in ARC is mandatory for me. It should not be more compex to handle that using 2 EZB.

You say that the coding shouldn't be a problem "since it looks simple"... Can you post a quick example of scripting or simple coding? I am interrested in evaluating the level of difficulty.

If you were to add more ports to the EZ-B, you will sacrifice communication speed. I do not recommend adding a multiplexor to the EZ-B for large projects.

By the time you source the materials, solder the breadboard and write the code... Your time is much better spent building robots and buying a second EZ-B.

DJ FIRST looking to sell the boards about $6 or less,and the coding might be more if you use a second EZB,then you are loooking at a drop in speed using 2 boards,needs to use bluetooth on both boards

Plus at back and forth communication.

Cant see how you would lose speed since is digital then using EZB with bluetooth,thats where speed it lost.

Most likely code will be made by me or someone else

IT only uses one chip ,plus radio shack board,plus connectors or straight wire ,no other parts.

Using a second EZ-B would need no extra code other than the board number in all controls and EZ-Script commands. All native controls in ARC would work regardless of port and board used. All EZ-Script commands would also work.

Not only would it be much simpler to use two boards, and tie that in with the costs of extra code (think of it as time writing scripts is time not doing something else, I value that time highly) it would be both easier and cheaper in the long run to run 2 EZ-Bs.

Your design will always have it's limitations as previously expressed. The GetPing EZ-Script command would not function correctly if the sensor is on two of these sub ports. Script commands on two or more scripts running simultaneously may have problems, which poses as a huge limitation on any of my projects as I have 4 or 5 scripts running at any one time, sometimes more.

All native controls would no longer be supported and would require scripts to operate, as a minimum 4 Set Digital controls to select the correct sub port so that the other controls would operate would be required. Running this with scripts running in the background also would pose a serious problem.

The same limitations would apply to an I2C based extender, which I had looked in to and decided against, however I2C would pose the simpler and less conflicting of the two methods. Native controls would not work correctly, if at all however the conflicts with scripts would be avoided.

Personally I would not wish to script around these limitations or script the extra code required to select the correct sub port. And this is the recommendation from someone who enjoys writing scripts. The extra code would be an educational guesstimated 5 times as much as that of using a second EZ-B.

Simple logic knowing both how the chips work and how ARC/EZ-Script work dictates that the above is correct and 100% justified in it's conclusion - building a practical circuit would have no benefit in finding the conclusion.

Not forgetting the issues DJ has mentioned also.

There are some applications where I can see the benefit of using this circuit however the limitations and extra work required greatly outweigh the benefits. To put it in plain and simple terms, it's a $60 saving in exchange for a lot of headaches.

This is for the benefit of those who are deciding on which method to use. This is not an argument against any design and as such is not open for debate. Users may use this post as they see fit and are free to disregard it should they wish to. All datasheets and documentation has been digested prior to this posting.