Great. Thanks. The receiver will enter "config mode" upon power up, so user can adjust whatever he needs to be changed, after exiting it, it will operate independently.
Great. Thanks. The receiver will enter "config mode" upon power up, so user can adjust whatever he needs to be changed, after exiting it, it will operate independently.
Just for ideas, I believe the DH11 (or whatever it is) temperature & humidity sensor uses 1-wire communication. You might also look at CAN, and I2C for ideas. You would need an Open Drain pin (when in output mode), or configure a transistor/MOSFET/diode to create an OD condition from both ends.
The basic idea is a pull-up resistor creates an "Idle High" situation. Pulling the line Low is how either side initiates communication. Using INT0 (INT1_2) or IOC you could know when to look for a transmission (ISR). Unless transmitting, the pin would be configured as an Input (TRISx.x = 1), so it is able to look for packets from the other chip. With CAN, if the Sender is attempting to send a High signal, but the line is Low, Arbitration states the other chip is also trying to communicate and the looser (the one unsuccessfully trying to send a High signal) backs out. To transmit, you would first clear the TRISx.x bit, then begin sending. When finished, set the TRISx.x bit so you can then receive on the same pin.
You would probably have to create your own protocol, but look at how exciting a challenge that might be!
Yeah, time to implement GPIB in PBPor FSK
![]()
Serin2 already has handshake implemented! Why not use it instead of trying to re-invent the wheel?
From the manual:
SERIN2 DataPin{\FlowPin},Mode,{ParityLabel,}{Timeout, Label,}[Item...]
Receive one or more Items on Pin in standard asynchronous format. SERIN2 is similar to the BS2 SERIN command. DataPin is automatically made an input. The optional FlowPin is automatically made an output. DataPin and FlowPin may be a constant, 0 - 15, or a variable that contains a number 0 - 15 (e.g. B0) or a pin name (e.g. PORTA.0).
The optional flow control pin, FlowPin, may be included to help keep data from overrunning the receiver. If it is used, FlowPin is automatically set to the enabled state to allow transmission of each character. This enabled state is determined by the polarity of the data specified by Mode.
Ioannis
Because the flow control feature of SERIN/OUT2 uses an aditional pin and CuriousOne specifically specified that there was only one I/O pin available.
You are right Henrik. I missed that. Well, it is not guaranteed then...
Ioannis
What about OWIN/OWOUT ?
Bookmarks