I am doing a project and in that project i am using one MAX232 but with multiple Microcontrollers i know that i cannot use RS-232 to multiple Microcontrollers but i am using MAX232 to convert the RS-232's 23V to TTL (5V) and so as the RS232 is converted to TTL so i think that it will work for multiple Microcontrollers (am i right?) well this is my stratigy ...
but my main task is that i want to send a HexaDecimal no through the Serial port so that the approriate Microcontroller will responce .... so i have coded some code but as i cant see the value came into SBUF in keil so could any one help me ?
"i am developing my own lame ideas for multiprocessing ... and my ideas are not so good"
So not only are you re-inventing the wheel, but your wheel is inferior to the wheels that already exist!
Would it not be better to simply study the good, proven wheels that are already available?!
Well you are right i should learn to use the Existing tires .... thanks man... but there is one problem that can i have your ID though i can communicate with you on PM.?
"can i have your ID though i can communicate with you on PM.?"
No - keep it in the forum.
That way, others can also help, and others can also benefit from the discussion.
What your should be looking at is RS485 protocol. One master and many slaves. Max232 will not work. Look at www.maxim-ic.com/.../
"What you should be looking at is RS485"
Maybe; Maybe not.
If the devices are not far apart, using low speeds, and noise is not a big concern, then RS485 may be overkill. A simple open-collector bus (as I2C uses) may be perfectly adequate.
But, whatever you do, you still need some scheme to address the slaves - and the 9-bit multiprocessor mode must be the obvious choice with an 8051?!
Your problem needs to be addressed in several different levels. At each level, an agreed-upon common scheme must be used by the devices to achieve communication : a protocol.
At the lowest level (the physical), you have to provide an electrical interface and topology that can be used to connect all your uC together - a BUS. At this level, you need to be concerned with the electrical signaling, noise, speed, direction signaling (such as a master/slave selection), and ability to send/receive data at the same time or not. You must also think about whether or not the bus will possibly have multiple talkers at the same time, which is a collision.
The RS232 standard interface, as noted above, is a poor choice for a multiple node bus in a multidrop topology, unless there is only one master and only unidirectional data is sent from the master to all slaves (no slave is allowed to talk on the bus). That is because you can't just tie multiple TX lines together, unless you tristate them, or use open collector drivers (but neither of it is RS232 anymore, and you can't use a MAX232 line driver for that). If you have 2 USARTs in every node, you can use a ring or daisy-chain topology with standard RS232 to achieve a bus with token-pass of packets (expensive in hardware and software).
A RS-485 bus, as mentioned above, is perfect for multidrop, low-cost, long-distance, and very simple master/slave software protocol. If you can have a single master on the bus, you can stay away of bus collision issues, as bus collision on RS-485 is very tricky to detect. This is what industrial protocols like MODBUS do, and is really simple to implement in software.
Other links can be used if you need multiple masters and collision detection, like the I2C bus. Several 8051s have I2C master hardware support, making it very simple to implement.
The 9-bit mode of the USART can be used to detect slave address by hardware, but it is not essential. You can just as well use standard 8-bit data and make the address recognition in the software protocol - that is what MODBUS does, for example.
"It would be a Really Bad Idea to call printf from inside your ISR...!
:-0 "
I agree with Andy. printf() is horribly large and slow on any microcontroller, especially in a 8051. You should never do lengthy operations inside a interrupt handler, to preserve system interrupt latency (the system response time for a interrupt).
Instead, you can prepare a buffer (e.g. unsigned char buf[]) with the ascii characters you want to send, and then directly feed the USART tx register with the characters, one at a time. The USART interrupt will be triggered on completion of each character transmission, and you can then get the next char from your buffer and send it to the USART, returning from the ISR. This takes just a few microseconds per char, and your main software can run while the USART is sending the char by the slow serial line.
Well Thankyou sir for your sharing of knowledge and i would like to thank you all of members who shared their knowledge well i have got little bit idea of how i can use Address bit and how to configure them but if i feel any difficulty then i would probabally create a new thread .... ;-)