Hello.
Outputs same codes for abc as for ABC. Seems like characters are converted to uppercase?Code:topline var byte [6]
arraywrite topline, ["ABCabc"]
FOR X=0 TO 6
LCDOUT $FE, $01, DEC topline[x]
pause 1000
next
Any ways to fix this?
Printable View
Hello.
Outputs same codes for abc as for ABC. Seems like characters are converted to uppercase?Code:topline var byte [6]
arraywrite topline, ["ABCabc"]
FOR X=0 TO 6
LCDOUT $FE, $01, DEC topline[x]
pause 1000
next
Any ways to fix this?
What device are you running this on?
Here it works fine (18F57Q43)Outputs:Code:Start:
HSEROUT["Start", 10,13]
arraywrite topline, ["ABCabc"]
FOR X=0 TO 6
HSEROUT [DEC topline[x],10,13]
next
With the 23 at the end being because you're reading past the last character written to the array.Code:Start
65
66
67
97
98
99
23
Pic16f886.
I don't have that chip handy but I did compile the code for it and looked at the .lst file. Needless to say I can't see anything strangeAs you can see it loads 41,42,43,61,62,63 (hex) so no conversion done. Not there at least.Code:movlw low (low (_topline))
movwf R5
clrf (R5) + 1
movlw 041h
clrf PCLATH
call ARRAYWRITE
movlw 042h
clrf PCLATH
call ARRAYWRITE
movlw 043h
clrf PCLATH
call ARRAYWRITE
movlw 061h
clrf PCLATH
call ARRAYWRITE
movlw 062h
clrf PCLATH
call ARRAYWRITE
movlw 063h
clrf PCLATH
call ARRAYWRITE
/Henrik.
How are you checking the output? Is that what's displayed on an LCD? Maybe the issue is with the LCD. If you have a scope with comm protocol, verify the output from the PIC.
I deleted all the code and defines
did everything from blank sheet, and now it works properly....
once again a failure to produce a compliable example that demonstrates the problem
proof again in the pointlessness of snippets
a complete waste of effort
well done .... not
Well, if you're into scrolling thru 500+ lines of code.....
I'm just trying to make things simpler :)
who wants that . 500 lines of chicken scratching's, no way i would even look at itQuote:
Well, if you're into scrolling thru 500+ lines of code.....
I'm just trying to make things simpler
post the simplest compliable program that shows the problem. [if you can 99.99% odds you cannot ]
code snippets generally don't cut it, we need to see the config settings, osc speed var declarations , port settings etc....
[use code tags] please
its not hard
just going through the process of making a provable example will help you confirm that the problem
is elsewhere
you keep trying to claim compiler errors , i have not seen one in core code for at least 10 years
Compiler errors?
try to write or read past available eeprom - no errors will be given :)
I know, this may be called not a bug, but a feature, but even on ancient ZX Spectrum there was an error code "Index out of range" :D
Yes, because - as we've discussed before - your beloved old ZX Spectrum (RIP Sr.Clive) ran a BASIC interpreter so it COULD check such things at runtime.
With PBP there is no interpreter running, it's COMPILED code so there is no way for the compiler to know, before hand, that value n that you just read from an external EEPROM points outside of an array.