Arraywrite converts all letters to uppercase?

[CuriousOne]

Hello.


topline var byte [6]
arraywrite topline, ["ABCabc"]
FOR X=0 TO 6
LCDOUT $FE, $01, DEC topline[x]
pause 1000
next


Outputs same codes for abc as for ABC. Seems like characters are converted to uppercase?

Any ways to fix this?

[HenrikOlsson]

What device are you running this on?

Here it works fine (18F57Q43)

Start:
HSEROUT["Start", 10,13]

arraywrite topline, ["ABCabc"]
FOR X=0 TO 6
HSEROUT [DEC topline[x],10,13]
next
Outputs:

Start
65
66
67
97
98
99
23
With the 23 at the end being because you're reading past the last character written to the array.

[CuriousOne]

Pic16f886.

[HenrikOlsson]

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 strange

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
As you can see it loads 41,42,43,61,62,63 (hex) so no conversion done. Not there at least.

/Henrik.

[mpgmike]

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.

[CuriousOne]

I deleted all the code and defines
did everything from blank sheet, and now it works properly....

[richard]

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

[CuriousOne]

Well, if you're into scrolling thru 500+ lines of code.....
I'm just trying to make things simpler :)

[richard]

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 it

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

[CuriousOne]

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

[HenrikOlsson]

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.