News:

PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

one wire 12F508 or 12F509

Started by hitronics, Aug 29, 2022, 04:03 PM

Previous topic - Next topic

hitronics

Hi, All
is it possible to make one wire connection between two MCU 12F508 or 12F509?
it is appreciated if there is a code for testing

Frizie

Look in the manual (help) for the instructions OREAD and OWRITE, although I've never used one-wire between two PIC's.
Also be aware that the one-wire protocol consists of two wires, the data line and ground  :P .
Ohm sweet Ohm | www.picbasic.nl

shantanu@india

Isn't the memory too small?
Regards
Shantanu

RGV250

Hi,
A bit more information is required, do you mean a one wire protocol like Dallas one wire or just any communication over one wire.
If the latter then is it bi directional, also if bi directional is it a master / slave type situation?
My only thought is master / slave where one device requests data and then wait for the other to reply. where you could use software serial.

Bob

joesaliba

I have done as Bob said using software serial.

I was a bit sceptical that it will work, but it came out better than I thought.

I remember having a handheld display with 3 buttons, and to make some changes to the master PIC, holding for example the up-button pressed , the slave will send data to master, and return the value to the LCD.

Note the RETURN VALUE TO THE LCD.

Not changing the numbers on the slave and send them, but send them and receive them, it was like a sort of acknowledgment that data was succesfully received by the master.

Another advantage I had was that I could disconnect and reconnect without any data loss.

Joe

shantanu@india

Bottomline is 512/1024 word flash.Very little room to write long programs.
You should try to use assembly code as much as possible for compactness of code. We used to manufacture automatic changeovers using 12C508 OTP devices. That was before proton days....
Regards
Shantanu

top204

#6
The straightforward way to do a single wire (not including a mutual ground) would be to use standard Async coms. Then you can use the Rsin and Rsout commands.

This was standard practice on the old devices before they introduced USARTs into them. So when one device is transmitting on that wire, the other device is receiving on the wire, and vice-versa. For more robustness, use low Baud rates.

Unless a person has a detailed knowledge of the old devices, writing in assembler code it very difficult, and can easily be mishandled and cause the device to go "potty", because of the dreadful architecture of the devices with a tiny call stack and extremely fragmented, and banked, RAM etc...

And also... The compiler produces quite nice assembler code, even for the 12-bit core devices. It even implements a software call stack to give them a bit more use. :-)

Frizie... The Oread and OWrite commands are for the microcontroller to be the master only. :-) The compiler has no built in slave commands, because they require interrupts, and the compiler uses as few as possible peripherals in its standard commands so they do not interfere with a user's program.


shantanu@india

QuoteAnd also... The compiler produces quite nice assembler code, even for the 12-bit core devices. It even implements a software call stack to give them a bit more use. :-)


I know that Les... all credit goes to you. I used to write 12F683/16F877A code in assembly before I was introduced to you... way back in 2002...and I found what Proton generated was as good as a carefully crafted assembly code that took approximately 15 days to write with innumerable hiccups!!!
Regards
Shantanu

joesaliba

Quote from: top204 on Aug 30, 2022, 02:45 PMThe straightforward way to do a single wire (not including a mutual ground) would be to use standard Async coms. Then you can use the Rsin and Rsout commands.

Hi Les,

Yes, I did use RSIn and RSOut for that purpose.

However, once I opened a device which was running an 16F876 using one wire transmission and receiver that had both hardware USART soldered together.

I think that when the device was receiving, TX pin was configured as an input.

Regards

Joe

tumbleweed

#9
Quote from: joesaliba on Aug 31, 2022, 06:19 AMI think that when the device was receiving, TX pin was configured as an input.
If you put a series resistor (several K) on the TX output and interconnect the RX at that point you don't have to do anything with the TX pin direction/enable.

edit:
This also protects the TX output so you don't have to worry about having the two TX pins tied together.

joesaliba

Quote from: tumbleweed on Aug 31, 2022, 11:08 AM
Quote from: joesaliba on Aug 31, 2022, 06:19 AMI think that when the device was receiving, TX pin was configured as an input.
If you put a resistor (several K) on the TX output and interconnect the RX at that point you don't have to do anything with the TX pin direction/enable.

Interesting. Thank you

Joe