Author Topic: Community Project - Module Housing (Read 24286 times)

dellagd · « **Reply #60 on:** April 27, 2009, 02:17:53 PM »

I like the idea of having a node that is just a breadboard and I/O pins. correct me if I am wrong. I²C is like a network that allows microcontrollers to communicate with eachother?

Asellith · « **Reply #61 on:** April 27, 2009, 04:03:40 PM »

The point of using I2C is to make it plug and play well sorta plug and play the main controller needs to be told what to do and if the programmers of the modules do the extra work and develop libraries for each then it is the MCU version of plug and play. This I/O board you want will need to be able to talk to the main controller some how. The main MCU will have a limited range of I/O on its board. Be it the axon or a whatever. An I/o Extension board is not a bad idea but it will still need an MCU to talk to the network. I/O interupts can be messy when using with a mapping program or something along those lines. But if the interupts where handled by their own I/O module and the only thing that happened would be the I/O board would take control of the bus and send info to the main controller when needed. Or if all it does is a programmed motor response then the main mcu just needs to be told it happened and it can go on mapping the room or whatever it is doing while the I/O board talks to the motor controller.

SmAsH · « **Reply #62 on:** April 27, 2009, 04:32:47 PM »

i am really happy to take a look at uart, but it just seems more complicated for beginners to get a grasp on.
about the programmer issue, i really think usb should be a standard or some form of communication that lets usb take hold, maybe a 4pin header the user can plug into that has usb on the other end? most people don't really want to buy a programmer as the good ones are a bit expensive or they don't have a serial/parallel port...

dellagd · « **Reply #63 on:** April 27, 2009, 05:02:18 PM »

a MCU can also be a slave on a I2C network right?

Asellith · « **Reply #64 on:** April 27, 2009, 05:07:01 PM »

Yes actually most modules will be slaves. There will be very few modules that will not have some sort of MCU on them.

SmAsH · « **Reply #65 on:** April 27, 2009, 06:31:59 PM »

so, the "master" is the device that is allowed to request info from the other devices. a "slave" not not allowed to request anything but only reply to a master. this is why slave devices are much easier to code because all thy have to do is the dirty work and reply to the master. and i thought for i2c all modules would have to have a microcontroller of some sort if they weren't pre-bought?

dellagd · « **Reply #66 on:** April 27, 2009, 06:43:39 PM »

I am pretty sure you are correct smash

TrickyNekro · « **Reply #67 on:** April 27, 2009, 07:29:14 PM »

having more than one master on the bus requires protocol.... that's for sure...
And implementing a com protocol isn't for absolute vodkas.......

Asellith · « **Reply #68 on:** April 27, 2009, 08:49:35 PM »

I2C is a protocol. It inherently handles multi-master. Each unit master and slave have an address. Only difference between a master and a slave is the ability to take control of the bus. Each node waits for the bus to be clear and then takes control by initializing the start bit sequence. Then it transmits its messages and waits for its response. The slave just wait for a master to tell them what it needs them to do and they send back an ACK with or without data depending on what the slave is doing. Any master can take control as long as the bus is not being used.

SmAsH · « **Reply #69 on:** April 28, 2009, 03:08:24 AM »

so, to sum it up. the reason I2C is a good interface to have is because its faster than just using I/O pins because the other microcontrollers (slaves) do all the time consuming and repetitive tasks then let the master take care of the decision making?
and, psssst guys this topic is about the module housings! not communication protocol. if you see needed start a new topic about that

TrickyNekro · « **Reply #70 on:** April 28, 2009, 05:08:04 AM »

Even though you "have" a I2C protocol it's not the protocol I talk about...
Imagine multiple masters co-existing in a same bus....

There MUST be a router that sets the timeslots for each to speak, then the speaker should inform
how much he will speak and with who....

I2C is a method of transmitting data, not a way to behave in public places...

hazzer123 · « **Reply #71 on:** April 28, 2009, 05:23:15 AM »

Multi-master I2C requires no router or time-slotting.

Either one master starts transmitting and the others be quiet, or multiple transmitters start transmitting at the same time and they have a 'race'. The winner of the 'race' is the master which sends out a message with the most zeros (ie the lowest message byte). Each of the other masters realise that they didn't win the 'race' and then they wait their turn.

TrickyNekro · « **Reply #72 on:** April 28, 2009, 05:27:40 AM »

Am I confusing something or data collision is a hole in water for every device???

SmAsH · « **Reply #73 on:** April 28, 2009, 05:28:55 AM »

Quote from: TrickyNekro on April 28, 2009, 05:27:40 AM

Am I confusing something or data collision is a hole in water for every device???

explain?

hazzer123 · « **Reply #74 on:** April 28, 2009, 05:35:05 AM »

ok the data lines are pulled up. So to clock data out, the devices either let the line go and it will be pulled up to +ve (for a 1 bit), or they pull the line down to negative (for a 0 bit).

Say master 1 wants to transmit byte 00101001 and master 2 wants to say 00100101

First both say 0 - they have no way of telling that there is another master on the line so they both carry on.
Again both transmit a 0 - again no way of detecting another master
Both transmit 1 - still no way
Both transmit 0 - "
Master 1 transmits 1 letting the line go free, master 2 wants to transmit a 0, so it pulls the line to ground. The line actually is in '0' state. Now master 1 can detect another master on the line. So it quits and waits its turn. Master 2 is oblivious to this and carries on happy.

The byte which is transmitted is 00100101.

The nice thing is, if both transmit the same bytes, they never realise and they don't need to realise. So its doubly quick compared to a time sharing system

But thats a very extreme case...

dellagd · « **Reply #75 on:** April 28, 2009, 05:38:20 AM »

I am confused here too
of course it would be better if they just had a race (I rooting for master #2

)
but I think Tricky is right. 2 signals can't travel on the same line as far as I know.
but hazzer could also be right. I just don't know enough on the subject to make a definitive answer. also we really need to move this conversation. Right now I am making a new topic "SoR Project - protocol".

EDIT: now I get it. makes sense. I see what you mean hazzer. I post just as you were

SmAsH · « **Reply #76 on:** April 28, 2009, 05:40:23 AM »

so your saying there would be no problem with them interfering with each other?
and as i said before this thread is called "module housing" for a reason! http://www.societyofrobots.com/robotforum/index.php?topic=7778.0
post this kind of stuff there!
dellagd, imagine two fat guys (masters) running to get into an elevator (line) which ever one gets in first gets in... the other fat guy realizes that the other guy is in the elevator and waits for it to come back (finish transmitting). sorry, needed an easy way to remember...
EDIT: oh shiz, dellagd beat me to it

dunk · « **Reply #77 on:** April 28, 2009, 06:51:00 AM »

Quote from: hazzer123 on April 28, 2009, 05:35:05 AM

ok the data lines are pulled up. So to clock data out, the devices either let the line go and it will be pulled up to +ve (for a 1 bit), or they pull the line down to negative (for a 0 bit).

Say master 1 wants to transmit byte 00101001 and master 2 wants to say 00100101

First both say 0 - they have no way of telling that there is another master on the line so they both carry on.
Again both transmit a 0 - again no way of detecting another master
Both transmit 1 - still no way
Both transmit 0 - "
Master 1 transmits 1 letting the line go free, master 2 wants to transmit a 0, so it pulls the line to ground. The line actually is in '0' state. Now master 1 can detect another master on the line. So it quits and waits its turn. Master 2 is oblivious to this and carries on happy.

The byte which is transmitted is 00100101.

The nice thing is, if both transmit the same bytes, they never realise and they don't need to realise. So its doubly quick compared to a time sharing system But thats a very extreme case...

hu?
sorry Hazzer but no.
in a multimaster i2c system a master that wants to take control of the bus takes control of the SCL line.
if the SCL line is high and does not have another master's clock pulse on it then any master can presume the bus is free.
any master can pull the SCL line low for a clock pulse signaling to all other masters that the bus is busy.
on vary rare occasions 2 masters might take control of the bus at exactly the same time so testing for this must also occur.

TrickyNekro, i think this answers your questions too.

dunk.

hazzer123 · « **Reply #78 on:** April 28, 2009, 06:55:46 AM »

Hmm u sure? I have seen the system i described in a different protocol. And from this page it seems the same.

Ahh well, i guess the important thing is that it supports Multi-master and is implementable.

EDIT: maybe the thing i read is the way to sort out the rare condition where they take control at the same time.

EDIT2: Oh.. here is some more info - http://www.esacademy.com/faq/i2c/general/i2carbit.htm - it's called arbitration -

I'm quite sure now that i was correct...

dunk · « **Reply #79 on:** April 28, 2009, 07:15:45 AM »

Quote from: hazzer123 on April 28, 2009, 06:55:46 AM

EDIT2: Oh.. here is some more info - http://www.esacademy.com/faq/i2c/general/i2carbit.htm - it's called arbitration -

I'm quite sure now that i was correct...

just to be clear, your EDIT2 is correct.
yes this is one way i2c multi-masters can deal with the *rare* cases when they both end up in control of the bus at the same time.
with a properly operating system this will hardly ever happen.

in *normal* cases the multi-masters just monitor the SCL line to see if the bus is free.
monitoring the data on the bus is not required.

dunk.

hazzer123 · « **Reply #80 on:** April 28, 2009, 07:21:16 AM »

Quote from: hazzer123 on April 28, 2009, 05:23:15 AM

Either one master starts transmitting and the others be quiet, or multiple transmitters start transmitting at the same time and they have a 'race'.

Im pretty sure i was correct

Although my language was slightly fuzzy...

Anyway, i say we should monitor the data on the bus, i.e. always check that when you write a 1 to it, check that it is a 1. Its not a big deal in terms of program complexity and despite the face that its unlikely... its possible and easy to fix. I'd like to cross out as many chances of failure as possible.

And people always seem to get back luck when reliability matters most

Weird Fishes · « **Reply #81 on:** April 28, 2009, 08:24:56 AM »

Just to be clear, we've abolished the idea of cubes, correct? I see it this way:

I want to build an autonomous robot that drives around and looks out for obstacles and tries to get to a certain GPS coordinate. Thing is: I need 142 IR sensors (exaggeration for effect), a GPS, 2 cameras, and 4 main MCU's for data crunching(again exaggeration for effect).

With this system, I could go to SoR, get the schematics and parts lists for those modules, send the schems in to a fab house and get myself 142 IR sensor boards, Gps, etc, etc. Then I can assemble all those PCB's and install the boards on my RC car chassis. Quick and painless (except for the assembling of 142 IR sensor boards

), plus I have code libraries.

With cubes this scenario is ridiculous. first, I'd have to buy all the cubes, which seem redundant for 99% of applications anyway, and I might as well order the boards too, since I'm getting that product anyway. Hey, my budget just quintupled!? What happened!

Cool, but impractical, and unfitting for this application. This is better served for an individual project, or a product, which is not what we're doing.

No offense to anyone, but I just feel it goes against all of our design goals.

Asellith · « **Reply #82 on:** April 28, 2009, 09:12:33 AM »

I agree. Cubes would be cool for a single project but does not meet the goals of this project. The cubes would work better if every module was a single unit with its own set of sensors/equipment that was standardized and you developed it like a hive system and they all worked together. Now if someone wants to design a housing that could connect the individual modules together and protect them as well as be expandable like the modules then more power to them.

hazzer123 · « **Reply #83 on:** April 28, 2009, 09:36:28 AM »

We should definitely take the idea of physical modularity aswell as electronic modularity from the cube design. So all our modules should fit on a 1inch grid, and have holes at each point in the grid to allow stacking of PCBs using standoffs. Of course 1 inch is just an arbitrary choice that can change. I think sth on the scale of a few cm is nice and we should look at making a final decision ok these standards soon.

dellagd · « **Reply #84 on:** April 28, 2009, 12:31:43 PM »

woah woah woah
I want a yes or a no or if it is inbetween give me a reason and what it is
are we doing cubes or not!

Weird Fishes · « **Reply #85 on:** April 28, 2009, 12:32:43 PM »

My vote is a big fat No.

hazzer123 · « **Reply #86 on:** April 28, 2009, 12:34:29 PM »

Mine is a no too.

dellagd · « **Reply #87 on:** April 28, 2009, 12:37:02 PM »

ok now that I think about it my vote is a no too. cubes not as flexable.

HyperNerd · « **Reply #88 on:** April 28, 2009, 02:18:09 PM »

I agree with Asellith, cubes are a good idea, but just not for this project.

SmAsH · « **Reply #89 on:** April 28, 2009, 02:19:44 PM »

my vote has always been a no for this project

News:

Author Topic: Community Project - Module Housing (Read 24286 times)