Hi Kiste, Rob,
I had a short look and found this code in the compiler sources:
case PIC_OPCODE_LFSR:
{
unsigned base;
value_t bval;
bval = pic_code_value_get(code);
base = value_base_get(bval)
+ value_const_get(value_baseofs_get(bval))
+ pic_code_ofs_get(code);
pcode_lo = 0xee00 | (pic_code_fsr_n_get(code) << 4) | (base >> 8);
pcode_hi = 0xf000 | (base & 0x00ff);
ct = 2;
}
If I know a reliable way to detect the other PIC types I could change this code
generation part for that specific situation to generate the right LFSR for
those PICs. Not sure if this is all I need to do, I only had a short look.
But what I need to know for which PIC types they changed this LFSR. Is that
always when the data space is >4k or is it with PICs that have 64 banks?
Kind regards,
Rob
________________________________
Van: [email protected] <[email protected]> namens Rob Hamerling
<[email protected]>
Verzonden: vrijdag 13 november 2020 14:18
Aan: [email protected] <[email protected]>
Onderwerp: Re: [jallib] RAM not working on larger chip
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 Hamerling, 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]<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/1a4940ae-ade2-0ceb-7fbe-59a90993f287%40gmail.com<https://groups.google.com/d/msgid/jallib/1a4940ae-ade2-0ceb-7fbe-59a90993f287%40gmail.com?utm_medium=email&utm_source=footer>.
--
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/AM0PR07MB62410D9CB95A613C3657C28DE6E60%40AM0PR07MB6241.eurprd07.prod.outlook.com.
