SerReceive issue

[Jacques Nilo]

Hello all
I have the following simple program:

#chip 16F690, 8

#define RecAHigh Set PORTA.1 ON
#define RecALow  Set PORTA.1 OFF
InitSer 1, r1200+WaitForStart, 7, 1, Even, Normal

SerReceive 1, char

It compiles ok but when the hex file is being generated I get the following error message:
Error: GCASM: Symbol SET 5.1 1 has not been defined

Any idea ?

Jacques

[Anobium]

Jacques,

Is the error from a pre-release version of GCB?

Version and date please.

Cheers

[Jacques Nilo]

Latest Hot Release dated 2015-04-02

[Anobium]

Hi, a few errors in the code. See below.

  #chip 16F690, 8


  'Recommend you use a define called SerOutPort, then set the HIGH/LOW states and then the direction all using SerOutPort
  #define SerOutPort PORTB.7
  #define RecAHigh SerOutPort  ON
  #define RecALow  SerOutPort  OFF
  'Set pin directions
  Dir SerOutPort Out

  'This is the correct InitSer  
  InitSer 1, r1200, 1+WaitForStart, 7, 1, Even, Normal

  SerReceive 1, char

In the planned release of Great Cow Basic (post August 2015) you will get a more meaningful error message when compiling.

[Anobium]

Also, there are demonstrations of serial setup in your installation.

See GreatCowBasic\Demos\New\Serial Communications Solutions\Sofware Serial to Turn On LEDs Solutions and other demos using Software Serial.

[Jacques Nilo]

Thanks Evan. I looked at the doc too quickly and did not notice that the define statement is not symetrical for RecAHigh/RecALow and SendAHigh/SendALow. Now it compiles ok but I am still having difficulties to read my data through soft serial (hard serial working ok though). Will look at that more closely.

[Anobium]

Please download https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/rs232.h this does have fixes that may resolve vomms issues.

Anobium

[Anobium]

Please download https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/rs232.h this does have fixes that may resolve vomms issues.

Anobium

[Jacques Nilo]

I tried the new rs232.h still not working.
I am trying to read incoming data from an "intelligent electricity meter".
Each character is sent at 1200 baud rate through a 10 bits packet with the following structure
1 start bit (0)
7 bits corresponding to the ASCII character to be read
1 parity bit (even)
1 stop bit (1)

When I use Hard RS232 to read the data, I can display it through Soft RS232 without any problem on Realterm setting the terminal at 9600/7 data bits/1 stop bit. The working program is a follows:

#chip 16F1709, 8

; Config Hardware-UART
#define USART_BAUD_RATE 1200
#define USART_BLOCKING true
RXPPS=0xD          'Peripheral input is RB5 (p140 of the datasheet)
RB7PPS=0x14        'Pin RB7 source is TX/CK (p141 of the datasheet)
Dir PORTb.7 Out
Dir PORTb.5 In

; Config Software-UART
#define SendAHigh SET PORTA.4 ON
#define SendALow  SET PORTA.4 OFF

InitSer 1, r9600, 1+WaitForStart, 8, 1, None

do
 char=HSerReceive
 if (char <> 0x02 ) | (char <> 0x03) then
     serprint 1,chr(char)
 end if
loop

Then I try to do the reverse: read the incoming data with Soft RS232 and displaying to the terminal with Hard RS232. Here is the program which does not work (I get garbage on the terminal):

#chip 16F1709, 8
#define USART_BAUD_RATE 9600

RXPPS=0xD          'Peripheral input is RB5 (p140 of the datasheet)
RB7PPS=0x14        'Pin RB7 source is TX/CK (p141 of the datasheet)
Dir PORTb.7 Out
Dir PORTb.5 In
  'Config Software-UART

#define RecAHigh PORTA.5 ON
#define RecALow  PORTA.5 OFF
Dir PORTA.5 In

InitSer 1, r1200, 1, 7, 1, Even, normal

do
 SerReceive 1, char
 if (char <> 0x02 ) | (char <> 0x03) then
     hserprint chr(char)
 end if
loop

Any ideas ?
Jacques

[Anobium]

If you can you use your first method then please do. The second method you are using may experience timing issues caused by the processing time within the Do-Loop

A pieces of information may help. SerReceive turns off and on global interrupts. Using a third parameter to the command SerReceive witll prevent the global interrupts from being turned off and on. Set the third parameter to 'True' as follows.

SerReceive 1, char, True

Then, I would enable all the constants in the hardware for the blocking commands, see here.

Then, I would optmise the if - then commands - this will take time to process and whilst this is processing you can lose incoming serials bits because it takes time to complete the if-then and the HSerPrint and then the call to CHR.

    ' use HserSend this will be much faster as 
HSerSend char
~~~~

Then, you could remove all the calls to the public methods like Hserprint and Hsersend - this code will remove the calls to improve timing.

HSerSendBlocker

'Send byte
#ifdef PIC
    #ifndef Var(TXREG1)
        TXREG = char
    #endif
    #ifdef Var(TXREG1)
        TXREG1 = char
    #endif
#endif
~~~~~~

This may help but I think if you work the maths of the timing to verify the timing is practical. You then could write a software serial input buffer ring which uses interrupts to resolve the timing issues.

[Jacques Nilo]

Thanks for your suggestions. Always very useful. I'll work that out.
Jacques