Help PLEASE - Stuck on a project! 16F877A


Closed Thread
Results 1 to 17 of 17

Hybrid View

  1. #1
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Megahertz View Post
    P.S: I don't have any knowledge about USART, I am a product design student actually and try to learn programming because I find it very interesting. I will learn about USART soon and apply it to these codes. I hope I can make this code work using DEBUG for now.
    Using the USART in PBP is not much different than using DEBUG or SERIN2, same syntax.
    Look to the PBP manual under HSERIN for starters and at the bottom of this page is an example to play with.
    http://www.melabs.com/resources/samples-pbp-general.htm
    The hardest thing with the USART at the beginning is setting it up.
    For that this is a handy tool
    PicMultiCalc
    http://www.picbasic.co.uk/forum/atta...achmentid=2957
    Dave
    Always wear safety glasses while programming.

  2. #2
    Join Date
    Nov 2009
    Location
    London
    Posts
    251


    Did you find this post helpful? Yes | No

    Default

    Hi Mackrackit, thanks for the answer.
    Can you please explain briefly what excatly is USART (HSERIN) and how is it different to SERIN, If I attach the TX pin to my RF receiver and use HSERIN, will it still work as normal, does data comes differently when HSEROUT/HSERIN is used.
    I also want to ask that when using the debug statement, because of the noise at the RF receiver, even if there is a timeout, 99% of the time it does not work. When used with USART command, can this problem be sorted?

  3. #3
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    The main difference is SERIN2 is all software(bit banging) while USART is done in the on chip hardware.

    SERIN2 has the advantage of being able to be used on just about any pin and can be setup for Inverted or True mode.

    USART has the advantage of running in the background and can be used as an interrupt trigger.

    Sometimes considered a disadvantage the USART is True mode only so depending on the application an inverter chip might be needed (MAX232 type).

    Data with both types can be a standard 8N1.

    To be honest I have not really looked at your code but I will guess some sort os simple checksum would solve the noise problem. I will take a look at it later.

    Reliable RF can be used with bit banged serial, Bruce has a nice example in the Code Example section.
    Dave
    Always wear safety glasses while programming.

  4. #4
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    Possible pointers...

    Finally had a chance to look at your code and I am wondering exactly what your are trying to accomplish with the interrupts and you are receiving a string into var P but I do not see where P is used.

    A couple of things that might help you.

    Like Darrel said about interrupts, get in and out as fast as you can.
    That being said I think I would use the interrupt to receive data. This can be accomplished using DT's instants if you use the USART. I have only used DT's intants for this a time or tow and they worked great, thanks Darrel! There are examples on how to set it all up on his web site.

    The only thing you would be doing inside the interrupt is receive data. The data will be processed else where. Using USART and interrupts you should not miss any data.

    Now for the RF.
    If you are using radio modules like the ones found at rentron.com then they need to be "trained" to receive data. This is done by sending a bunch of 0s and 1s. There is some controversy about this but sending $A5 first seems to work well. Also send a SYNK byte, this will take place of your MT3. You will wait for the SYNK.
    Code:
    TRAIN = $A5
    SYNK = $7E
    HSEROUT [TRAIN,SYNK,"your data will be here"]
    In the receiver side, the interrupt will be triggered when the USART "hears" something. If the SYNK is not received then exit the interrupt. If SYNK is good save the data then exit the interrupt.

    That might be enough to make it work but you may also want to add a simple checksum.

    A quick and dirty way is to take the value you are sending, 41, and multiply by 3 before you send. That value would be saved into a VAR CH_SUM, = 123. Send 41 and CH_SUM.

    When you receive save 41 to your code VAR and save CH_SUM also. Before you act on the data divide CH_SUM by 3 and check to see if it equals "code". If not you have had a bad transmission.

    There are several ways to do this, the above is just one to give you some ideas.
    Hope my babbling did not confuse the issue.

    [/code]
    Dave
    Always wear safety glasses while programming.

  5. #5
    Join Date
    Nov 2009
    Location
    London
    Posts
    251


    Did you find this post helpful? Yes | No

    Default

    Thanks Dave, I am very thankful to many members here, because I have learnt a lot from this forum and now the checksum method, which you have explained very simply.

    I have taken the advises above and changed the code and freed the MCRoom's ISR.
    During my earlier attempts, I tried to make the code work by sending an 1 string byte, but it didnt worked so I changed it, but left the receiving string variable as it is.

    It is not working currently, but it seems I am near as ISR is not handling much complicated stuff like pause or DEBUG.
    The code at machine now (MCH1.txt), keeps sending signals and waits for the answer from the MCroom.
    The MCroom should switch the LED ON and buzzer ON when mch reports a problem. I have tried to put everything in a loop, but it is not working.
    Is it ok to put things in loop like I have done?
    I am attaching the codes I have amended.
    Attached Files Attached Files

  6. #6
    Join Date
    Nov 2009
    Location
    London
    Posts
    251


    Did you find this post helpful? Yes | No

    Default Start with HSERIN

    I was looking into the PIC calculator. I would like to incorporate USART into the code as advised.
    I have got few statements from the PIC calculator which are:

    Code:
    DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
    DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
    DEFINE HSER_SPBRG 12  ' 4800 Baud @ 4MHz, 0.17%
    DEFINE HSER_CLROERR 1 ' Clear overflow automatically
    and also
    Code:
    RCSTA = $90 ' Enable serial port & continuous receive
    TXSTA = $20 ' Enable transmit, BRGH = 0
    SPBRG = 12  ' 4800 Baud @ 4MHz, 0.17%
    I would like to ask, if these are the only statements which I need to put in the code and then replace DEBUG with HSERIN & HSEROUT and also use my simple RF modules on TX & RX pins of my PIC instead of the ones I am using now?
    I mean would these statements be correct?
    Code:
    HSEROUT "MT3",code,"S" & HSERIN [WAIT("MT3"),code,STR string\1\10]
    Also Dave, to answer your question -
    If you are using radio modules like the ones found at rentron.com then they need to be "trained" to receive data.
    . I am using simple RF modules and not any special kind.

  7. #7
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    Is it ok to put things in loop like I have done?
    The code in the ISR still looks a bit long. Maybe put that stuff in the START label being you are looping back to it. Have a GOSUB in there to TOGGLE FAST.
    In the end I think the only thing you want in the ISR is the serial receive.


    From the PicMultiCalc program the copy defines is what you want at the beginning of your code for this.

    Your HESER statement is not quite right. Look at SERIN2/SEROUT2 for examples on the syntax, it is the same as HSERin/out. Basically you need [ ] at the beginning and end.

    Now I am going to suggest that you leave your code for a bit and and work on some simple test codes to make sure you have everything working. I am sure you did that at the beginning of this project but several things are changing now, adding new "stuff" and restructuring the code.

    RF is difficult at best so start with wires. Do the HSERIN in the ISR and just simply have it do one thing, light an LED. Then work on feed back from the receiver.

    Which brings up another thing. If I am following this correctly the RF is two way. ZUnless you have a two way module you will want to kill the power to the transmitter when you are receiving. I do not see this in the code but maybe it is there.
    Dave
    Always wear safety glasses while programming.

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts