HSerReceive on Mega's

[Bertrand BAROTH]

Hello ....
The subroutine :

Do
HSerReceive (Test)
Loop Until (Test = 0x3A)

(handshake for Emic) where "test" is a byte, works fine on 90S8515 ; it does not work correctly on Mega's ; it seems that it reads "ghost" characters, so AVR assumes that Emic is ready, sends a new string via HSerPrint, which is obviously ignored ! Is there a buffer of several characters for incoming stream, managed by hardware, which could contain such "parasitic" characters (but where do they come from ? ) On the other side, a Sub with

Do
HserReceive (test)
Loop until (test <> 0x3A)

which should erase all ":" , called before every HSerPrint, does not solve the problem !
Maybe I should call for Ghostbusters ?

[mmotte]

Betrand,
The AVR and Pics have a one byte "buffer", the read register UDR or UDR0. They claim it is a 2 byte FIFO but really it is the shift register receiving a byte and the read register waiting to be read. A flag is raised when a byte is available, RXC and GCB has created a general variable that is mapped to any of the RXC, RXC0, RXc1... flags ( USARTHasData = "RXC = On"). Using Blocking by defining, #define USART_BLOCKING waits for a byte to be present but it can wait for ever.

In your program you could check for a byte before calling HSerReceive.

If USARTHasData then HSerReceive(test)

If you are not using blocking then HSerReceive sends back a default value of 255.
'When Not using USART_BLOCKING the return value is defined by

define DefaultUsartReturnValue = 255

So you are receiving these "255"s and checking if they are 0x3a's .

This exampled in the Command Ref Helps

Start:
        comport = 1
        HSerReceive(InChar)    'Subroutine needs the comport set
        'InChar = HSerReceive    ' This function will get from comport 1
            If InChar <> 255 Then    ' check if for received byte
                                    'return 255 if old data
                HSerSend InChar    'send back char to UART
            End If
    Goto Start

So you can Handle It before the HSEReceive by checking "USARTHasData"

Or after the HSerReceive by checking for 255

Or put define USART_Blocking in a wait for ever for a byte to be sent. If your confident of the EMIC then it won't be for ever.

GL
Mike

[Bertrand BAROTH]

Dear Mike.

Thank You for Your answer, I tested several of Your solutions ... with no success. And the parameter "comport" is not defined for Mega8515. I added a "Wait 50 ms" after the handshake (I thought it was a question of "strict" timing), nothing went better. It seems strange, but the ignored data depend on which voice I use with Emic ! It's the eternal problem when two devices don't work together : where is the problem ? I worked on this problem for more than 6 hours, so I think I will give it up trying to use the Emic (and perhaps the serial port) ... or I will become MAD !

[Bertrand BAROTH]

PS : But it works perfectly with the routines of RS232 (software optimised) if I use the same pins as for hardware USART (handshake : Test = Ser1Receive) ! If anybody understands it, please explain it to me :
- If it does not work, it is not understandable !
- If it works, it is not understandable, too !
Murphy ?

[mmotte]

Betrand,
Take a breath! Step back. We're missing something.

What is the second ATMega? 2560 I assumed?
Comport is a GCB variable to define more than 1 usart on a micro. Comport canbe 1,2,3,4 which aligns with the 4 ports on the 2560 usart0,usart1,usart2,usart3 . Default Comport is 1. It is sometimes important to use the comport when using multiple comports and that is why we added user_byte_variable = HSerReceive1
GCB is trying to uyse a common interface for all the chips.

You seem like an advanced user. Maybe you need a Saleae protocal analyzer. They are great for solving "what is going on?". givies the timing and decodes the bits/bytes.

I have to go for now.
Mike

[Bertrand BAROTH]

I used Mega8515 (which failed with hardware RS232) at 4MHz for my first tests . I need a DIL processor with at least 32 I/O, or better 35, so I can dedicate Port E for serial (the voice application will be embedded into another one) : Mega 8515 is good for tests but for my final application there is not enough RAM, so I will use Mega162 ; I tested the prog for Emic with it, too (4MHz on STK200, it will be 8 on the final application board) : it worked fine. For handshake Ser1Receive, as indicated in help.

[Bertrand BAROTH]

PS : All my electronics for the railroad layout (see former topics) are DIY, no readymade modules like Arduino etc (so I don't use TQFP processors, because I am not equipped to solder them) ... I will design a new PCB to add the missing connections to the processor, in order to drive the Emic.