On 13/11/2020 13.00, 'Oliver Seitz' via jallib wrote:
This could be the origin of the problem. Here's the bit codes of the
machine instructions which load a literal value to a file select
register:
18f26k22: LFSR 1110 1110 00ff kkkk - 1111 0000 kkkk kkkk
18f27k42: LFSR 1110 1110 00ff kkkk - 1111 00kk kkkk kkkk
18f27q43: LFSR 1110 1110 00ff kkkk - 1111 00kk kkkk kkkk
k22 has only 12 bit deep FSR, while the ones with the larger RAM have
14 bit. The low byte is the same on all chips, but the high bits are
arranged differently. While on k22 bits 11,10,9 and 8 are in the
lowest nibble of the first word, that nibble on the larger chips hold
bits 13,12,11 and 10. Bits 9 and 8 are in locations which were defined
as zero on k22.
This means, if the compiler only generates the k22 form of the
command, banks are skipped. Only banks 0,4,8,12... are addressed.
Unpopulated RAM locations on the k42 start at 0x2000. Divided by four
due to the lost bits that region would be adressed from 0x0800 on,
which is exactly what the test program showed.
I haven't gone into these details, but your analysis sounds plausible.
I'm afraid I cannot help with compiler issues.
Regards, Rob.
--
*Rob H*amerling, Vianen, NL
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/1a4940ae-ade2-0ceb-7fbe-59a90993f287%40gmail.com.
