Hi Rob,
I'd really like to help... but I would prefer to have a look into the
.pic-files the device files are generated from. I only have MPLAB IDE on my old
little laptop I'm using for pic programming. No .pic-files there. I tried
installing the linux version of the XC compiler, but even though it is titled
"Linux 32-Bit and Linux 64-Bit", it won't install on my 32bit system.
So I dug up a small machine with Windows 10 on it. However, when I double-click
the installer it tells me "This software cannot run on this machine. Please ask
the maufacturer for a compatible version." No more information, I can only
guess that again the problem is, that it is a 32bit system.
I think I'll have to power up my big old intel x64 linux machine... Will take a
while.
In the jallib device files there are entries like "(banks=64)", but e.g. on the
q43 devices only the populated banks are counted. So, for the 18f25q43, which
definitely has 14 bit FSRs, "(banks=14)" would be of no help.
Greets,Kiste
Am Freitag, 13. November 2020, 19:55:56 MEZ hat Rob CJ <[email protected]>
Folgendes geschrieben:
Hi Kiste,
Thanks for the info. I still wonder if it also valid for PICs that have 64
banks (did not check that yet). If so I could update the device files for the
18F series with the pragma numbanks like I did for the PIC14H device files. I
do already have the check in the compiler for this pragma so that would be a
nice solution.
I made a quick hack to the compiler source to see if it works but since I only
have a PIC18F47Q43 I need to get your program running on it. Unfortuntely I ran
into compatibility issues with all serial libraries that do not compile for
this PIC. The easiest thing for me to do was to 'hack' the serial software
library but nothing comes out yet.
So if this issue can be fixed in the compiler, all serial libraries also need
some rework too.
I will keep you posted. Weekend is there ....
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib <[email protected]>
Verzonden: vrijdag 13 november 2020 19:35
Aan: 'Oliver Seitz' via jallib <[email protected]>
Onderwerp: Re: [jallib] RAM not working on larger chip Sorry, it would have
been too easy... But there's something else,
FSR0H_SHAD_FSR0H
seems to be defined only for devices and for all devices with 14 bit wide FSRs.
Greets,Kiste
Am Freitag, 13. November 2020, 19:10:27 MEZ hat 'Oliver Seitz' via jallib
<[email protected]> Folgendes geschrieben:
Hi Rob,
I've found a probably reliable hint in the device files:
var volatile bit*6 FSR0H_FSR0H at FSR0H : 0
or
var volatile bit*4 FSR0H_FSR0H at FSR0H : 0
As far as I have seen, all 18f*-devices have such a definition in the device
file.
It is only 57 of 486 18f*-device files which declare bit*6.
Greets,Kiste
Am Freitag, 13. November 2020, 18:21:52 MEZ hat Rob CJ <[email protected]>
Folgendes geschrieben:
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 kkkk18f27k42: 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
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/1a4940ae-ade2-0ceb-7fbe-59a90993f287%40gmail.com.
--
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
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/AM0PR07MB62410D9CB95A613C3657C28DE6E60%40AM0PR07MB6241.eurprd07.prod.outlook.com.
--
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
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/1636633074.5199862.1605290913916%40mail.yahoo.com.
--
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
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/1877556776.5199977.1605292524536%40mail.yahoo.com.
--
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/AM0PR07MB624135B540E97D9C116B2679E6E60%40AM0PR07MB6241.eurprd07.prod.outlook.com.
--
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/1236086078.5413750.1605340330253%40mail.yahoo.com.
