Multi-CPU-System based on BS2
andreas6583
Posts: 17
Hi !
I´am currently working on a multi-BS2p-system for larger model ships, using the I2C for a system bus and a couple of M24c65 EEPROMs as a blackboard for information and program interchange between the BS2p.
I wonder if anybody has any experience with I2C bus based inter-BS2 communication. Is there a way to switch a BS2p to "Slave Receiver Mode" other than creating a new subroutine for that ?
Using the blackboard works just fine and the I2C protocols manage the traffic magnificently with the help of a PCF8574 (I2C 8-Bit-I/O) as a basic IRC (POLL-commands for interrupt control). But a direct link for faster information interchange (e.g. for navigation or fast command transmission when the system is used in fast moving robots)...
Since I am not that experienced with the BS2 yet, it really would help me a lot if I could find some people to discuss this project and to get in touch with some other BS2 enthusiasts !!!
Thanks very much in advance !!!
Andreas
I´am currently working on a multi-BS2p-system for larger model ships, using the I2C for a system bus and a couple of M24c65 EEPROMs as a blackboard for information and program interchange between the BS2p.
I wonder if anybody has any experience with I2C bus based inter-BS2 communication. Is there a way to switch a BS2p to "Slave Receiver Mode" other than creating a new subroutine for that ?
Using the blackboard works just fine and the I2C protocols manage the traffic magnificently with the help of a PCF8574 (I2C 8-Bit-I/O) as a basic IRC (POLL-commands for interrupt control). But a direct link for faster information interchange (e.g. for navigation or fast command transmission when the system is used in fast moving robots)...
Since I am not that experienced with the BS2 yet, it really would help me a lot if I could find some people to discuss this project and to get in touch with some other BS2 enthusiasts !!!
Thanks very much in advance !!!
Andreas
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Maybe you can use one BS2p as a master, that is connected to the EEPROM and have the other BS2P communicate with the master via open-mode serial to get/store data from the EEPROM.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
Forget about the past, plan for the future, and live for today.
·
Yes, I did not realise that it might be the speed that prevents the BS2 to be capable of the "slave receiver mode"... But since the I2C transmission rate is controlled by the sender, would it not be possible to slow down a transmission to allow the receiving BS2 to adapt ? Of course, this would be a drop in performance, and then the blackboard solution might probably be the faster one again...
Is there any experience in operating multiple BS2 as a network of specialized subprocessors ? (I found nothing of that sort in the ressources or the forum so far....)
All the best,
Andreas
http://www.parallax.com/dl/docs/cols/nv/vol3/col/nv81.pdf
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Btw.: Working with the BS is great and you are doing a great job at parallax !!!
I read this, I jumped into my digital simulator, made a quick thinggie, made sure the logic was there... and came here to post it and found this... the ariticle posted by Jon.
Much better then my answer...·· Any way, my answer required intrupt polling on both master and the slaves... up to 8 slaves with 7 pins from the controller (that would be 16 slaves with 8 pins from the controller...)... direct connection... BUT... if there's a programming error in program... could result in dead pin / stamp... so... add the 1K R's to the layout I made, and you have a very expandable multi - bs2 network...
basic operation is...
{Setup}
· Slaves in pollmode on P0
· Master in pollmode on P14
{Get Data from a slave}
· Master sets slave address on P0~2 and sets enable on the 3-8 decoder (74138)
· Master toggles P15 ("ATTN!")
· Master waits on P14 to toggle
· Slaves respond by checking if their select pin is high (P3)
··· IF Not high -> THEN
······· clear the intrupt and go back to doing what they were doing
····· ELSE
······· toggle P1 (lets the master know slave is ready)
······· SERIN on the P2 Line
······· {Execute the COMMAND}
··· END IF
· Master does a SEROUT on P13
From this, you can work out other commands like:
(?) Master Requests data
(?) Master Sends Commnad
(?) Slave requests data
(?) Slave requests Command
(?) Slave requests send data to other slave
(?) Slave requests Command to other Slave
With something like this, it's quite plausable to use 1 master BS2, some creative addressing with 3-8 or 4->16 decoders ...
Example:
1 74154 providing 16 BANK selects,
16 74154's (one for each of the 16 bank selects) providing for 16 BS2's = 265 stamps...
Total cost of pins on the Master = 8 for addressing, 2 for enable lines, 3 for controll = 13 lines
And with ROOM left for EEPROM access!
No matter the number of BS2's in the layout, each slave needs only 4 pins to make it work...
I've attached a PDF from my simulator (sorry about the way it looks, I haven't figured out all the options of PDF creation yet)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
You mentioned a sinulator... Which one are you using ?
I've made some templates for the BS2P24 & BS2P40 stamps...
When I go to simulate the logic, I use the seqence editor for the pins I need to simulate on the BS.· It gives great feedback for the digital stuff, but no help what so ever on the analog stuff.· I've gone as far as to make some templates for current limiting reistors (geez, it's late and I can't spell!).· On one of these threads I've seen a list of commly used values, I'll have to dig that list up.· (poke, poke, knudge, knudge, klue, klue)...
If you want some other ideas... let me know, I've a few others I could share... each with it's own pro's and cons...
KK
I would like to take the opportunity to tell about the system I have started to build, so I can discuss it with some people who know about the BS2... (Unfortunately it´s still hard to find anyone in Germany who uses the BS2 in any other way than using some custom board and -more or less- complete software packages...
I hope this is not too boring...
Well, I started this project to create a means of controlling model ships with numerous special functions.
It all·started with a small model of the USS. Missouri (see Photo) and a small double BS2p board to control it, still using a RC-control and just reading the receiver ´s signal and modifying it with the BS (one BS2p for continuous I/O control and to operate the servo controller, one for receiving control commands).
Even though I never finished the model itself, I had quite some success with the controls. The reason for not finishing the model was that –seeing what was possible- I wanted more automation... I wanted a robot brain suitable for the use in any such model and found that the very basic control system I set up at first should be extended to a full featured computer providing not only the brain for my ships, but also an extensive·array of binary I/O (merely switching on and off special functions), sensor inputs (navigation, water, smoke, ...) and -of course- servo control ports. So I put aside the Missouri for a while and started on a full featured control system.
·
The result of this was the design·for a·multi-BS2p robot brain with -in a first step-·up to 8 BS2p working together.
(see PowerPoint-File for functional schematics)
·
The base for this system is a dual BS2p unit with a "command processor" (COMM, CPU 1, BS2p24) and a “control processor” (CON, CPU 2, BS2p40).
I used the I2C bus to create a simple system bus to which the "primary" I2C interface of each BS2p (pins 0/1)·are connected to. To avoid handshake other than that of the I2C, I decided to·add a system "blackboard", made up of up to eight EEPROMs 24c65 (I2C, 16kBytes, a total of up to 128kBytes) connected to the system bus for information exchange between the processors. The idea was to not only have data transferred from one BS2p to the next but also of course to provide a system memory·to store programs for operating the functions on the models.
·
Since each BS2p needs to·read the information stored on the blackboard as fast as possible, I added a PCF8574 to the system bus as a simple interrupt controller.
·
For each BS2p -apart from the I2C system bus- I provided·a private I2C bus (pins 8/9 on each) to be able to attach any interface hardware I might find useful.
Each processor has its own additional private memory attached to this bus, which also can be made up of up to·eight 24c65 (128kBytes again).
This allows creating various customized processor boards to add to the system.
·
The COMM CPU is also fitted with three PCF8574 to have immediate control over 24 bidirectional I/O-ports and a connector for the DS-FWCM wireless module·available from·Total Robots.
Apart from the I2C, the COMM CPU also has connectors for two Parallax servo controllers, a serial LC-display, four channels of a RC-receiver and a small extension board with additional hardware.
The CON CPU on the base unit is equipped only with four private 24c65 and connectors for -again- two servo controllers and a serial LC-display. In addition to that, all·availlable pins and signals are routed to a connector to provide the means to connect a·"sandwich"·board with additional interface hardware and/or memory.
·
The purpose of the COMM CPU is to manage the system. It receives incoming commands (RC and/or wireless), distributes the commands to the appropriate processor, manages incoming program sequences (see below) and controls the system blackboard.
Since the other processors operate almost autonomously, the COMM CPU is not needed to do too much work managing the system. So there is still enough room for operating the I/Os on the private bus.
The CON CPU on the other hand·is meant to provide and control I/O-ports to operate the model´s major special functions (lights, sound, radar, etc.) using a separate I/O-Board. (Not finished yet). Of course ther can be more than just one CON in the system.
·
Using a·system extension connector on the system bus, special CPU boards can be added on top of the base unit. I plan to have a number·of boards such as sensor arrays, navigation and I/O. Almost anything in any combination is possible here.
The idea about that is to have an open system with·specialized units for certain tasks and only something like a moderator to coordinate the units "work".
So how does this system operate a model:
·
When this "brain" is built into a model (not necessarily a ship)·the user uses either his RC sender or another BS2 based system to transmit control commands to the model. With the system it is possible to issue single commands such as "ahead full" (instead of operating some joystick) which will be executed immediately by the processor concerned·by this command.
Each command issued is addressed to the model, the specific CPU and a specific I/O-port, interface, sensor or function.
For each model, the system can be customized by adding the different processor and interface boards to meet the requirements. On startup, the COMM CPU determines the type and configuration (ports, sensors, etc.) of each processor attached (each processor determines its own private config and periphery and writes that to the blackboard) and will therefore be able to forward the commands correctly. Of course, for each model the user will have to make up a table of processors and ports (...)·and their functions, logically linking a function on the model to a specific port and processor. This table is created using a PC software or the BS2 based remote control and then downloaded to the COMM CPU.
·
That means for example, that if the command "ahead full" is received by the COMM CPU, the command will be sent to the blackboard position of the CPU in charge for·propulsion, this CPU is "interrupted" (using the PCF8475 on the system bus and the poll functionalities of the BS2p to be addressed), reads the command and processes it·to give the appropriate PULSOUT or servo controller command to drive the motor control accordingly.
It is the same with any other possible·command.
For the time being, I have not yet implemented the automatic detection of which commands are legal for a certain configuration of the system, but I plan to do that·using an extended configuration table (mentioned above) providing a certain set of commands for each type of board.
·
Of course, when it is possible to issue single commands, the user can also use command sequences. The user can enter a list of commands, which will make the model do all the “programmed” manoeuvres when transmitted to the system. (Somewhat like an interpreter on the BS2...)
·
I plan to integrate operating sensors and navigation in the list of commands to make it possible to link certain commands to a certain input. This would make it possible to e.g. link the “ahead full” to “if ahead is clear” or to have an automated docking sequence for the model ship based on measuring speed and distance …
With the right sensor arrays and navigation, a number of up to 254 models (depends on the wireless module provided by TotalRobots) could be operated to display a whole scenario with units that operate autonomously but in relation to each other (this would probably require a “team processor unit” *smile*) Of course, there is a long way to go to have this (but wouldn´t it be great to have a display of the Battle of Midway or D-Day in this fashion ?)
·
The system hardware itself is very simple and the most complex –if you can call it that- thing about it really is to make the layout. As can be seen on the photo, I made a layout for a 10x16cm double layer board leaving loads of space for the sandwich modules for the two CPUs.
·
The system works absolutely fine with the test routines I have programmed so far. I have not yet fully completed the software for the base unit but the basic functions such as the init-routine with hardware detection, the use of the system blackboard for information and command interchange, receiving and processing commands (wireless from another BS2 system and via RC) and the control of servos using the Parallax servo controller are already operational.
·
Even though I had some doubts about it at first, I found the I2C highly efficient as a system bus for such a purpose, especially because the implementation of the I2C protocols on the BS2p is great !!!
Since this is an open system and only limited to eight processors because of the PCF8574 I chose for an IRC, it could be extended enormously adding processor boards not only to the system bus but also to any “private” bus of any processor already operational in the system. One could easily imagine what a complex system this might become an what possibilities one has with such a system.
Of course, this will never be a high performance AI-capable system, but in my opinion it is absolutely great for automation !!!
·
For the time being this is just a hobby application but once the system is working OK, I would like to make it a product for the market.
I hope I could give you a good overview on my project. Of course I would be glad to hear your opinion about it !!!
Big plans... Big Ideas... and a better idea...
Instead of going for "hard addressing" (ie chip based addressing), 4 Pins and "soft addressing" would be better...
Looking at your design, each CON stamp would have it's own program, so there for this works real well...
What you would do is use 5 pins (the same 4 pins as before and 1 more for busy/ready), but code the CON's address into it's program...
Then the program would be more like:
{Setup}
Master sets polling on "REQ Line"
Slaves set polling on "ATTN Line"
{SendToSlave}
Master pulses "ATTN" line
All Slaves exexute SERIN on "DATA" line
Master executes SEROUT with the address of the 'target' slave'
'Target' slave toggles "READY" line
All other slaves set Ignore ATTN and DATA lines until READY line goes low.
Master executes SEROUT with the command for the 'target slave'
Master watchs REQ line for recieve
Target slaves Pulses REQ line when CMD is recieved
Master executes SEROUT with data for 'target slave'
Master watches REQ line for recieve
Target pulses REQ line when DATA is recieved
Target Toggles READY line
All Slaves return to polling / waiting loop
Using this design, an unlimited number of stamps can communicate
Also, this could be software designed so there is NO master... Any address can communicate with any address...
Well, just another idea... [noparse]:)[/noparse]
KK
serout pin, baud, [noparse][[/noparse]"A1", data]
but only the Stamp whose program said:
serin pin, baud, [noparse][[/noparse]WAIT("A1"), data] would receive it.· All other Stamps would ignore it because they have a different WAIT("???").
Sid
That's fine, but just make sure that "baud" is one of the OPEN baud mode configurations. That will provide the quasi-multi-drop ability without fear of damage to any of the Stamps. In other words, one serial RS-232 line serving ALL of the Stamps.
Regards,
Bruce Bates
The point is that if you have a system like that you might not want to change the the adress each time you combine CPUs differently. Ok, it could be done like the MAC of some Ethernet device, but then the user would have to deal with these adresses when he sets up the system.
I thought about some sort of daisy chain where each processor recognizes on which "interrupt"-position it was placed and writes it´s configuration (something like a ressourcelist) to the appropriate position on the blackboard so all other CPUs can check that.
In this way for example you could have two or more identical CON-CPUs with I/O on the same system and the user would only have to create a CPU and port map like this:
Unit1-Port5-Lights
Unit1-Port6-Turn Radar
Unit2-Port1-Anchor up
Unit2-Port2-Anchor down
and so on...
So he would not need to adress a certain CPU, but only to link the lights to unit 1, Port 5, download that to the system and after that just issue "LIGHTS ON" or "LIGHTS OFF" and let the system do the rest...
This works fine with the two BS2 I have on the system until now, especially when the modules on the "private" bus of the BS2s are changed...
Of course, the init-routine for this already fills a whole slot and this can be a problem...
BUt what I have to think about is assigning an adress automaticly... Something like DHCP for the BS2.... Maybe I could do both... The normal, slower communication using the blackboard and your suggestion for emergency messages and commands.... ... with the different CPUs getting an adress from the blackboard an defining who has which adress in a sort of ARP table... Hmmmmmmmm... Nice new perspectives for spending my weekend....
Thanks very much KK !!!
I will keep on posting about this of course !
Hope to hear more from you and others !!!
Andreas
Any time... there are other answers as well.. and the idea... DHCP for the BS2... Hmmm, now I'm scratching my head... interesting idea...
DHCP Plug and Play for a BS2 network...
(Hmmm, more like DHCP Plug and Pray..)
[noparse]:)[/noparse]
Post Edited (KaosKidd) : 12/16/2005 5:33:56 PM GMT
seem like I am a bit slow today but I only just realized that your proposal means that all the BS2 would be communicating on a broadcast basis... So this would -of course- interrupt all functions until each CPU has checked verified the destination adress.... This is just right for emergency messages but would probably be a bit disturbing if there is too much traffic...
More on Monday... if I can make the time....
The nature of this·question now is what other chores does the·'master' have to deal with, which will·directly affect it's ability to·effectivaly manage the number of transmissions in question.· In the real world, most·closed controllers spend only 20% of their time in actual communication routines.· I sould explain that this is a closed system, as the slave provides feed back (which could be a fail safe in the system!).· If it were an open system, it would be like the internet, where as packets of data can be lost, and the 'protocall' would have to re-request the data.· Anyway, back to the topic at hand:· The BS2 could in theory max out at an estimated 800000 'transactions' per second.· This is estimate is based on 28.8 kps (and we all know it can do SER operations faster then that), no other chores other then transfering data between slaves, running at the estimated 12000 instructions per second.· Lastly, using flow contol to prevent collisions and bus contention, the number drops to roughly 70,000 'transmissions'.· I would love to test my math out to see just how close I really am, but I can't so I'll·provide for a 10% error in my 'rough' math, and that still is an impressive 63000 transmissions, just slightly below the wire max at 67200 @ 28.8 kps.· Make it 33.6 kps and there's no way the slaves can max the bandwith.
Do you really think that an simi automatus object would require more then that much bandwidth / power / intercommunication speed?· The reality of it is, the entire system will spend more then 70% of it's time waiting on user input.· 10% of it's time in automated replies to user input, the remaining time spent in communication with other units and overhead.· I agree with you, I wouldn't go with a 256 stamp network like this (for that, I'd impliment a hardware banked AND broadcast bus (like a segmented TCP network)), but a 16 -> 32 stamp network, it's a no brainer for me [noparse]:)[/noparse]
Hmmm... there's an idea...· ...· Ok, you have an good weekend, I';m gonna go see if I can find that 'TCP on a chip' chip·that I read about some time ago...·Ok, that's just my .02 cents worth..· [noparse]:)[/noparse]· Catch up with you later..
KK
I tested the serial connection you proposed. It works absolutely fine ! Still, I found that handling the IR for switching all CPUs to a listen mode together with the other functions (operating the private ports... etc.) that have an effect on the interrupt handling routine·had quite some effect on the operations on the private bus.
So I decided to do things a bit different:
Normal communication will remain on the blackboard. This allows the CPUs to operate independatly just as I described before. But I see the necessity of "all system commands" meaning such commands that are used to force all CPUs to do certain (emergency) tasks at once. A system emergency stop could be one and certainly a system re-initialize an other. These commands·are broadcasts and it would take much to long to issue these on the blackboard for each CPU separately.
So,·Rev 2 of my board will have an additional interrupt line and a serial "bus" running between all CPUs to use such a feature.
I also have given some thought to give an·adress to each·CPUs or to have them get one availlable from the blackboard. In order to enable·allow emergency·commands to be adressed to a specific CPU only, I implemented a "passive BHCA (BS2 Host Control Adress) server" on the blackboard... (
The COMMAND CPU as the master copies the whole table to be able to adress any CPU in case of an emergency. All the other CPUs use the table similar to the ARP-table, looking up the appropriate adresses if a CPU-CPU direct communication is needed.
I will keep you posted and -of course- always be happy to read about other ideas !!
Merry Christmas everybody and all the best for 2006 !!!!!!
Andreas
KEWL! I do want to see your layout... Question: Did you purchase the Proteus package? It's beyond my budget to afford that. How are you keeping the same address from being used by two stamps? The issue here is this: Being all stamps are created the same, each will start at the same time, and there fore ask for the next available address at the same time, thus creating the inital and identicale issues found in win 95->98 plug and play, correctly renamed plug and pray. Now, unless you featured a hardware time delay for each stamps power connection, sort of like SCSI drives use a delayed start to prevent pwoer supply spiking, you will encounter the probability of two stamps getting the same address. A quick fix is to stager the power up lines to each stamp in the system. In theory, any delay will prevent the "collision", but lets say that after the master powers on, each slave in the system will power up in like 250 ms intervals. An example would be for like this:
After the Master turns on, the delay starts... then, after the first 250 MS, the first slave, the next 250 MS, the next and so on. THis way, the code for getting the address is the same for each slave, the actual address used is dependent on startup position, not address settings in the program or on the stamps board. That would also ease up the demand on the power supply during start up, remove the chances of address conflicts, and it's simple enough to impliment.
A very merry christmass to you and your family...
KK AKA Fred
Thank you very much !!! I hope you had a wonderfull Christmas as well !!!
I did not do much over Christmas but since I had some time to think about my system...
Though I have not tested it with more than two BS2 in my system, I am counting on the I2C protocol to do loads of things for me...
First, I could not make out clearly from the manual how the BS2 works on the I2C regarding the check for bus availlability. Normally an I2C device checks for the bus to be availlable before generating a start condition to send... If that works with the BS2 as well, all CPUs will determine their "private" configuration by probing their private I2C on pins 8/9. The COM CPU does the same for the system bus. If that is done, each CPU can access the blackboard to publish this config and of course register for an adress. Given the operations of the I2C system bus, only one CPU at a time will be able to communicate with the BB. So it is a defined process with some real CSMA/CA.
To avoid duplicate adresses, I use a table on the BB which links each availlable adress to a specific CPU-ID:
Adr.· ID
01··· 00········ meaning that adress 01 is assigned to the COM CPU
02··· A1········ meaning that Adress 02 is assigned to the CPU with the ID A1
03··· FF········ meaning that adress 03 has not been assigned yet (I chose FF as the indicator for that)
Each CPU simply checks for an unassigned adress and·assigns its ID. So all the CPUs add themselves to the·list forming something like an ARP table. This way no doubles are possible.
If the BS2 does not support the check for a free I2C bus, I will simply·halt each CPU and use the PCF on the system bus to trigger each to continue. An other soulution could be a sort of daisy chain with each CPU triggering the next after config has been written and adress registered. The chain could be according to their position on the bus...
I don´t think·the use of timers to control this would be a good idea because the different CPUs (CON, NAV, OPS) might have different startup times and might appear in the system at any position ! This would be a problem if the positions were changed. It would be necessary to always determine the longest startup period of a module·linked to the system and adjust all other CPUs to that time. Or I would have to define a standard delay to cover all modules.·I want this as flexible and open as I can make it and with timers·operation·of the system·might even depend on a software update, which might change the startup time of a CPU module... So it might be roulette to some point if you combine different modules, even just different releases or if you change positions... Indeed, the processors would have to calculate their delay according to their position...
I know the guys who play around with model ships... What they accept is just some device that integrates easily without too much trouble or programming... So troubleshooting is pretty much limited to checking voltage, current or capacity. They wouldn´t check for releases or something like timer problems or module positions... They just click the thing together and put it in... So apart from what I posted earlier (how to link CPU and ports to specific functions), the user should not be required to change anything in the system´s hard- or software... I want to avoid any problem of that kind...
The attachment is the designe for my base unit with a BS2p24 and one BS2p40. It is not very complex and I left out some capacitors that might be recommended, but the board works perfectly fine the way it is... The serial (RS232) bus is not implemented yet. I did the design and the simulations with the Proteus package... I purchased the software for the company I work for... I do the technical training of our IT apprentices and usually put up a number of microcontroller projects. Last year we did a hexapod robot, this year we are working on a wireless order system for the drinks at our company´s summer festival. It is real fun and Proteus helps a lot to save costs because its simulation feature !!! This package is worth every penny !!! I can only recommend it !!!
Well, enough for now. I really like to hear more and to learn about other ideas !!!!
CU
Andreas
I hope this caveat below, as found in both the I2CIN and I2COUT commands from the PBASIC Help File, won't spoil your plans:
"Also note that the I2CIN command does not support multiple I2C masters and the BASIC Stamp cannot operate as an I2C slave device."
I would add to that, that I don't believe these I2Cxx PBASIC commands support the General Call or "broadcast mode" as described in the Philips I2C Specifications either. There may be other differences as well.
Regards,
Bruce Bates
Post Edited (Bruce Bates) : 12/27/2005 11:31:45 AM GMT
Yes, I read these lines... And I think you are right. But still I·would like to see the effects·a collision·on the I2C has on the BS2... If an error occurs that·can be caught and processed somehow, it would be possible to create a work around...
If it is not possible, I will just use the PCF for the time being... Just one or two lines of code that´s all... When I designed this, I always had more than one function in mind than just using the PCF as·some basic·IRC...
All the best,
Andreas
For those who are interested, this is the model ship I intend to equip with my little system...
It is the model of the German SAR·cruiser Adolph Bermpohl. With a length·of 126cm and a width of ca. 30cm, it provides sufficient space for a number of special functions.
Of course, basic stuff like switching on and off lights, turn the radar, drop the anchor is nice. But I think that making a robot like model out of it is much more fun. Especially with it´s fully operational rescue boat (not shown in picture) that is usually carried in the aft bay, it will be loads of fun !
The aft bay can be opened and the smaller·boat ususally carried there can operate on its own. My plan with the multi BS2p system is to have both models operate together without any RC required for certain manoeuvres such as DROP, PICK UP or more complex "rescue missions"...
The smaller model has a single BS2p and a wireless module obtained from Total Robot in GB. The Bermpohl in turn has the MBS2p with another wireless module and is able to issue control commands as well as receiving controls from shore..
Of course.·first of all I want the MBS2p running ok. Then I will go for the necessary sensors and subroutines... But this is in brief what the system is intended for...
You seemed to be focusing on 8-bit port chips, and you can get more ports than that, on a per chip basis, and probably save some PCB real estate. So too there are some interesting I2C LED dimmer chips so when the smoke machine kicks out some smoke, you can dim the lights and appear to be going through a FOG! How's that?
Check out these Philips Semiconductor chips:
PCA9555 16-bit I²C and SMBus I/O port with interrupt
http://www.semiconductors.philips.com/pip/PCA9555.html
PCA9532; 16-bit I²C LED dimmer
http://www.semiconductors.philips.com/pip/PCA9532.html
Regards,
Bruce Bates
Awesome layout. Nice approch to sharing / storing data between uints. I'm not sure how the I2C will work in this case, because of the BusMaster issue with the BS2's, but you seem to have that worked out. I wasn't even thinking about the I2C, I was sort of creating my own protocall, but what the heck, if it works, why reinvent it, right? Real nice modeling... Long time ago, I was into planes, but sence the advent of Kids, thats come and gone. Now I'm starting into trains and some other nifty thinggies. [noparse]:)[/noparse] Real slick layout, nice.
PS: Bruce: Thanks for the tip! I'm already checking out the specs on the chips... [noparse]:)[/noparse]
Have a Merry, Happy and Safe new year all!
KK
Ever look into the canbus that parallax sells? Looks like a good way to set up a controller network using stamps. And mbus also sells an i / o expander. Maybe not what you want, but just thought i'd give it a mention.
kelvin
Bruce:
I´ve been doing a lot with a number of microcontrollers, but my favorites are either the 80c552 or the 68070... The problem is that many of the "bigger" controllers have more features than one needs or require extensive programming using expensive SDKs of some kind... Really, using the BS2p is absolutely great because it is easy and straight forward ! Especially with Parallax giving awany the SDK for free...
I built a MCPU system with four 80c552 once. It was based in I2C communication as well. It worked absolutely great·and programming the protocols for the I2C·dataexchange was quite ok... But I did not like the programming of special functions (such as servo control...) very much. Also it was not easy enough to integrate this system in a model because the layout was by far more complex and needed a larger board... Anyway, I certainly will check out the chips you proposed !·Thank you very much for the hint !!!·Maybe there´s even another project in sight...
KK:
Thanks for the compliments on my design... But that´s just some normal stuff pretty much all BS2 users use one way or another I suppose... Well, as you can see from the schematic, I used the PCF to have a work around for that busmaster thing... Still it might be necessary to sacrifice another pin on each BS to generate a BUSY signal for the I2C, but for the time being I will try to do this in software. For two BS2 it is ok like it is, but I have to give it some thought for the full complement of modules I have in mind...
Kelvin:
Thanks very much ! I haven´t checked the canbus yet eventhough I came across it several times before without really thinking about using it. And being as perceptive as I am I must have missed that on the Parallax homepage... But I will check that, too !
I would like to grab the oportunity and extend the topic a bit towards the modules I have in mind... I have no problems with I/O modules, because·it is quite simple to have a number binary ports with some transistors, couplers and stuff like that doing what you want...
But the sensors still give me some trouble... I actually dream about a ultrasonic sensor with a range·some 20m, combined with an electronic compass and something like a sonar (since it is all about a robot ship...) in one nice package with a BS2 controlling it... I have some vague·idea about the sonar but nothing practical.
Any ideas out there ?
All the best,
Andreas
www.neobotix.de/en/products/Components.html
Too bad they are in Denmark, i don't know the price and they state it as low cost, but i quess it depends as to who is looking to buy it. Kinda looks like a high end PIR sensor? with great resolution, and can see through wood and plastics, which is not only really cool, but kind of like " what the hell?"
If i needed a good sensor for a boat locating objects/ targets on the water, this would be it. It gives velocity, positional and directional data at 20 mhz, and even better, it communicates easily by rs232 or canbus. The specs are that it can detect " human " presence at 30m, obviously heat, which is very good, metals and such it doesn't really say, but the sensitivity is configurable, so it may vary on the application. I have been sitting around waiting for an affordable hobbyist laser scanner to show ( other than the SICK one that is way above my budget ) , but it don't look like that is going to happen soon, so i may try one of these puppies out, if it doesn't cost an arm and a first born. Adding the pdf doc to this, hopefully it views okay.
kelvin
well·this looks·promising ! Not only because it is about what I looked for but also because NEOBOTIX seems to be in Germany, not in Denmark... Thanks very much for pointing me there !!!
I will get in touch with them to find out about the price and whether the sensor could be mounted at some distance to the board itself... Having a real working radar would not look so great if it was totally out of the scale of the model...
I will keep you posted on this !!!
Once again: Thanks !
All the best,
Andreas
Some news about the NEOBOTIX - RADAR board... I received word from NEOBOTIX yesterday and they told me that the board is designed for speed measurement only. It is not able to scan. In addition to that, it is still under devellopment.
For those who are interested in the board nonetheless, for (just some) more information you can check the download area on the NEOTECHNIX homepage. The NEOBOTIX-homepage only has restricted access to the documentation downloads.
I hope I will be able to work on my project in the next couple of days and hope to make some more progress...
All the best,
Andreas