??? 02/28/04 19:57 Read: times |
#65689 - RE: Flexible Networking.... Responding to: ???'s previous message |
well, i`ll try.
It is so complex that I even cannot imagine the thing I should start from. Okay, I start from the therms. First of all, I need to say that data typed below, is THE THEORY. When you realize it in the practical software, it may be some different. So read it like a guidelines, not direct implementation! TTC. It is the Time Triggered Communication. Under this scheme the each network device has own time slot inside the network communication cycle. For example, if the maximum number of network devices is 255 and the time of communication packet is 1ms then network cycle is 256ms (one time slot is recerved for the service purposes - see below). During the network communication cycle, each device with network number 1...255 has own time frame inside which only specified device may send data over the net. Rest devices must listen network and take it free itself. The simple example: we have network devices with numbers 1,2 and 255. Device No1 starts communicate. It may send either a data packet within 1ms frame or just a dummy mark about that it still presents online. Rest devices watch network and see that device No1 is online. They may(not) log this fact but they must produce silence while the device No1 transmits. After time slot No1 comes out, then device No2 takes control over the net like I said about the first divice. Now the time slot of device No2 is over and device No3 has own time slot. Oops, it is absent. No problem - all devices listen the net and may(not) mark this event. After all, device No255 catches network during its time slot. Then we have dummy lag time ("service frame"). Now network cycle goes to begin again. It is good in theory. Okay, I see you have some questions now (= The general question: how to assign these network numbers? Well, it is good question. The simplest way is having it as constant for each device: either somewhere inside CODE segment or in internal/external EEPROM (like MAC ethernet number), or via a DIP-switch selector on the board. But it is not usable sometimes. Then there is another scheme called "random number assignation". To implement it, you need a source of random event and "collision detect" method which solves the problem when some devices try to assign the same number. I try explain now. A device is powered in. First of all, it executes own power-up/setup routines and then goes to assign own network number. First of all, the device watches network and waits for at least full network cycle (I preffer for much more ones). It logs all numbers which are already online and so knows which ones are free to be used. Now it runs random generator based on accidental factor (for example: white-noice, thermo-sensor, external voltage ADC calcualtion, the current cost of a wood at Alaska :) . As result, the device has own number and tries to use it. The device waits till "servise frame" occures and then sends its number as a numbered bit inside this fraem. Well, now we come to it, need more explanation. Really, service frame should have special format. Now it is just the example, Think more about it yourself. The service frame is divided to the fields: one field per each network number. New device waits for the field which is corresponded to the number device has assigned itself on. The first bit is for the new devices: device sets it to zero to indicate: "I wish to take this number, could I do?". The second bit is response one. The device looks on it and checks if it is at high level that mean: "this number is free, you may use it". If another device detects that the first bit for its number is zero then device sets second bit to zero to say: "this number has been already assigned - try another one". At this case the new device must re-run random generator to give another number. Note that this way is common used as long as devices are not plugged more often than one per network cycle time. Otherwise there is a chance that some devices assign the same number and pass through "identification" routine both as well. To avoid it, another "collision detector" method may be implemented. The idea is that the each bit sent during time slot, is represented as two bits actually. Let example: imagine, it happenes that two devices have the same number somehow. At their time slot they send a data simultaneously. First device sends 1101 and second one 1100. Your software must convert it to: 11 11 00 11 for the first device and 11 11 00 00 for the second one. Here the first bits (named A) are information ones, second bits are collision detector ones (bits B). Device sends bit A and then looks at second one (B) - it must be the same as the first one. In our example, the first device is able to detect that it sents 4-A bit as 1 but read back 4-B as zero. And so it indicates that there is a collision problem over the net. To disable such packet and avoid wrong data to be received with other nodes, each time slot must have the validation bit at the end of a packet. If it is high then all is okay. If device detects collision problem then it sets this bit to zero what says: "drop this data, it has been been corrupted". What do I say more? I hope you catch the idea. Now try to implement it while I drinking my beer (= Good luck you with it... I think you will reach many problems. First one is syncronisation - your devices must detect start bit of each time slot correctly. Second one is re-sync: all OSCs must be at same frequency, As well, take attention about that time_slot, network_cycle_time and bit-time may be much less than error of OSC deviation. May I say that it is hard work to make it all to work good. But you asked - I do answer. Regards, Oleg |
Topic | Author | Date |
Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: 1-Wire | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
Perhaps I'm missing something; ... | 01/01/70 00:00 | |
RE: Perhaps I'm missing something; ... | 01/01/70 00:00 | |
RE: Perhaps I'm missing something; ... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
So what is the medium? | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
TTC = TDM? | 01/01/70 00:00 | |
RE: TTC = TDM? | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: Flexible Networking.... | 01/01/70 00:00 | |
RE: a missed issue![]() | 01/01/70 00:00 |