PICSimLab emulates many PIC chips so you can experiment with devices from the PIC10, PIC12, PIC16 and PIC18 families. It also emulates several of the AVR Devices including atmega328P, atmega2560 and the attiny85, so you can test not only your target device but portability too.
Not so relevant to GCBasic but the C51, STM8S103 and the good old Z80 are supported and emulated too.
Several pre-designed training boards are included but, of far more use when testing GCB applications, so are the Breadboard or the GPBoard. Both boards provide access to all the device pins and the “Spare Parts” module allows you to connect Buttons, Switches, potentiometers etc. as inputs along with LED’s, Buzzers, servo motors and of course several LCD or 7 Segment displays.
You can also simulate RTC devices such as the ds1307 or pfc8563, port expanders like the MPC23S17, memory chips like the 24C family etc.
And for debugging it provides not only a serial terminal but a PIN Viewer and an MPLAB X Debugger plugin.
It also has a signal generator and an oscilloscope along with several other virtual tools.
Every program, patch and library that I have contributed to the Great Cow Basic Project have been developed and tested in PicSimLab as well as physical hardware.
And on final thought:
PicSimLab is designed and supported by a Brazilian University Professor who uses it to teach Microcontroller techniques to pre- and post- graduate students. And he is passionate about it. Over the years that I have been using it I have discovered and reported remarkably few bugs in specific microcontroller emulations and the Prof has fixed and posted the working version within 24 hours despite the 5 hour time difference.
There are others, and I have several, but PICSimLab followed by a physical breadboard and, finally, the target hardware is my choice of development tool chain.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
all of the good things you said about the simulator convinced
me to get a look to it, will be useful also for future needs..
I hate to have to learn yet another complex tool, however,
Instead of simplifying my firmware life with GCB as I initially tought,
it seems I have to "sweat" on learning other additional stuff.
Sometimes the learning curves of yet another sw makes you think to give up..
Between Spice/ PCB Cad / Compilers etc, if you do it for hobby,
you get tempted many times to switch to stamps collection..
Bye, GC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GC,
I setup a PIC16F1615 for a transmitter because there was some laying around.
I use ttl to usb adapters to test, trouble shoot and as power supplies.
So the transmitter is running off of the usb converter
I used a graphics LCD board with a PIC16F886 on for the receiver. Please do not get confused with the GLCD overhead stuff.
dim usart_input as string
dim k as Byte
k=0
Do
HSerGetString usart_input
'Locate 1,1
'Print usart_input
GLCDPrint ( 0, 0, usart_input)
wait 500 ms
GLCDCLS 'cls
loop
If you put #DEFINE USART_BLOCKING in you do not need
_#DEFINE USART_TX_BLOCKING, first staement does both TX and RX
#DEFINE USART_BAUD_RATE 9600
#DEFINE USART_TX_BLOCKING
#DEFINE USART_DELAY OFF
#DEFINE USART_BLOCKING
GetString does a good job.
I think your timing was off.
Hi Mike,
thanks for the time devoted to my issue..
Now I suspect even more that (lucky me) those 5 pieces of 18F1220 I had in a drawer have problems..
Found these errata sheets where it mentions that, among other things, the uC may have clock problems that influence the UART too (autobaud rate etc).
My guess is that the Transmission works (I saw it on the scope), but the Receiver can't lock in the incoming data (perhaps) because unable to adapt to the transmission pulses timing..
This morning (I live in italy) I can't, but later in the day I'll check with other chips and see what happens.
Then I'll let everybody know.
Have a good day,
GC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Evan,
I told you that the 47k resistor is not influent in the problem.. Yesterda, in the n tentatives I made I also removed that one, with same results. If you notice it, I had one placed also at the receiver pin on the uC (receiver) that drives the LCD. The first tests with or without it weremade to make sure that the edges of the tx/Rx were fast enough. Such an high value can't make any different in the output stage of a CMOS device, I am sure.
This afternoon wil make some more tests and let you know.
Thx for now,
GC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GC,
using a ttl-USB converter and a terminal program in your development PC , you could test the two modules separately. many times ,trouble shooting, "divide and conquer" , tells where the problem is. This would show more than a oscilloscope, It could send and receive the messages.
Having fun!
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As i said in a previous message, got that input early fm Evan..
I already ordered the TTL/ USB converters (three models,
CH340, PL2303 and CP2102, just to be sure one of them will work).
But they will be delivered to me with other stuff around
mid November..
While waiting I got the idea of the "Poor Man's Terminal"..
Thanks and rgds,
GC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Everybody, thanks to all whom had the patience to look at my issue..
I think I solved the problem: PIC18F1220 have troubles (among other things)
with the UART..
To prove it myself, after I tought of this yesterday and this morning
found the errata sheets, I made a rewire of the Receiver uC using
this time a PIC16F886 and keeping the Trasmitter uC with PIC18F1220
with the same short program..
Found that as I tought the 18F1220 in transmission "almost" works,
like the oscilloscope was telling me.. This is proved by my videos
attached, where fm time to time the first characters of the transmitted string
where read from the receiver, but soon the sync was lost, perhaps because
of clock shifts or whatever inside the chip. Most of the times only garbage is read.
But surely the reception on the PIC18F1220 never works!
Then I tried to loopback something on the PIC16F886, and found it works
quite well (however one char at a time, if not implemented a receiving
buffer). This when transmitting and receiving onto himself. I have to try (once
I get the USB/TTL adapter) to get a full string from an external Terminal.
Attached also the test programs.
Cheers,
GC
PS: sorry for the strange orientation of videos.. I am a scarce Videomaker.
No need to wait for the adaptor.
Use PicSimLab - It may look complex but that is only because it emulates so many different boards and Devices.
Run it, Select GPBoard under the Board menu
Select PIC18F1220 under the Micro controler Menu.
Select File Load Hex to import the hex file generated by GCBasic
Select Tools->Serial Terminal
Now you have a PC terminal connected to your programed target device.
Only one curve ball, you may need to create a virtual com port pairing.
Download and install com0com from here: http://sourceforge.net/projects/com0com/
Accept the default pairing of Com3 <> com4
In the GPBoard menu select File->Configure->and select Com3
In the Terminal emulator Select Com4
Debug away :)
p.s. you can use any terminal emulator connected to com4, CuteCom is just the bundled one.
Cheers
Chris
Last edit: Chris Roper 2023-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
done wgat you suggested, and have to admit is seems simple..
However I was''nt able to see any output on the terminal, after having loaded the Transmitter Hex and launched debug, I saw on the virtual scope that the uC is sending data to the terminal (virtually cross connected com3/4). But on the Terminal console does'nt appear any string..
I haven't read the doc yet, so will find out what happens... But it's just for getting familiar with PICSimLab too, as in this case perhaps the sw emulation may work, but if I have "defective" uCs I wil not realize it trough PicSimLab.
Thx & rgds,
GC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is a good start, not sure why you are not receiving anything.
Try starting a second instance of the terminal and set it to com4:
and see if the terminals can talk to each other.
If they can't then com<>com is not set up correctly.
If they can, then try writing some simple code to send a single character rather than a string and see if that works.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Chris,
I made some progresses with both GCB and Picsimlab..
Put down simple progs that turned on and off LEDs and they worked also on PicSimLab. But as soon as I try something more complex, I find problems.
In the attached GCB there is a program that works perfectly on a breadboard, printing data on an LCD and blinking an LED, reads a pushbutton to toggle another LED..
Also, it loopbacks a character on the Uart (TX/RX shorted).
When I try to simulate it on PicSimLab it does'nt work anymore.. a few questions for you (maybe you are familiar with PicSimLab and can quickly explain), on stuff that I did not find into PSL and its doc:
1) To use serial comm, one should put into the spare parts window the UART I/O module? In your previous instructions you did not mention it was necessary
2) Why nothing gets printed on the HD44780 LCD emulator module, perhaps it does'nt work on 4 data bits only and needs full 8 bit data?
3) Pins at LEDs assigned as in the real breadboard does'nt turn them on/off
4) Same as above for the pushbutton
I installed PicSimLab and com0com exactly as explained in PicSimLab doc, but can't use serial communications.. Pls note that opening two virtual sessions on Cutecom, I can send data from one terminal to the other (COM3/4) without problems.
Workspace and Main attached for reference.
Thx & Rgds,
GC
I am out of town at the moment so don't have access to my lab but if you haven't managed to resolve it by the time I get back next week I will fire it up and see if I can help.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that I am not lucky at all with the tools for GCB..
Here the latest news:
1) PicSimLab keeps not working.. I made several trials, but there is no way to make it work.. While my program on the breadboard works fine....! It's impossible to get infos on their spare parts like the LCD for example - it should work in the 4wires mode, but you can't be assured on their doc
2) I received yesterday the TTL to USB adapters I ordered, made a cable to swap them all alternatively onto PC/breadboard, and tried.. The first one (chip PL2303) did not work, and got error messege of obsolescence by PC device Mgr.. Tried to get the drivers for Win11: there are not.
The second one with the Silicon Lab chip (CP2102) also did not work immediately, but fortunately the W11 drivers were available and downloaded/ connected, HW seems ok.
Perhaps it would be good to give an advice to users that want to buy one adapter to make sure it works under their PC's OS.. For the time being I left out the check of the third model CH340
3) To make sure the SW terminals are ok I installed in addition to CuteCom the program Putty.. Both of them detect the USB/TTL adapter and work
I hate to give up, but boy! I tought that dealing with GCB should have been easy..
Nevertheless I am looking after what I am doing wrong with this simple task fo sending Hello World to the PC terminal. We'll see.
Rgds,
GC
Last edit: Anobium 2023-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PicSimLab certainly works with a character LCD in four wire mode. I fired it up and loaded an existing program that uses an LCD, once 'wired' correctly to my processor, it worked immediately.
I cannot make it work..
Would you mind to get a look and give a try to this simple example and tell me if it works for you? Perhaps something is wrong with my installation.. By the way I tested this morning the latest release of PicSimLba, Nov. 12, and still it does'nt print anything on the LCD module.
Thx,
GC
Windows 11, on a very low level Intel Silver N6000 based tablet.
Asking a dumb question, you have set the correct pins for the RS/RW/EN and four data lines?
I have included a screenshot of the properties for the LCD for my program I sent a picture of earlier, you'd need to set yours to the appropriate ones for your program:
Yes, I am sure I configured the right pins of the LCD in PICSimLab according to my source code.. You can verify it too, as I included the workspace file of PICSimLab, that includes the connections I made. But it does not work to me..
Did you try to load my workspace file and see if it runs on your machine? If positive, it would be clear that I have an issue with PICSimLab installation on my PC..
Thx and rgds,
GC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well...
Looking at this and loading your workspace, I see where the difference is.
You are using a "gpboard" which indeed does not work.
I am using a "breadboard" which does work.
There must be some difference(s) between the two boards that prevents the software from working. There are no schematics for the gpboard and it uses a different simulator engine to the breadboard (gpsim as opposed to picsim) so whether it is the way the board is 'wired' or the simulator I can't say.
Now I finally got the program working, sending and receiving small strings to/fm the PC Terminal.. Attached the code.
But the program hangs up at the instruction HSerGetString uart_input if I do not precede it with the command
if USARTHasData Then HSerGetString uart_input end if
If nothing arrives to the UART, the program flows continuosly.. But at the first string received, then it will hang up again at the line HSerGetString uart_input .
It seems that when using this instruction, the program waits until something comes in to the UART. For your input..
Rgds,
GC
@GC - Any any others experimenting with GCBasic
When starting out or experimenting with GCBasic it is a lot cheaper, faster and, I would argue, easier to debug when running an emulator.
Whilst GCBasic has not got an official emulator I can personally recommend the following:
PICSimLab
PICSimLab emulates many PIC chips so you can experiment with devices from the PIC10, PIC12, PIC16 and PIC18 families. It also emulates several of the AVR Devices including atmega328P, atmega2560 and the attiny85, so you can test not only your target device but portability too.
Not so relevant to GCBasic but the C51, STM8S103 and the good old Z80 are supported and emulated too.
Several pre-designed training boards are included but, of far more use when testing GCB applications, so are the Breadboard or the GPBoard. Both boards provide access to all the device pins and the “Spare Parts” module allows you to connect Buttons, Switches, potentiometers etc. as inputs along with LED’s, Buzzers, servo motors and of course several LCD or 7 Segment displays.
You can also simulate RTC devices such as the ds1307 or pfc8563, port expanders like the MPC23S17, memory chips like the 24C family etc.
And for debugging it provides not only a serial terminal but a PIN Viewer and an MPLAB X Debugger plugin.
It also has a signal generator and an oscilloscope along with several other virtual tools.
Every program, patch and library that I have contributed to the Great Cow Basic Project have been developed and tested in PicSimLab as well as physical hardware.
And on final thought:
PicSimLab is designed and supported by a Brazilian University Professor who uses it to teach Microcontroller techniques to pre- and post- graduate students. And he is passionate about it. Over the years that I have been using it I have discovered and reported remarkably few bugs in specific microcontroller emulations and the Prof has fixed and posted the working version within 24 hours despite the 5 hour time difference.
There are others, and I have several, but PICSimLab followed by a physical breadboard and, finally, the target hardware is my choice of development tool chain.
Cheers
Chris
Thanks Chris,
all of the good things you said about the simulator convinced
me to get a look to it, will be useful also for future needs..
I hate to have to learn yet another complex tool, however,
Instead of simplifying my firmware life with GCB as I initially tought,
it seems I have to "sweat" on learning other additional stuff.
Sometimes the learning curves of yet another sw makes you think to give up..
Between Spice/ PCB Cad / Compilers etc, if you do it for hobby,
you get tempted many times to switch to stamps collection..
Bye, GC
GC,
I setup a PIC16F1615 for a transmitter because there was some laying around.
I use ttl to usb adapters to test, trouble shoot and as power supplies.
So the transmitter is running off of the usb converter
I used a graphics LCD board with a PIC16F886 on for the receiver. Please do not get confused with the GLCD overhead stuff.
If you put #DEFINE USART_BLOCKING in you do not need
_#DEFINE USART_TX_BLOCKING, first staement does both TX and RX
GetString does a good job.
I think your timing was off.
Hi Mike,
thanks for the time devoted to my issue..
Now I suspect even more that (lucky me) those 5 pieces of 18F1220 I had in a drawer have problems..
Found these errata sheets where it mentions that, among other things, the uC may have clock problems that influence the UART too (autobaud rate etc).
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/Errata/80175e.pdf
https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/80324b.pdf
My guess is that the Transmission works (I saw it on the scope), but the Receiver can't lock in the incoming data (perhaps) because unable to adapt to the transmission pulses timing..
This morning (I live in italy) I can't, but later in the day I'll check with other chips and see what happens.
Then I'll let everybody know.
Have a good day,
GC
The Errata(s) are not applicable as the ASM does not use Auto-Baud rate.
I suspect the 47k resistor needs to be removed. But, a 47k here on my test rig... it still works. Most odd.
Last edit: Anobium 2023-10-31
Hi Evan,
I told you that the 47k resistor is not influent in the problem.. Yesterda, in the n tentatives I made I also removed that one, with same results. If you notice it, I had one placed also at the receiver pin on the uC (receiver) that drives the LCD. The first tests with or without it weremade to make sure that the edges of the tx/Rx were fast enough. Such an high value can't make any different in the output stage of a CMOS device, I am sure.
This afternoon wil make some more tests and let you know.
Thx for now,
GC
GC,
using a ttl-USB converter and a terminal program in your development PC , you could test the two modules separately. many times ,trouble shooting, "divide and conquer" , tells where the problem is. This would show more than a oscilloscope, It could send and receive the messages.
Having fun!
Mike
Yes Mike,
As i said in a previous message, got that input early fm Evan..
I already ordered the TTL/ USB converters (three models,
CH340, PL2303 and CP2102, just to be sure one of them will work).
But they will be delivered to me with other stuff around
mid November..
While waiting I got the idea of the "Poor Man's Terminal"..
Thanks and rgds,
GC
Hi Everybody, thanks to all whom had the patience to look at my issue..
I think I solved the problem: PIC18F1220 have troubles (among other things)
with the UART..
To prove it myself, after I tought of this yesterday and this morning
found the errata sheets, I made a rewire of the Receiver uC using
this time a PIC16F886 and keeping the Trasmitter uC with PIC18F1220
with the same short program..
Found that as I tought the 18F1220 in transmission "almost" works,
like the oscilloscope was telling me.. This is proved by my videos
attached, where fm time to time the first characters of the transmitted string
where read from the receiver, but soon the sync was lost, perhaps because
of clock shifts or whatever inside the chip. Most of the times only garbage is read.
But surely the reception on the PIC18F1220 never works!
Then I tried to loopback something on the PIC16F886, and found it works
quite well (however one char at a time, if not implemented a receiving
buffer). This when transmitting and receiving onto himself. I have to try (once
I get the USB/TTL adapter) to get a full string from an external Terminal.
Attached also the test programs.
Cheers,
GC
PS: sorry for the strange orientation of videos.. I am a scarce Videomaker.
No need to wait for the adaptor.
Use PicSimLab - It may look complex but that is only because it emulates so many different boards and Devices.
Run it, Select GPBoard under the Board menu
Select PIC18F1220 under the Micro controler Menu.
Select File Load Hex to import the hex file generated by GCBasic
Select Tools->Serial Terminal
Now you have a PC terminal connected to your programed target device.
Only one curve ball, you may need to create a virtual com port pairing.
Download and install com0com from here: http://sourceforge.net/projects/com0com/
Accept the default pairing of Com3 <> com4
In the GPBoard menu select File->Configure->and select Com3
In the Terminal emulator Select Com4
Debug away :)
p.s. you can use any terminal emulator connected to com4, CuteCom is just the bundled one.
Cheers
Chris
Last edit: Chris Roper 2023-10-31
Hi Chris,
done wgat you suggested, and have to admit is seems simple..
However I was''nt able to see any output on the terminal, after having loaded the Transmitter Hex and launched debug, I saw on the virtual scope that the uC is sending data to the terminal (virtually cross connected com3/4). But on the Terminal console does'nt appear any string..
I haven't read the doc yet, so will find out what happens... But it's just for getting familiar with PICSimLab too, as in this case perhaps the sw emulation may work, but if I have "defective" uCs I wil not realize it trough PicSimLab.
Thx & rgds,
GC
here what I get
That is a good start, not sure why you are not receiving anything.
Try starting a second instance of the terminal and set it to com4:
and see if the terminals can talk to each other.
If they can't then com<>com is not set up correctly.
If they can, then try writing some simple code to send a single character rather than a string and see if that works.
Cheers
Chris
@Chris
Hi Chris,
I made some progresses with both GCB and Picsimlab..
Put down simple progs that turned on and off LEDs and they worked also on PicSimLab. But as soon as I try something more complex, I find problems.
In the attached GCB there is a program that works perfectly on a breadboard, printing data on an LCD and blinking an LED, reads a pushbutton to toggle another LED..
Also, it loopbacks a character on the Uart (TX/RX shorted).
When I try to simulate it on PicSimLab it does'nt work anymore.. a few questions for you (maybe you are familiar with PicSimLab and can quickly explain), on stuff that I did not find into PSL and its doc:
1) To use serial comm, one should put into the spare parts window the UART I/O module? In your previous instructions you did not mention it was necessary
2) Why nothing gets printed on the HD44780 LCD emulator module, perhaps it does'nt work on 4 data bits only and needs full 8 bit data?
3) Pins at LEDs assigned as in the real breadboard does'nt turn them on/off
4) Same as above for the pushbutton
I installed PicSimLab and com0com exactly as explained in PicSimLab doc, but can't use serial communications.. Pls note that opening two virtual sessions on Cutecom, I can send data from one terminal to the other (COM3/4) without problems.
Workspace and Main attached for reference.
Thx & Rgds,
GC
Hi GC,
I am out of town at the moment so don't have access to my lab but if you haven't managed to resolve it by the time I get back next week I will fire it up and see if I can help.
Cheers
Chris
It seems that I am not lucky at all with the tools for GCB..
Here the latest news:
1) PicSimLab keeps not working.. I made several trials, but there is no way to make it work.. While my program on the breadboard works fine....! It's impossible to get infos on their spare parts like the LCD for example - it should work in the 4wires mode, but you can't be assured on their doc
2) I received yesterday the TTL to USB adapters I ordered, made a cable to swap them all alternatively onto PC/breadboard, and tried.. The first one (chip PL2303) did not work, and got error messege of obsolescence by PC device Mgr.. Tried to get the drivers for Win11: there are not.
The second one with the Silicon Lab chip (CP2102) also did not work immediately, but fortunately the W11 drivers were available and downloaded/ connected, HW seems ok.
Perhaps it would be good to give an advice to users that want to buy one adapter to make sure it works under their PC's OS.. For the time being I left out the check of the third model CH340
3) To make sure the SW terminals are ok I installed in addition to CuteCom the program Putty.. Both of them detect the USB/TTL adapter and work
4) Tried my loopback TX/RX program, but no luck
5) Copied exactly the Demo program that's here :
https://github.com/GreatCowBASIC/Demonstration_Sources/blob/main/Serial_Communications_Solutions/Serial_Microprocessors_to_PC_Terminal_Solutions/Send_to_PC_Terminal_Example_Direct_Connection_HardwareUART_16f877a.gcb
But also this one doesn't work..
I hate to give up, but boy! I tought that dealing with GCB should have been easy..
Nevertheless I am looking after what I am doing wrong with this simple task fo sending Hello World to the PC terminal. We'll see.
Rgds,
GC
Last edit: Anobium 2023-11-14
PicSimLab certainly works with a character LCD in four wire mode. I fired it up and loaded an existing program that uses an LCD, once 'wired' correctly to my processor, it worked immediately.
I cannot make it work..
Would you mind to get a look and give a try to this simple example and tell me if it works for you? Perhaps something is wrong with my installation.. By the way I tested this morning the latest release of PicSimLba, Nov. 12, and still it does'nt print anything on the LCD module.
Thx,
GC
I do not use that Sim. But, it works on Real Sim. But, the code to falsh the LED is not right. I get mesxages on the sim LCD.
Working here?
Windows 11, on a very low level Intel Silver N6000 based tablet.
Asking a dumb question, you have set the correct pins for the RS/RW/EN and four data lines?
I have included a screenshot of the properties for the LCD for my program I sent a picture of earlier, you'd need to set yours to the appropriate ones for your program:
RS A.5
RW A.6
EN A.7
.
.
.
.
D4 A.0
D5 A.1
D6 A.2
D7 A.3
Yes, I am sure I configured the right pins of the LCD in PICSimLab according to my source code.. You can verify it too, as I included the workspace file of PICSimLab, that includes the connections I made. But it does not work to me..
Did you try to load my workspace file and see if it runs on your machine? If positive, it would be clear that I have an issue with PICSimLab installation on my PC..
Thx and rgds,
GC
PS: please note that GCB source code works fine on real hardware..
Well...
Looking at this and loading your workspace, I see where the difference is.
You are using a "gpboard" which indeed does not work.
I am using a "breadboard" which does work.
There must be some difference(s) between the two boards that prevents the software from working. There are no schematics for the gpboard and it uses a different simulator engine to the breadboard (gpsim as opposed to picsim) so whether it is the way the board is 'wired' or the simulator I can't say.
One more question...
Now I finally got the program working, sending and receiving small strings to/fm the PC Terminal.. Attached the code.
But the program hangs up at the instruction HSerGetString uart_input if I do not precede it with the command
if USARTHasData Then HSerGetString uart_input end if
If nothing arrives to the UART, the program flows continuosly.. But at the first string received, then it will hang up again at the line HSerGetString uart_input .
It seems that when using this instruction, the program waits until something comes in to the UART. For your input..
Rgds,
GC