I just uploaded version 3.0. This version is not compatible with previous versions because I had to change the signal timing to accommodate RCFast clock mode. I also included a schematic of the various circuits that I tested with. The biggest change is that it now provides a one, two or three wire interface to support a variety of interface chips. I hope the documentation is clear on this. I tested all four interfaces up to 1.1MB. However, since the two wire RS-485 interface relies on bus termination for rising edges I'm not sure this will work at that speed in a noisy real world environment. For my projects I will be using either the single wire or the CAN bus interface. I'm starting to like CAN.
In continuous mode (ProBusTest2.spin) there is no reliable connection between BC and RC and in async mode (ProBusTest3.spin) there is a data transfer but after some time there is corrupted data.
Maybe it´s a timing problem because it seems to take some time until a buffer is completely read by the asm programs but I don´t know how to optimize the async mode.
When I´m writing data into a buffer there is a time difference between first word written and last word written so that I would like to know whether direction is up (word 0 ... 62) or down (62 .. 0).
Mike writes that there is a limit of 63 words for a buffer and it seemed to work for more words but due to my problems I could not check that further.
The test programs published by Mike don´t show a real BC - RT communication.
So I have built 2 programs sending 63 word buffers to and fro in an endless loop always incrementing the buffer contents. a simple checksum shows if the data transfer worked or failed.
Who can help?
Background of my test configuration:
I´m using a PropStick with 32K EEprom as BC and a Propeller Dip40 as RT. RT is connected to BC thru I2C (P28/29) and oscillator output Pin31 (XO) of PropStick is connected to RT Pin30 (XI).
The 1wire connection is a 10 cm line (5 cm flat cable, 5 cm handwired cable on a breadboard pcb) using one 100k pullup to +3.3V. Therefore I have reduced bit rate to 300kbit.
The PropStick is modified in a way that XO from the bottom side crystal socket of the PropStick is soldered to PropStick Pin31 (Pin31 is normally not connected).
Question to Parallax staff: why is XO not connected for PropStick? That would be a real benefit ;-)
BOE of RT is connected to GND. Res of RT is pulled down to GND by 10k. Port P0 of BC is pulled up to +3.3V. P0 of RT is pulled down to GND.
P1 of BC is connected to Res of RT.
My goal is to run a stack of Propeller RTs without individual crystals and without individual EEproms. So BC starts to boot from EEprom while RT is in reset mode. P0 high identifies master role.
After BC has started master application it sets P1 to high and RT starts to boot from PropStick´s EEprom. Because RT´s P0 is low the program start selector code identifies the slave role and RT code is processed.
All program code for BC and RT is placed in BC´s EEprom.
In a first step I want to connect 2 RTs to the master and so there is a basic adressing mechanism to identify RT´s number.
For one BC and one RT that works fine so far.
Once data transfer works I want to implement adressing thru the 1wire protocol. Maybe there is a broadcast mode or a connect for RT at HIVAL address to the BC and then disconnect and reconnect RT with finite address after address reception.
The PropStick board has a crystal on the board. Does the dip prop have a crystal, or are you using one of the rc modes? Very difficult to do async comms reliably unless you are using accurate and stable clocks on all the micros.
The Dip40 Prop (pin XI) is using the XO signal of the PropStick crystal. So it´s running synchronuous to the PropStick. I have no understanding of the asm implementation but the Manchester code containing timing information should sync the time base anyway.
Comments
Thanks a million, your a life saver. I had hooked up a second computer, but I kept getting confused on which mouse controlled which cursor.
Mike
I just uploaded version 3.0. This version is not compatible with previous versions because I had to change the signal timing to accommodate RCFast clock mode. I also included a schematic of the various circuits that I tested with. The biggest change is that it now provides a one, two or three wire interface to support a variety of interface chips. I hope the documentation is clear on this. I tested all four interfaces up to 1.1MB. However, since the two wire RS-485 interface relies on bus termination for rising edges I'm not sure this will work at that speed in a noisy real world environment. For my projects I will be using either the single wire or the CAN bus interface. I'm starting to like CAN.
Mike
Do you use "Differential Manchester" or just "Manchester" coding?
Thanks
rich
Differential Manchester, no. Manchester, yes.
Mike
In continuous mode (ProBusTest2.spin) there is no reliable connection between BC and RC and in async mode (ProBusTest3.spin) there is a data transfer but after some time there is corrupted data.
Maybe it´s a timing problem because it seems to take some time until a buffer is completely read by the asm programs but I don´t know how to optimize the async mode.
When I´m writing data into a buffer there is a time difference between first word written and last word written so that I would like to know whether direction is up (word 0 ... 62) or down (62 .. 0).
Mike writes that there is a limit of 63 words for a buffer and it seemed to work for more words but due to my problems I could not check that further.
The test programs published by Mike don´t show a real BC - RT communication.
So I have built 2 programs sending 63 word buffers to and fro in an endless loop always incrementing the buffer contents. a simple checksum shows if the data transfer worked or failed.
Who can help?
Background of my test configuration:
I´m using a PropStick with 32K EEprom as BC and a Propeller Dip40 as RT. RT is connected to BC thru I2C (P28/29) and oscillator output Pin31 (XO) of PropStick is connected to RT Pin30 (XI).
The 1wire connection is a 10 cm line (5 cm flat cable, 5 cm handwired cable on a breadboard pcb) using one 100k pullup to +3.3V. Therefore I have reduced bit rate to 300kbit.
The PropStick is modified in a way that XO from the bottom side crystal socket of the PropStick is soldered to PropStick Pin31 (Pin31 is normally not connected).
Question to Parallax staff: why is XO not connected for PropStick? That would be a real benefit ;-)
BOE of RT is connected to GND. Res of RT is pulled down to GND by 10k. Port P0 of BC is pulled up to +3.3V. P0 of RT is pulled down to GND.
P1 of BC is connected to Res of RT.
My goal is to run a stack of Propeller RTs without individual crystals and without individual EEproms. So BC starts to boot from EEprom while RT is in reset mode. P0 high identifies master role.
After BC has started master application it sets P1 to high and RT starts to boot from PropStick´s EEprom. Because RT´s P0 is low the program start selector code identifies the slave role and RT code is processed.
All program code for BC and RT is placed in BC´s EEprom.
In a first step I want to connect 2 RTs to the master and so there is a basic adressing mechanism to identify RT´s number.
For one BC and one RT that works fine so far.
Once data transfer works I want to implement adressing thru the 1wire protocol. Maybe there is a broadcast mode or a connect for RT at HIVAL address to the BC and then disconnect and reconnect RT with finite address after address reception.