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"

[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.