COMM Bleedover

[Phil]

Hi Guys n Gals,

I've got an absolute corker here.. Let me start at the begining. I'm sending uart data to two dumb terminals so I thought the chip with two uarts suitably would be a pic18F47K42. Fine It worked nicely untill this week where I started to get bleed over and i'll explain.

Code Line :-
hserprint "LOGON:",1

I even put a 1 at the end to make sure it went to terminal 1

on two terminals becomes

Terminal 1:-
LO

Terminal 2:-
GON:

can anybody explain this phenomena and possible cure as this is happening everywhere in my code?

Thanks in advance

Madphil :)

PS:- I'm upto about 1700 lines of code and five months in with a deadline at the end of october.

[Anobium]

Not seen this one before. Version   of the compiler ?

[mmotte]

Phil,
I haven't seen it either but I think it is possible.

please send the code your using. Are you using tranmit Blocking for both usarts?

We are not using transmit buffers for each comport and somehow the usart comport number is changing.
73
Mike

[Anobium]

version,   project as a zip please.

[Phil]

Its the latest release file GCB_Installer-98

[Phil]

Like I say, I has been working fine untill this week using the usual setup :-

 #define USART_BAUD_RATE 38400
  #define USART_TX_BLOCKING
  #define USART_BLOCKING

  #define usart2_baud_rate 38400
  #define USART2_TX_BLOCKING
  #define USARt2_BLOCKING

 ; ----- Config Serial UART :
    #define SER1_BAUD 38400   ; baudrate must be defined
    #define SER1_DATABITS 8    ; databits optional (default = 8)
    #define SER1_STOPBITS 1    ; stopbits optional (default = 1)
    #define SER1_INVERT Off    ; inverted polarity optional (default = Off)
    ; Config I/O ports for transmitting:
    #define SER1_TXPORT PORTA  ; I/O port (without .bit) must be defined
    #define SER1_TXPIN 0       ; portbit  must be defined
    ; Config I/O ports for receiving:
    #define SER1_RXPORT PORTA  ; I/O port (without .bit) must be defined
    #define SER1_RXPIN 1       ; portbit  must be defined
    #define SER1_RXNOWAIT Off  ; don't wait for stopbit optional (default = Off)``

[Anobium]

I have sent you a personal message.

I want to get you on the latest release of the compiler.

But, your code same does not tell us much. If you want send me the project to keep it confidential.

However... not enough information on the compiler release. Please post the first three lines of the ASM generated. This will tell me what I need to know.

[Anobium]

I have completed an offline code review. This is a really fun project!

The bleeding is cause by reentrant interrupts. The serial receive handler on USART1 is long running and another interrupt received on USART1 or USART2 when the trying send on USART2 would cause this issue as the serial receive handler on USART1 has could be mid stream sending on USART1.

Advice.

1. Implement a ring buffer for the incoming data. Examine the incoming in the main loop.
2. Make the Interrupt routines short as possible
3. Do not call HSERSEND or other comms ops from with the interrupts
4. Choose one type of Serial comms. You have two methods in use. Remove all references to Ser1Send and remove the include and the setup info.
5. Remove timer.h - not required

I have provided Phil with the latest patches for the compiler and UART.h but a little re-architecting of the project will resolve the issue.

Evan

[Anobium]

Also, looking the code again.

You could reduce the complexity by using a converter. The converter would simply create the table the ASCII text that is currently in strings. Then, you could stream the table to the serial port a lot faster and you can edit the source text file to correct errors.

Your converter would simple read the txt file then create the table dynamically with the table header etc. Should take about an to knock up the converter in Freebasic.

[Phil]

I've abandoned GCB for this project as it seems to be too buggy and doesn't seem consistant. Which is a shame. I will be back for other smaller projects though.

[Anobium]

Phil I reviewed your project. No fault found in Great Cow BASIC. There were no bugs or issues related to your issue this all due the solution architecture.

Using Interrupts is not easy and the architecture of using interrupts needs to be thought about up front.

A re-design will resolve your issue.

[Chris Roper]

Hi Phil,

Did you try the suggestion by Anobium to use Buffers and shorten your interrupt routines?

I am not sure what your background in BASIC is but many forget that GCBASIC is a cross compiler that supports hundreds of devices, on multiple architectures, so can’t be optimised to single processor like early BASIC implementations such as BBC or MSBASIC were.

The benefit is that GCBASIC absolves you of the hassle of defining the configuration and architecture of your target processor relieving you from issues such as segmented memory and complex oscillators and interrupt vectors, especially when porting code between devices. But the downside is that you have to take on responsibility for hardware specific functions such as dual UART implementation, buffering and correct interrupt handling.

Whilst I agree that GCBASIC has several bugs, and that the small volunteer team are constantly trying to track them down, fix and test on the masive list of supported devices, it is a bit unfair to say that it is too Buggy on the basis of attempting something it was not meant to do.

If you have abandoned GCBASIC what are you intending to use instead?

It would be a valuable exercise if you were to get it working in another compiler and then try and port that working code / algorithm back to GCBASIC. The results may actually contribute a new library to support multiple com ports in future releases.

Good luck with the project, I hope you get it working and we look forward to you returning when you have more time to experiment and contribute to GCBASIC development.

Cheers
Chris

[Phil]

@ Chris. I've gone back to oshonsoft basic. I've had to use a pic18f4620 and a 128k memory chip to acheive the same thing. Interrupts work fine. Although this looses one hardware com port, the software comm does work fine, so this allows me pretty much as many comm ports i want. I estimate this project will require about 6 to 7 comm ports.

Thanks for everyone's help.

Phil :)

[Chris Roper]

I estimate this project will require about 6 to 7 comm ports.

Sounds like you are making a comunications HUB for a multiuser MiniComputer or mainframe :)

I have never tried oshonsoft but will take a look.