Menu

HSerReceive and HserGetNum issues on PIC16F886

2017-10-13
2017-10-13
  • Giuseppe D'Elia

    Giuseppe D'Elia - 2017-10-13

    I'm playng with PIC16F866

    Using the HSerReceive to receive a ASCII byte from a terminal and retrasmitting the same byte to the terminal using HSerSend, no match is found. As an example:
    First example:
    Trasmitted ASCI Character from terminal 1 Bynary format 0011 0001
    Received Character from terminal g i.e., number 103 Bynary format 0110 0111
    Note that the received Character is obtained from the negated trasmitted bynary byte (1100 1110 the negated of 0011 0001) shifted to the rigth by one bit and by adding a zero on the left.
    Second example
    Trasmitted ASCI Character from terminal 2 Bynary format 00110010
    Received Character from terminal 3 i.e., number 51 Bynary format 0011 0011
    Note that the received Character is obtained from the negated trasmitted bynary byte (1100 1101 the negated of 00110010) shifted to the rigth by TWO bit and by adding a zero on the left.

    This kind of rule applies also for other characters. The negation is alwais required. The number of shifts is equal to 1 if the last digit is 0.
    is equal to 2 when the last digit is one
    Is equal to 3 if the last two digits are equal to one. And so on.

    I do not understand. Samebody can help? Thanks

     
  • Anobium

    Anobium - 2017-10-13

    Hi,

    what version of GCBASIC ? and, what is connection between PC and microcontroller?

     
  • Giuseppe D'Elia

    Giuseppe D'Elia - 2017-10-14

    Hi,
    thanks for your quick answer.
    I have the last GCBASIC Version avaliable on the SourceForge I very recently downloaded.
    The connection between the PC and PIC is a wireless serial connection made by using the couple ERF (Part RFA020) URF (Part RFA021) Radio modules provided by Picaxe. This allows me to use a Mac (without RS232 hardware). They work fine and the terminal receive correctly the data trasmitted by the PIC.

    My problem inolves only the trasmitting from the terminal, i.e. the receiving PIC behaviour. This problem, the same problem, occurs on all terminals I used, i.e., Putty, CoolTerm, RealTerm, the Terminal provided by GCBASIC as well as the one provided by Picaxe Editor.
    My GCBASIC program is a very short one and only includes USART settings and a reading and writing on PIC. I must set SCKP=1 to correctly receive data from the PIC. When I set SCKP=0 the terminal only receive garbage (this on all terminals I experienced).
    I made a TEST and verified that the terminal correctly send and receive data by connecting the TX-RX pins of the receiving radio unit, i.e., the ERF. In fact the received data match the trasmitted ones.

    From the 16F886 datasheet I see that when setting SCKP=1, the PIC inverts trasmitted data. Nothing is said about the effect of SCKP=1 on the receiving behaviour of the PIC. I supposed it should not have any effect.
    On the other side, my TEST implicitly shows that the terminal uses the same polarity both trasmitting and receiving data.

    My opinion is that here reside the problem.

    In fact, the terminal requires inverted data when receiving and, I think, it transmit inverted data when transmitting.

    Accordingly, the starting bit of the trasmitted sequence, which is supposed to be LOW from the PIC, is now HIGH. In this way, the PIC does not recognize the right starting bit of the sequence. When a LOW bit of the 8-bit payload arriving data is received, this is assumed to be the starting bit of the received sequence. Accordingly, the 8-bit recognized by the receiver are not the true one and are shifted with respect the true one. This is exactly what I experienced on the negate sequence of bit trasmitted by the terminal, as described in my previous Post.
    Please let me know your opinion.
    Now I want to put an inverter betveen the TX pin of the ERF radio unit and the RX pin of the PIC and verify the PIC reception correctness. I think a simple transistor should be enougth when connecting the ERF output to the base and the PIC input to the collector of the transistor.
    Please let me know your opinion also on this point.
    Thank you

     
  • Giuseppe D'Elia

    Giuseppe D'Elia - 2017-10-14

    Hi Anobium,
    this is to confirm that when trasmitting to PIC the data must be inverted before reaching the PIC, according to the SCKP=1 setting. I checked by using a NPN transistor as a NOT port and now everyting is working when trasmitting from PC to PIC.
    Thank you for your attention

     
  • mmotte

    mmotte - 2017-10-15

    Giuseppe,
    I do not find a data sheet for 16F866, maybe a typo, But i am familiar with 16F886 and it don't have the SCKP polarity bit. I have struggled with it and ended up using a MAX232 chip to a serial port.

    There another option and that is using software serial. look in the Help under command references\serial communication\RS232(soft). It has both inverted and noninverted output. This works pretty well and I have communicated through just a pair of wires hooked to the 16F886 directly off of windows terminal. It has one limitation and that is 7 standard baud rates.

    I have been doing some data logging using 16F886 and a bluetooth module HC-05. I have no need for data inversion with that module.

    Thanks for solving your own problem.

    BR
    Mike

     
  • Giuseppe D'Elia

    Giuseppe D'Elia - 2017-10-15

    Hi mmotte,
    Here you can find the PIC16F886 data sheet
    http://ww1.microchip.com/downloads/en/DeviceDoc/41291D.pdf

    I knew the availability of the software RS232 GCBASIC commands. However I did'nt care because I was interested in solving my problem with the Hardware RS232 GCBASIC commands.
    This is because I'm mainly interested knowing the speed of a GCBASIC programmed PIC as compared with a Picaxe software programmed one. I used the PIC16F886 just because it was easily available at the moment. The great feature of GCBASIC is that it allows to directly program the PICs by using the PICKIT2 or PICKITS3, as i'm doing now. I'm new to GCBASIC.

    The Max232 chip was also known to me.
    However, inserting the line SCKP=1 after the USART settings in GCBASIC and using a 2N3903 NPN transistor (the first one available) plus two resistors quickly solved my problem.
    The fact is that I spend a lot of time to understand the explaination of the connection problem I had.
    Thanks for your post.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.