_Sorry for double postig; putted this to Great Cow Graphical BASIC Problems by mistake: _
Hi!
First I want to say THANK YOU for sharing this great piece of software with us. Written in Basic to write in Basic and able to compile for nearly all MCs I'm intersted in; awesome.
Now my problem:
This code works fine on an PIC16F688:
#chip 16F688, 4
#config Osc = Int
Dir PORTC.4 Out
#define USART_BLOCKING
#define USART_BAUD_RATE 1200
Dim SendByte, TestByte as byte
Dim TestArray(3)
Dim TestText as string
TestByte = 97
TestArray(2) = 98
TestText = "abc"
Start:
SendByte = TestByte
HSerSend SendByte 'gives "a"
SendByte = TestArray(2)
HSerSend SendByte 'gives "b"
SendByte = TestText(3)
HSerSend SendByte 'gives "c"
HSerSend 13
HSerSend 10
wait 500 ms
goto Start
With this similar code for my PIC18F13K50 only the "a" and <LF> <CR> are transmitted correct. It seems, it's not possible to store/get data to/from an array.:
'Possible bug in Great Cow Basic
'while accessing an array
'on PIC18F13K50
#chip 18F13k50, 2
#config Osc = Int
#define USART_BLOCKING
#define USART_BAUD_RATE 1200
Dir PORTB.7 Out
Dim SendByte, TestByte as byte
Dim TestArray(3)
Dim TestText as string
TestByte = 97
TestArray(2) = 98
TestText = "abc"
Start:
SendByte = TestByte
HSerSend SendByte 'gives "a"
SendByte = TestArray(2)
HSerSend SendByte 'should give "b" but gives a NullByte !
SendByte = TestText(3)
HSerSend SendByte 'should give "c" but gives a NullByte !
HSerSend 13
HSerSend 10
wait 500 ms
goto Start
GCB-Version is from 19/7/2011
Best regards
Steini
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 18F13K50 has an unusual data memory map with a gap in the general purpose RAM between 0x100 and 0x1FF that reads as 0x00 according to the datasheet. The dat file for the 18F13K50 though lists the FreeRAM area as 0x000 to 0x1FF so GCBasic is placing the arrays in that gap that reads as 0x00. If you edit the dat file to -
[FreeRAM]0:0FF200:2FF
it should place the arrays in the high block of RAM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just had a look at the datasheet, and there is definitely something odd about the memory arrangement! That block should fix it, I don't have an 18F13K50 handy to test, but the assembly looks ok. Will have to update the chip data file.
(Also, I deleted the duplicate post in GCGB problems.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just had a look at the datasheet, and there is definitely something odd about the memory arrangement! That block should fix it, I don't have an 18F13K50 handy to test, but the assembly looks ok. Will have to update the chip data file.
Tried the patch in chipdata-file and IT WORKS!
While trying the HSerPrint Function I noticed problems with longer strings (> 21 Bytes on PIC16f688 and > 41 Bytes in PIC18f13k50). It seems that string-memory can be overwritten:
#chip 16F688, 4
#config Osc = Int
#define USART_BLOCKING
#define USART_BAUD_RATE 1200
Dir PORTC.4 Out
Dim TestString as String
Dim TestArray(26)
TestString = "abcdefghijklmnopqrstuvwxyz"
TestArray = 65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,85,86,87,88,89,90
Start:
'Output:
HSerSend TestString(0) '26
HSerSend TestString(19) '115 "s"
HSerSend TestString(20) '116 "t"
HSerSend TestString(21) '117 "u"
HSerSend TestString(22) '25
HSerSend TestString(23) '65 "A"
HSerSend TestString(24) '66 "B"
HSerSend TestString(25) '67 "C"
HSerSend TestString(26) '68 "D"
HSerSend 13 '13
HSerSend 10 '10
wait 1 s
Steini
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
O.K., find out something about the string-overwrite problem, mentioned above:
GCBASIC Command Guide.doc:
Known Limitations:
…
• Array size: 80 bytes on 10/12/16, 255 bytes on 18 (Avoid large arrays
wherever possible)
• String length: 20 characters default, 80 if declared using DIM
…
The 20 characters limit and the lack of "range check" seems to be the reason for overwriting the string, which is 26 long.
"Declaring using DIM" is working as "DIM TestString * 80" ? I tried this out and looks o.k.
Arrays (and string too) are without "range check".
DIM TestAray(10)
TestArray(15) = 99
… is possible without error message (but can crash our prog).
Hope, I'm right and it may be helpful !?
Steini
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
_Sorry for double postig; putted this to Great Cow Graphical BASIC Problems by mistake: _
Hi!
First I want to say THANK YOU for sharing this great piece of software with us. Written in Basic to write in Basic and able to compile for nearly all MCs I'm intersted in; awesome.
Now my problem:
This code works fine on an PIC16F688:
With this similar code for my PIC18F13K50 only the "a" and <LF> <CR> are transmitted correct. It seems, it's not possible to store/get data to/from an array.:
GCB-Version is from 19/7/2011
Best regards
Steini
The 18F13K50 has an unusual data memory map with a gap in the general purpose RAM between 0x100 and 0x1FF that reads as 0x00 according to the datasheet. The dat file for the 18F13K50 though lists the FreeRAM area as 0x000 to 0x1FF so GCBasic is placing the arrays in that gap that reads as 0x00. If you edit the dat file to -
it should place the arrays in the high block of RAM.
Just had a look at the datasheet, and there is definitely something odd about the memory arrangement! That block should fix it, I don't have an 18F13K50 handy to test, but the assembly looks ok. Will have to update the chip data file.
(Also, I deleted the duplicate post in GCGB problems.)
Thank you for the quick reply.
Tried the patch in chipdata-file and IT WORKS!
While trying the HSerPrint Function I noticed problems with longer strings (> 21 Bytes on PIC16f688 and > 41 Bytes in PIC18f13k50). It seems that string-memory can be overwritten:
Steini
O.K., find out something about the string-overwrite problem, mentioned above:
GCBASIC Command Guide.doc:
The 20 characters limit and the lack of "range check" seems to be the reason for overwriting the string, which is 26 long.
"Declaring using DIM" is working as "DIM TestString * 80" ? I tried this out and looks o.k.
Arrays (and string too) are without "range check".
… is possible without error message (but can crash our prog).
Hope, I'm right and it may be helpful !?
Steini
Hi Hugh!
The RAM in 18f13k50 from 100h to 1FFh is definitively not usable (always returning 0). I find that in the datasheet:
For the 18f14k50 the same region can be used as general purpose RAM (when not used as USB buffer).:
So in my opinion the entries in the second post are correct for 18lf13k50.dat and 18lf13k50.dat :
And for 18lf14k50.dat and 18f14k50.dat :
Would be nice, if you update the chipdata-files the next chance.
Regards
_________________________
Steini