If Great Cow BASIC is not working as it should, please do not hesitate to post here or email one of the admins. We want it to be the best language for PIC chips available!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
#define LCD_IO 2 ' 2 wire connection: for schematics have a look to: http://www.rentron.com/Myke1.htm
#Define LCD_DB Porta.0 ' Required: pin where Data Bit is wired
#Define LCD_CB Porta.1 ' Required: pin where Clock Bit is wired
CLS ' clear LCD
LOCATE 1,0 ' put Cursor on first Row, first Column
PRINT "Hi, how are you?" ' Write something on LCD
Put 2,1,32 ' Write a Space Character on Second Line, second Col
LOCATE 2,0
Newbyte = 253
LCDINT Newbyte ' Write Integer on LCD
Post for any question
Best Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks you so much!
I translate your sample program to 12F675 and works fine. In this little pic really you appreciate the convenience of two wire LCD. My best regards to you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to say that I like the compiler a lot...
...but just as I was getting into it and making a fairly complex
program I hit the 2048 page boundary in a 16F877A. I found the other
thread about this here:
But this seems to have stopped with no resolution (apparently).
I know it's the boundary problem (as I can remove a small section of code and the program starts working again) also when I use compile.bat looking at the compile.lst shows the program usage going over the 2048 boundary.
I have installed the latest GCBASIC (0.9 15/10/2007)
and update.zip (so gcbasic can use the built in assembler) - whether or not I
use the built in assembler or gputils it still fails when code is long.
Using #option lcall does not resolve the problem although the stated assembler mnemonics are inserted i.e. pagesel $
It is a shame as the program looks like a great alternative to the commercial ones that are available (and I know it's good as I have come far enough to use it in a complex program) however the commercial ones have a 2k limit so without resolving this gcbasic has no advantage over the commercial ones.
"But this seems to have stopped with no resolution (apparently). "
To my knowledge the #option lcall did the job at that particular time. As I remember, the only complaint was that it added 600 or more words to the program.
Haven't had to use it for a long while, maybe something went wrong between then, and the latest update?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The lcall code was working, but I damaged some of it while implementing the bootloader support. The fixed compiler is at http://gcbasic.sourceforge.net/newfiles/lcallpatch.zip - install this over the top of update.zip.
I'll write some proper program memory bank handling code asap, hopefully by this time next week. The current code in GCBASIC based around #option lcall is very rushed and not properly thought out, and I look forward to getting rid of it.
update.zip hasn't been fixed, but will be dealt with once the new code is implemented.
GCBASIC does still have one minor advantage over commercial demo compilers with regard to program size - there isn't a 2k limit on 18F chips.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been using Great Cow BASIC for about a month now and I have been quite impressed with it so far. I completed a project to sample an audio track and move a servo to make my Halloween props speak it works very well and is very simple. I look forward to using it more and hope to contribute some sample code to help beginners get started soon.
Thank you for all of your hard work and making this open source.
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 2k limit comes about because of the goto and call instructions on the 16F chips. They can only supply the lowest 11 bits of the new address, but it takes 12 to address all of the locations in a chip with 4096 (2 ^ 12) words of flash, or 13 for a chip with 8192 words.
The simplest solution to this is for the compiler to add "pagesel" before every goto or call. The pagesel instruction will supply the missing bit or bits. However, this will increase the size of a goto or call from 1 to 2 or 3 instructions, and breaks any inline assembly that doesn't allow for the adding of the extra instructions (in the same way as the banksel instructions are interferring with the divide and multiply routines now).
This is basically what #option lcall will do. (lcall is a macro in PIC assembly, it's the same as inserting a pagesel and then the call.)
However, #option lcall will make sure that no subroutine spans multiple program memory pages, so goto instructions don't have to be dealt with. Unfortunately, older versions of GCBASIC combine all of the subroutines in alphabetical order, and then compile. Once this is done, there's no easy way to rearrange the subroutines to fit into the available memory, so the compiler just inserts blank space to force a sub onto the next page if needed.
The most recent version of GCBASIC uses a better solution. It compiles the subroutines, then combines them. This means that it knows the size of the subroutine when it's trying to place it into the program memory, so it can pack them in much more tightly together. It can also tell when to use pagesel, so hopefully no memory is wasted fitting things in.
Some of the new bugs in the latest release are because of this change - GCBASIC now has to compile the program a subroutine at a time instead of compiling the entire program in one go. This meant changing every part of GCBASIC that does any compilation.
18F PICs have goto and call instructions that can supply 20 bits of the address, enough to jump to any location in a PIC with up to 1MB (2^20 locations) of program memory! So none of this applies on an 18F.
So, in summary: With older versions of GCBASIC, there is no reliable way to use any more than 2048 instructions on a 16F. Use the latest version of GCBASIC (May 2009 release) and there should be no problems with larger chips - although a few other things are not working now! Or, use an 18F chip, and write a program as large as you like.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok I was completely 100% wrong.
Not sure why I was able to get my code running this high.
I have too many compliers, and apps I guess.
I must have compiled it wrong and used an old hex or something.
I was working on one last night and all the subs were up high and variables were looking good. I added a few more calls to my main and poof, 2k boundry "Overwrite" limit errors, thousands of them. lol
So I do not know what I did the other day, but it don't work now.
So it "IS" still an issue on 16F series.
Sorry for all the confusion here. I got to get more sleep!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried the new update zip on my 16F946 program and got this:
Error: Program is too large, cannot fit all subroutines into available program memory.
My program is just a hair over 4.5k when I compile under a 18Fxxxx series no errors and looking at asm it is about 4.5k.
The 16F946 chip is an 8k so I assume it would compile also.
This is what is at then end of the asm when compiled under a 16F946 chip.
Perhaps it grows too large when compiled under the 16F but is fine under the 18F?
Sorry for the double post but I also notice this in the vari declares.
> SYSSTRINGPARAM1 EQU 473
This chip does not have ram that high only 336, so is it using the LCD pixel ram location?
Also I have Z_ on all my vari yet the sys's are in the 100's.
I know you reworked CGB Hugh so just curious, may not even be an issue. My program only ever worked when all the sys calls were in the 1st bank of memory only.
I've no idea what is going on with the error message. Please email me the program or post it here, I'll put it through GCBASIC, watch what happens, and do the best I can to fix it. Programs are usually slightly larger when compiled for a 16F, but page 3 being empty makes me suspect that there's a bug in the code responsible for deciding which subroutine goes into which page of program memory.
That memory allocation is fine, the memory arrangement of 16Fs is a mess! The RAM isn't arranged in a single area, each bank has 32 bytes of special function registers and some amount of RAM, typically 96 or 80 bytes. Location 473 is toward the end of the last bank of RAM. The system variables are being placed into the common RAM - this is the area between 112 and 127 (0x70 and 0x7F) on most chips, and can be accessed regardless of what bank the PIC is in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool, thanks Hugh I'll send my code to you when I get home tonight for ya to pound on. I know the ram bank and amounts across them that is why I posted the second post it's was too high, there is no way you can get to 473 when there is only 336 of ram locations. But this chip has that lcd pixel area that can be used for ram also. In the DS in mentions it, but I have no intention of using it. It's hard enought just to get this chip to work right with any code (asm) let alone GCB. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it is for rally odometer
it counts pulses from probe1 and 10 times second send data to PC via rs232.
clock is 19,66 MHz (common freq. for CDA systems, see wikipedia about Crystal oscillator)
baud rate 19200
software bit banging, but need to optimize.
in some places there is problems with IF statemet, don't remember where exaclty. probably in
if countervalue>1920 then
sometimes i get errors with IF
more about code this cray code.
i need to count pulses from wheel probe 10 times per second ans send results to PC for calculations.
there are many tasks in this uC:
timed task for serial bit bang
timed task 10 times/second
task to prepare serial data
serial protocol looks like this string:
B (0x66) begin data
pulses (binary 0 to 255)
E (0x69) end data
"BpulsesE"
interrupts?
I DON'T want to miss any pulses.
do the only interrupt goes to probe counting...
NO timer interrupt or what ever
In main loop I put all may other tasks.
how to handle timer regularly?
just check timer owerflow flag
if flag set, then proseed timer task.
how to handle 10 ties/secod?
on each timer overflow cimply increment another variabe (I called it postscaler)
when postscaler will be more than something thaen set send to serial flag active.
what if probe add pulse while we send data?
simply copy from probe counter to local variable and work with this varible NOT probe counter's variable.
on backbound put the serial string tash, who will form serial string when necessery.
this unusual concept will make bit banging and will not lose any pulses. Now i need just to optimize timer code, because I am not shure for good serial timings.
GCBASIC is good when You must quicky make code, it is more readible than pure asm and You can more easly see idea.
There are lot of comments in code, just ignore them.
I don't like timer init commands. I just need initialize timer without prescaler.
Some time ago I changed GCBASIC includes, but result code was huge (20 or more operands). So it is good thing that You know ASM and put it in you basic program.
Just to it! GC is good, if You know ASM and know what to do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This buggy code compiles for 12F675
#config osc = int
#config INTOSC_OSC_NOCLKOUT, BODEN_OFF
#chip 12F675, 0.125
DIR GP0 in '
DIR GP1 in '
DIR GP2 in 'LD1
DIR GP3 in 'mclr
DIR GP4 in 'LD2
DIR GP5 in 'SW1
' Note: all are set as input in order to compile
do while 1
Set GP2 On 'Note: requires "DIR GP2 out"
Wait 500 ms
Set GP2 Off
loop
But If I set
DIR GP2 out 'LD1
DIR GP4 out 'LD2
then compiler says "TRIS2, TRIS4 not defined"
and compiled.asm contains:
"
;Set aside memory locations for variables
DELAYTEMP EQU 32
DELAYTEMP2 EQU 33
SysWaitTempMS EQU 34
SysWaitTempMS_H EQU 35
TRIS0 EQU 36
TRIS1 EQU 37
TRIS3 EQU 38
TRIS5 EQU 39
"
so TRIS2, TRIS4 wont get defined when IObits 2,4 are defined as output
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If Great Cow BASIC is not working as it should, please do not hesitate to post here or email one of the admins. We want it to be the best language for PIC chips available!
THE GCBASIC COMPILER DOES NOT WORKS ON PIC 12F675 PROGRAM, COMPILES WELL BUT DOES NOT WORK AT ALL
Could you please post your program here so that I can look at it?
Hi Nobody!
I tried to write a simple program for 12F675, a random generator. I simulated it with MPLAB and all is OK.
the code is:
-----------------------------------
'pseudo random generator
#chip 12F675, 20
#mem 64
'
' ----\_/----
' I/O Vdd--| |--Vss
' I/O GP5--| |--GP0
' I/O GP4--| |--GP1
' in GP3--| |--GP2
' -----------
'
#chip 12F675, 4
#mem 64
#config _BODEN_OFF & _CP_OFF & _PWRTE_OFF & _WDT_OFF & _MCLRE_OFF & _INTRC_OSC_NOCLKOUT
DIR GPIO b'00001000' 'GP3 as input
movlw 0x07 'comparator off
movwf CMCON
INTCON=0
ANSEL=0
Main:
val1=b'10110100'
val2=b'00010101'
val3=b'11001100'
loop1:
val2=val1+val2
tmp1=val2+val3
val3=tmp1
val1=val1+tmp1
swapf val1,f
GPIO=val1
goto loop1
---------------------------
It seems to me that GCBASIC works fine with 12F675.
Regards
stefano
I would to see a program that use the GCBASIC 2 wire LCD recently implemented, thanks in advance..
Hi!
I am currently using the 2 wire LCD implementation, and so here a little example for you:
#chip 16F690,4
#config _INTRC_OSC_NOCLKOUT, _WDT_OFF,_PWRTE_OFF,_MCLRE_OFF,_CP_OFF, _BOR_OFF, _IESO_OFF,_FCMEN_OFF
#define LCD_IO 2 ' 2 wire connection: for schematics have a look to: http://www.rentron.com/Myke1.htm
#Define LCD_DB Porta.0 ' Required: pin where Data Bit is wired
#Define LCD_CB Porta.1 ' Required: pin where Clock Bit is wired
CLS ' clear LCD
LOCATE 1,0 ' put Cursor on first Row, first Column
PRINT "Hi, how are you?" ' Write something on LCD
Put 2,1,32 ' Write a Space Character on Second Line, second Col
LOCATE 2,0
Newbyte = 253
LCDINT Newbyte ' Write Integer on LCD
Post for any question
Best Regards
Thanks you so much!
I translate your sample program to 12F675 and works fine. In this little pic really you appreciate the convenience of two wire LCD. My best regards to you.
Hi I'm John Main,
Just wanted to say that I like the compiler a lot...
...but just as I was getting into it and making a fairly complex
program I hit the 2048 page boundary in a 16F877A. I found the other
thread about this here:
https://sourceforge.net/forum/message.php?msg_id=4195465
But this seems to have stopped with no resolution (apparently).
I know it's the boundary problem (as I can remove a small section of code and the program starts working again) also when I use compile.bat looking at the compile.lst shows the program usage going over the 2048 boundary.
I have installed the latest GCBASIC (0.9 15/10/2007)
and update.zip (so gcbasic can use the built in assembler) - whether or not I
use the built in assembler or gputils it still fails when code is long.
Using #option lcall does not resolve the problem although the stated assembler mnemonics are inserted i.e. pagesel $
It is a shame as the program looks like a great alternative to the commercial ones that are available (and I know it's good as I have come far enough to use it in a complex program) however the commercial ones have a 2k limit so without resolving this gcbasic has no advantage over the commercial ones.
John Main
http://www.best-microcontroller-projects.com
I haven't got an email back to login yet but you can contact me at here sourceforge AT best-microcontroller-projects.com works.
"But this seems to have stopped with no resolution (apparently). "
To my knowledge the #option lcall did the job at that particular time. As I remember, the only complaint was that it added 600 or more words to the program.
Haven't had to use it for a long while, maybe something went wrong between then, and the latest update?
The lcall code was working, but I damaged some of it while implementing the bootloader support. The fixed compiler is at http://gcbasic.sourceforge.net/newfiles/lcallpatch.zip - install this over the top of update.zip.
I'll write some proper program memory bank handling code asap, hopefully by this time next week. The current code in GCBASIC based around #option lcall is very rushed and not properly thought out, and I look forward to getting rid of it.
update.zip hasn't been fixed, but will be dealt with once the new code is implemented.
GCBASIC does still have one minor advantage over commercial demo compilers with regard to program size - there isn't a 2k limit on 18F chips.
I have been using Great Cow BASIC for about a month now and I have been quite impressed with it so far. I completed a project to sample an audio track and move a servo to make my Halloween props speak it works very well and is very simple. I look forward to using it more and hope to contribute some sample code to help beginners get started soon.
Thank you for all of your hard work and making this open source.
Craig
Hugh, Kent can you explain/update me a bit on this since I use mostly 16F chips currently?
I know I am about to go over 2k soon on some projects I am bulding so hence my interest or concern.
If my chip has over 2k program memory which all of them I use do either have 4k or 8k memory space up to 4 banks, is this a problem in GCB still?
And what is the best way to handle once I do run over this 2k limit? I've seen the lcall mentioned but not sure where it ended up at in GCB.
Thanks
Zm
The 2k limit comes about because of the goto and call instructions on the 16F chips. They can only supply the lowest 11 bits of the new address, but it takes 12 to address all of the locations in a chip with 4096 (2 ^ 12) words of flash, or 13 for a chip with 8192 words.
The simplest solution to this is for the compiler to add "pagesel" before every goto or call. The pagesel instruction will supply the missing bit or bits. However, this will increase the size of a goto or call from 1 to 2 or 3 instructions, and breaks any inline assembly that doesn't allow for the adding of the extra instructions (in the same way as the banksel instructions are interferring with the divide and multiply routines now).
This is basically what #option lcall will do. (lcall is a macro in PIC assembly, it's the same as inserting a pagesel and then the call.)
However, #option lcall will make sure that no subroutine spans multiple program memory pages, so goto instructions don't have to be dealt with. Unfortunately, older versions of GCBASIC combine all of the subroutines in alphabetical order, and then compile. Once this is done, there's no easy way to rearrange the subroutines to fit into the available memory, so the compiler just inserts blank space to force a sub onto the next page if needed.
The most recent version of GCBASIC uses a better solution. It compiles the subroutines, then combines them. This means that it knows the size of the subroutine when it's trying to place it into the program memory, so it can pack them in much more tightly together. It can also tell when to use pagesel, so hopefully no memory is wasted fitting things in.
Some of the new bugs in the latest release are because of this change - GCBASIC now has to compile the program a subroutine at a time instead of compiling the entire program in one go. This meant changing every part of GCBASIC that does any compilation.
18F PICs have goto and call instructions that can supply 20 bits of the address, enough to jump to any location in a PIC with up to 1MB (2^20 locations) of program memory! So none of this applies on an 18F.
So, in summary: With older versions of GCBASIC, there is no reliable way to use any more than 2048 instructions on a 16F. Use the latest version of GCBASIC (May 2009 release) and there should be no problems with larger chips - although a few other things are not working now! Or, use an 18F chip, and write a program as large as you like.
Thank Hugh, that is what I imagined but you made it very clear on how and why. Info very useful.
Mz
Is the lcallpatch.zip still available?
The link above is broke.
I was goofing around with just writting a program that jumps the 2k boundry to try some simple jumps / goto / calls out.
Also if GCB allows assembly inline then why the errors when trying pagesel and banksel inline?
Mz
Ah I am a bonehead guys.
I forgot to add the #option lcall to my program.
DOH!
It jumps over now.
Cool, now for some testing. Ahhh..
Mz
Ok I have been able to get a long program to run using all lcalls and using Z_ in front of all variables on 16F series:
1) be over 2k and over 4k
2) have over 300+ variables mixed byte and word
3) must keep all sys and math functions in 1st bank
When looking at the asm, as long as all the sys calls stay in the 1st bank and no math functions go into another bank everything works.
Program calls jump correct and varibles do not get corrupt and the program does not jump out wild to some other location.
So, based on this I would assume that any sys/math calls need to be in the 1st bank period.?.
I have reworked a few of my programs and they work fine and I can add tons more variables with no issues now.
Great news for any 16f lovers...
Thought I would share.
Jz
Ok I was completely 100% wrong.
Not sure why I was able to get my code running this high.
I have too many compliers, and apps I guess.
I must have compiled it wrong and used an old hex or something.
I was working on one last night and all the subs were up high and variables were looking good. I added a few more calls to my main and poof, 2k boundry "Overwrite" limit errors, thousands of them. lol
So I do not know what I did the other day, but it don't work now.
So it "IS" still an issue on 16F series.
Sorry for all the confusion here. I got to get more sleep!
Try the new update.zip, hopefully that will deal with this problem! Any more errors, please let me know and I'll do the best I can to get rid of them.
Tried the new update zip on my 16F946 program and got this:
Error: Program is too large, cannot fit all subroutines into available program memory.
My program is just a hair over 4.5k when I compile under a 18Fxxxx series no errors and looking at asm it is about 4.5k.
The 16F946 chip is an 8k so I assume it would compile also.
This is what is at then end of the asm when compiled under a 16F946 chip.
Perhaps it grows too large when compiled under the 16F but is fine under the 18F?
;***********************************************************
;Start of program memory page 3
ORG 6144
END
Sorry for the double post but I also notice this in the vari declares.
> SYSSTRINGPARAM1 EQU 473
This chip does not have ram that high only 336, so is it using the LCD pixel ram location?
Also I have Z_ on all my vari yet the sys's are in the 100's.
I know you reworked CGB Hugh so just curious, may not even be an issue. My program only ever worked when all the sys calls were in the 1st bank of memory only.
;******************************************************************
;Set aside memory locations for variables
DELAYTEMP EQU 112
DELAYTEMP2 EQU 113
SYSDIVMULTA EQU 119
SYSDIVMULTA_H EQU 120
SYSDIVMULTB EQU 123
SYSDIVMULTB_H EQU 124
SYSDIVMULTX EQU 114
SYSDIVMULTX_H EQU 115
SYSSTRINGLENGTH EQU 118
SysCalcTempA EQU 117
SysCalcTempA_H EQU 118
SysCalcTempB EQU 121
SysCalcTempB_H EQU 122
SysCalcTempX EQU 112
SysCalcTempX_H EQU 113
SysStringA EQU 119
SysStringA_H EQU 120
SysStringB EQU 114
SysStringB_H EQU 115
SysWaitTemp10US EQU 117
SysWaitTempMS EQU 114
SysWaitTempMS_H EQU 115
SysWaitTempS EQU 116
SysWaitTempUS EQU 117
SysWaitTempUS_H EQU 118
SYSSTRINGPARAM1 EQU 473 <------------ to high
ADDR EQU 32
ADDR_H EQU 33
ADREADPORT EQU 34
ADTEMP EQU 35
COMMAND_WRITE EQU 36
I've no idea what is going on with the error message. Please email me the program or post it here, I'll put it through GCBASIC, watch what happens, and do the best I can to fix it. Programs are usually slightly larger when compiled for a 16F, but page 3 being empty makes me suspect that there's a bug in the code responsible for deciding which subroutine goes into which page of program memory.
That memory allocation is fine, the memory arrangement of 16Fs is a mess! The RAM isn't arranged in a single area, each bank has 32 bytes of special function registers and some amount of RAM, typically 96 or 80 bytes. Location 473 is toward the end of the last bank of RAM. The system variables are being placed into the common RAM - this is the area between 112 and 127 (0x70 and 0x7F) on most chips, and can be accessed regardless of what bank the PIC is in.
Cool, thanks Hugh I'll send my code to you when I get home tonight for ya to pound on. I know the ram bank and amounts across them that is why I posted the second post it's was too high, there is no way you can get to 473 when there is only 336 of ram locations. But this chip has that lcd pixel area that can be used for ram also. In the DS in mentions it, but I have no intention of using it. It's hard enought just to get this chip to work right with any code (asm) let alone GCB. :)
gcbasic is working, but it still has bugs...
As I a familiar with ASM, I can edit manually and simulate in MPLAB.
look on this strange code:
'================================================================
'===== CHIP SETUP
'================================================================
#chip 16F84A, 20
#config HS_OSC, WDT_OFF,PWRTE_ON,CP_ON
#define tmr0owflow INTCON.T0IF
#define carry STATUS.C
''#define pullup option_reg.NOT_RBPU
'#define wdtout porta.2
#define rs232 PORTA.3
''#define pidpin porta.1
#define probe1 portb.6
''#define probe1 portb.4
''#define probe2 portb.5
dim Countervalue as word
dim wdtCounter as word
''dim pid as byte
dim comsend as bit
dim comgo as bit
''dim wdtbit as bit
''dim wdtfreq as word
dim curbuff as byte
''dim curbuff2 as byte
dim ubuff1 as byte
''dim ubuff2 as byte
dim curbit as byte
dim nextchar as byte
dim p1 as byte
''dim p2 as byte
On Interrupt PORTBChange Call probe
Startup:
''InitTimer0 (Osc, PS0_1/2)
CounterValue = 0
''set pullup on
'================================================================
'===== SET DIRECTION OF THE PORTS
'================================================================
Dir rs232 out
''Dir wdtout out
''dir portb out
''pid=0
set comsend off
set rs232 off
movlw b'11001111' 'no prescaler
''movlw b'11000000' 'prescaler 1/2
'banksel OPTION_REG
movwf option_reg
clrf trisb
''wait 10 ms
dir probe1 in
''pid=2
''wdtfreq=480
'if pidpin off then pid=0
''if pidpin on then
'' pid --
'' wdtfreq=0
''end if
'================================================================
'===== MAIN PROGRAM LOOP
'================================================================
Main:
if tmr0owflow on then
set tmr0owflow off
countervalue ++
''wdtCounter ++
'RS-232 stuff
if comsend on then
select case curbit
case 0 'start bit
set rs232 on
case 1 'bit 0
if curbuff.0 off then set rs232 on
if curbuff.0 on then set rs232 off
case 2 'bit 1
if curbuff.1 off then set rs232 on
if curbuff.1 on then set rs232 off
case 3 'bit 2
if curbuff.2 off then set rs232 on
if curbuff.2 on then set rs232 off
case 4 'bit 3
if curbuff.3 off then set rs232 on
if curbuff.3 on then set rs232 off
case 5 'bit 4
if curbuff.4 off then set rs232 on
if curbuff.4 on then set rs232 off
case 6 'bit 5
if curbuff.5 off then set rs232 on
if curbuff.5 on then set rs232 off
case 7 'bit 6
if curbuff.6 off then set rs232 on
if curbuff.6 on then set rs232 off
case 8 'bit 7
if curbuff.7 off then set rs232 on
if curbuff.7 on then set rs232 off
case 9 'stop bit 1
set rs232 off
case 10 'stop bit 2
set rs232 off
set comsend off
curbit=255
nextchar ++
set comgo on
'case else
end select
curbit ++
end if
'clear watchdog
end if
if comgo on then
select case nextchar
case 0
curbuff=66
case 1
curbuff=ubuff1
case 2
curbuff=69
case 3
nextchar=0
set comgo off
goto endcomGO
end select
set comsend on
set comgo off
end if
endComGo:
if countervalue>1920 then 'no prescaler
''if countervalue>960 then 'prescaler 1/2 9600 100 ms
countervalue=0
ubuff1=p1
p1=ubuff1-p1
''ubuff2=p2
''p2=ubuff2-p2
set comgo on
end if
''if wdtCounter>wdtfreq then
'' wdtCounter=0
'' if wdtout on then set wdtbit off
'' if wdtout off then set wdtbit on
'' if wdtbit on then set wdtout on
'' if wdtbit off then set wdtout off
''end if
Goto Main
'================================================================
'===== SUBROUTINES AND FUNCTIONS
'================================================================
Sub probe
if probe1 off then p1 ++
''if probe2 off then p2 ++
end sub
it is for rally odometer
it counts pulses from probe1 and 10 times second send data to PC via rs232.
clock is 19,66 MHz (common freq. for CDA systems, see wikipedia about Crystal oscillator)
baud rate 19200
software bit banging, but need to optimize.
in some places there is problems with IF statemet, don't remember where exaclty. probably in
if countervalue>1920 then
sometimes i get errors with IF
more about code this cray code.
i need to count pulses from wheel probe 10 times per second ans send results to PC for calculations.
there are many tasks in this uC:
timed task for serial bit bang
timed task 10 times/second
task to prepare serial data
serial protocol looks like this string:
B (0x66) begin data
pulses (binary 0 to 255)
E (0x69) end data
"BpulsesE"
interrupts?
I DON'T want to miss any pulses.
do the only interrupt goes to probe counting...
NO timer interrupt or what ever
In main loop I put all may other tasks.
how to handle timer regularly?
just check timer owerflow flag
if flag set, then proseed timer task.
how to handle 10 ties/secod?
on each timer overflow cimply increment another variabe (I called it postscaler)
when postscaler will be more than something thaen set send to serial flag active.
what if probe add pulse while we send data?
simply copy from probe counter to local variable and work with this varible NOT probe counter's variable.
on backbound put the serial string tash, who will form serial string when necessery.
this unusual concept will make bit banging and will not lose any pulses. Now i need just to optimize timer code, because I am not shure for good serial timings.
GCBASIC is good when You must quicky make code, it is more readible than pure asm and You can more easly see idea.
There are lot of comments in code, just ignore them.
I don't like timer init commands. I just need initialize timer without prescaler.
Some time ago I changed GCBASIC includes, but result code was huge (20 or more operands). So it is good thing that You know ASM and put it in you basic program.
Just to it! GC is good, if You know ASM and know what to do.
This buggy code compiles for 12F675
#config osc = int
#config INTOSC_OSC_NOCLKOUT, BODEN_OFF
#chip 12F675, 0.125
DIR GP0 in '
DIR GP1 in '
DIR GP2 in 'LD1
DIR GP3 in 'mclr
DIR GP4 in 'LD2
DIR GP5 in 'SW1
' Note: all are set as input in order to compile
do while 1
Set GP2 On 'Note: requires "DIR GP2 out"
Wait 500 ms
Set GP2 Off
loop
But If I set
DIR GP2 out 'LD1
DIR GP4 out 'LD2
then compiler says "TRIS2, TRIS4 not defined"
and compiled.asm contains:
"
;Set aside memory locations for variables
DELAYTEMP EQU 32
DELAYTEMP2 EQU 33
SysWaitTempMS EQU 34
SysWaitTempMS_H EQU 35
TRIS0 EQU 36
TRIS1 EQU 37
TRIS3 EQU 38
TRIS5 EQU 39
"
so TRIS2, TRIS4 wont get defined when IObits 2,4 are defined as output