Serial port Receive troubles

[Anobium]

Are sending CR=CHR(13) to terminate the string?

[G. C.]

Yes, Carriage Return and Line Feed too..

[Anobium]

@GC

The program is doing what you ask. It is running until it gets byte of date, but by the time the buffer is read it has been corrupted as the waits will have prevented you to read all the incoming string.

 ;----- Main Program
do forever

              if USARTHasData Then
                Locate 0,0
                Print "Receiving"
                HSerGetString uart_input

                Locate 1,0
                Print uart_input

              Else
                HSerPrintStringCRLF "Hi Friend, what's up?"

              end if

loop

[Anobium]

Question. What did you change to get things working? Your insight may help others in the future.

[G. C.]

I believe it was a combination of multiple issues..
Both Hardware and Software.

Perhaps I started overconfident in my previous experience with simple PIC boards (made up with MPLAB, C and ICD3), and the easyness of Basic added to this.
Misfortune was also in using "defective" chips (the PIC18F1220 that you should have received), and also I did not make enough checks to every wire on the breadboard and got problems at various points, like the LCD etc. Furthermore, some confusion arose because of the lack of full infos on the commands in GCB (as I said previously, do not blame anyone for this or pretend state of the art sw..).

Having no way to make a step by step debug, I had to find other ways - and got yr suggestions about the "Terminal debugging".. The move back to assembler and MPLAB did not make sense to me, in such case better go back to C and MPLAB/ICD3. Trying to simulate with PicSimLab did not go well also (I still have to find out why, as I realized it seems quite an easy and powerful tool, even if poorly documented too, see the question wheter or not an HD44780 LCD emulation works with both 4 and 8 data wires).

Then, even the TTL adapters order had problems: one was obsolete (no driver for Win11) and the second one tried had a minuscule short circuit on the RX to GND pin..

In the process of rewiring the breadboard to use the PIC16F886 and an LED/Pushbutton I carefully reviewed every HW point and finally, after checking all the HW serial commands available in GCBasic, I succeeded in sending at least a character echoed into the uC itself.. Later I fixed the TTL adapter, connected to the working breadboard and finally got able to send and receive strings too. Now the only thing that's worth to investigate is the losses of sync on some long strings transmissions (I believe it's just a matter of timing limitation) or the fact that the flow of program stops when encountering the HSerGetString cmd (USARTHasData works only until the first RX of some data).

Well, quite messy, but seeing light at the end of the tunnel. Having said all above, if I can add my little contribution for helping a novice to the great job made by all the GCB team, it would be this:

1) First of all make use of a fully working HW before approaching GCBasic or any new programming language. There are plenty of cheap boards like Arduino etc that will avoid any prototype issue
2) Stitch to one Software tool at a time, ie GCB only or PicSimLab only and be sure to make "atomic" steps in the development
3) Read all the doc available for SW tools and only once sure that the problems you are facing are not documented, ask for help. This will improve the doc for future users also
4) If you want to buy a piece of Hardware like a TTL adapter, PICKitX programmer etc, make sure it works under your Operating System or PC Hardware you have

Best,
GC

[Anobium]

@GC.

Thank you for the chip! It was the only way to resolve the issue.

Re the PIC18F1220 - the root cause of the issues was incorrect configuration of a register when the chip is initialised, and, when the USART functions are used. So, I have updated the system library to 1) change the initialisation, and, changed the usart library 2) to ensure the correct setting of the RX and TX for digital operations.

See attached demos as these are the programs I used to test the correct operation.

---

Update your install in the gcbasic\include\lowlevel folder with the two .h file.

Please test - the chip should now work as expected.

[G. C.]

Made modification to h files, now it works correctly..
I found another "bizarre" problem on the PIC18F1220: when I use the pin INT0 to connect an LED I can't toggle it.. Moved to anothe pinj it works.

[Anobium]

Works here. This is on real silicon.

// GCBASIC Program.

// ----- Define Hardware settings
#chip 18F1220, 8
#option Explicit

#DEFINE USART_BAUD_RATE 9600
#DEFINE USART_TX_BLOCKING
#DEFINE USART_DELAY OFF


// ----- Main body of program
dir Portb.0 in

// ----- Main Program

HserPrintCRLF 2
HSerPrintStringCRLF "Started"

do forever

    If PORTb.0 = 1 then 
        HSerPrintStringCRLF ByteToBin ( PORTB )
    End If

loop  
end

[Anobium]

The same using an Interrupt.

// GCBASIC Program.

// ----- Define Hardware settings
#chip 18F1220, 8
#option Explicit

#DEFINE USART_BAUD_RATE 9600
#DEFINE USART_TX_BLOCKING
#DEFINE USART_DELAY OFF


// ----- Main body of program
dir Portb.0 in

On Interrupt ExtInt0 Call ISR

// ----- Main Program

HserPrintCRLF 2
HSerPrintStringCRLF "Started"

do forever

loop  

Sub ISR

    If PORTb.0 = 1 then 
        HSerPrintStringCRLF ByteToBin ( PORTB )
    End If

End Sub
end

[G. C.]

Also mine is on a real hw...
But I get it on an output, not input.. see my source code I put above, and if you can, try it out pls.. I had to change the output to pin RB7 to make it work.

When Led is on RB0/INT0, pb_led_commute (portb.0 = !portb.0) command does'nt get executed.

[Anobium]

I do not understand. Go back to basics. Like the operation of the code.

// GCBASIC Program.
// ----- Define Hardware settings
  #chip 18F1220, 8
  #option Explicit

  dir porta.4 in // pushbutton
  dir portb.7 out // Red Led 

  //----- Main Program
  do forever

                if porta.4 = 0 Then
                  portb.7 = !portb.7
                end if 

  loop  

  end

The code portb.7 = !portb.7 in this specific coding with produce three different operations.

1. The LED wiil flash when the porta.4 is low
2. The LED will be ON if you happen to set porta.4 to low when ortb.7 is High
3. The LED will be OFF if you happen to set porta.4 to low when ortb.7 is Low

So, know this this. Your code will produce three different results.

Your code looking at the same issue produces the same result of three states.

'''GCBASIC Program.

'''----- Define Hardware settings
  #chip 18F1220, 8

dir porta.4 in // pushbutton
#define pushbutton_pressed porta.4 = 0

dir portb.7 out // Red Led 
#define pb_led_commute portb.7 = !portb.7


 ;----- Main Program
do forever

              if pushbutton_pressed Then
                pb_led_commute
              end if 

loop  


end

Changing to PORTB.0 on the code above works.

So, start with this. Then, build back up to isolate where things go wrong.

---

And, for the LCD_IO 4 try #define LCD_NO_RW and do not define the RW line.

[G. C.]

Sorry Anobium,
But I do not understand you point.. In my example, that I have fully working onto a breadboard as it is posted in the main.gcb above, there is simply this strange fact: it works if I put the red LED on RB7, and not if the LED is connected to RB0 (obviously changing the sw to the change of output pin)..

Leaving aside the Serial lines commands, there is only an LED (yellow, RA6) that blinks once per loop that includes a 1s delay, and a pushbutton that if pressed (active low) will invert the outpin pin (RB7) state, wichever it was before, where a second red LED is connected.
There is no three state operation (unless you mean the possible bouncing of the pushbutton).

About the LCD, it works fine with the RW line driven by GCBasic, no problem at all..

The LCD operation is not working with the PicSimLab. I hope that when either Chris Roper or Ccin E Crout , that both have said are familiar with the simulator, will have some spare time to load my example (simulator workspace and GCB source already posted earier) and check if on their machines simulation works. Because that little program on real hardware works fine, but do not get simulated.
When I looked onto PicSimLab found plenty of uCs, modules etc available and seems very promising in terms of help to the development of PIC boards. Therefore I tried it out, but found something working and something not. Surely is for some error of mine or problems with the installation on my PC. But even with using the latest version, same problems..
I'll try on another machine and see. This piece of sw seems good and in full life/evolution, while Real PIC Simulator that you mentioned is not even present on the developer's website, I think it's no longer mantained and seemingly available in frree trial version only on shareware sites..

[Anobium]

You think you have a fully working program. I think you need to reset so we can resolve one issue at a time.

The chip you are using has probably not been used by anyone ( to my knowledge and proven by the fact that serial could never have been working). So, I recommend, you take the code I posted and validate that the basics IO operations work... which means sort the LEDs and switch operations out, then, add Serial and retest the IO operations then add LCD and retest.

[G. C.]

The simple program with only IO works, I confirm your post above. Both with RB7 and RB0.
Now also with the TX serial port commands included.. I am wrong in the timing of the incoming string reception, I will fix it up by using the serial port only on Interrupt and waiting for the full reception of the incoming message.
Thx,
GC

[Anobium]

Excellent.

I think the issue may happen again, when, you use the LCD. I am not 100% sure but as you progress with your testing then you will be able to figure this out.

---

If you have that issue when the LCD integrated, then, please try #define LCD_NO_RW and do not define the RW line.

[Chris Roper]

The INT0 pin is an input by default, is your code specifically making it an output?
The Code example above doesn't look like it.

[G. C.]

Perhaps there is a misunderstanding due to my poor english..

I said I made some tests with the red LED attached to RB0 and was not able to toggle the LED via the pushbutton (active low, a 10KOhm resistor on RB4 to pull up to 5V and a pushbutton to get a low when pressed ).

Meaning that the code line that now in mmy source code above is written as dir portb.7 out // Red Led was initially set to dir portb.0 out // Red Led and the other one: #define pb_led_commute portb.7 = !portb.7 was before #define pb_led_commute portb.0 = !portb.0

When trying to commute the pin RB0 to toggle the LED on/off via the pushbutton on RB4, the board did not work as expected. Changing the red LED to the port RB7, everything is fine..
So I tought this strange behaviour of the RB0 was perhaps connected to the fact that is also an external interrupt that may cause something weird.. But I said I am not sure.

[Anobium]

Try the simplified code I posted. Does this work?

Start with the code I posted. Then, we have a new baseline to dicsuss.

[G. C.]

The final post on the simulator issue:

it was necessary to remove the RW line management from the GCB source, as suggested by Anobium https://sourceforge.net/p/gcbasic/discussion/579125/thread/07207e7ef8/?page=2#05e7/165d/189c/ea7c/94a7/76aa/3e80/895e/cb62, and then create again the HEX file to load onto PICsimLab.

If RW pin is managed in the source/hex code, even if you do not virtually connect the RW pin on the LCD simulator module trough it's property window, it does'nt work. That's true even if you pass to a full 8 bit data mode.. If somebody tried to load my PicSimLab workspace file posted in previous messages, perhaps would have found it not working on his machine too.

Please note that the GCB source code HEXed/Flashed on an actual uC on a real board, works perfectly even with the RW pin driven.

Thanks for the help & patience of everybody, and regards.
GC