Your Electronics Open Source

The program is wrote in PicBasicPro, such chosen was dictated from the pragmatism as well as the facilities of modification and integration of future code. So that the management of the bus can be easily transportable and integrable I have put the code in external file to include in the main program.
The program is active just in case of one question from part of the bus, while normally the PIC executes the main program.
The wrote code the communication manages all the MultiMaster of the net and is easily transportable on other model PIC ( with USART integrate )modify just the definitions, like this you can add easily another functionalities. The speed settando the opportune definition can be various you must verify if the USART internal can manage the baud-rate correctly, otherwise it must change the quartz, I have noticed that however it exists a big tolerance.

With a quartz from 20 Mhz you can reach the speed of almost 1Mbps! For a correct use of the USART do the reference at Data Sheet of the PIC. The use of the elevate speed can be utile for the automatics machines which must communicate quickly to short distances. For the commodity I advise to use the standard speed to be able to monitorare the data through a PC.
At the beginning it is very commode to control everything all the traffic through the PC to test the correct functioning, anyhow the net is autonomous in the sense that every node has the capacity to function from Master and from Slave interacting between them. The communication is the MULTI-MASTER type, the resources minims to work the net are are at least two nodes or a node and PC with adapter RS232. You can add others just connecting them and assigning them an ID unambiguous.
In the new version the sw is completed transparent to the main program because uses the interrupt from the serial. Like this you can obtain an instantaneous response when the question of the net, the unique inconvenient is that if one routines is being executed with the temporisation this is totally the cause is the order time to satisfy the demand for the interrupt wrong .

For this reason the interrupt was thought in a particular mode, because it doesn't turn to the next instruction after the call, but it realizes a jump to the label loop that it must necessarily be in the main program. This is utile because is abort the instruction which performed and could give the wrong results
One technical to resolve this problem can be the supposed bit-banging e il real-time but we will speak on the BLOG in the future

Another consideration: it must make attention when the data is demanded in a repetitive way not to saturate the bus, to put the delays or a timer which at the times predefined it executes the demand.