Hi Rob,
serial_hw_int_cts uses a lot of RAM for buffers, so it is likely that the
large_array variables are placed differently depending on which serial lib is
used.
In the asm file, you can see where the variables are placed:
v__large_array_1_byte_1h EQU 0x0100 ;
_large_array_1_byte_1hv__large_array_1_byte_2h EQU 0x0200 ;
_large_array_1_byte_2hv__large_array_1_byte_3h EQU 0x0300 ;
_large_array_1_byte_3hv__large_array_1_byte_4h EQU 0x0400 ;
_large_array_1_byte_4hv__large_array_1_byte_5h EQU 0x0500 ;
_large_array_1_byte_5h
I've seen that variables with starting address from 0x0800 on will not work.
The obvious difference in your files is at the end of array_4, I presume that
last array has different locations depending on which serial lib you used.
Greets,Kiste
(En nog extra groetjes naar de ander Rob. Heb ik vergeten de laatste keer ;-) )
Am Donnerstag, 12. November 2020, 21:35:59 MEZ hat Rob CJ
<[email protected]> Folgendes geschrieben:
Hi Kiste,
I am playing with your program but do not have a 18f27k42 but I do have a
18f26k42 which has 4k of memory.
While experimenting I found something strange. The results are different when I
use serial_hardware instead of serial_hw_int_cts. The results are still wrong
but completely different, see attached file where the two results are listed.
Not sure yet what is happening here. I added some explicit typecasting in
large_array_4 but it did not make a difference.
To be continued.
Kind regards,
Rob
Van: 'Oliver Seitz' via jallib <[email protected]>
Verzonden: donderdag 12 november 2020 21:14
Aan: [email protected] <[email protected]>
Onderwerp: Re: [jallib] RAM not working on larger chip Hi, the other Rob ;-)
Thanks, looks very interesting. My suspicion so far is that, from a certain
address on, the variables are falsely mapped to unimplemented and SFR areas.
This is probable for both the k42 and the q43 types, as their SFR pattern is
different: q43 has all SFRs densely packed in five banks with few "reserved"
spaces in between. k42 has the SFRs scattered over eight banks with lots of
"unimplemented, reads as zero" spaces in between. Those patterns resemble parts
of the patterns of the wrong variable readings.
Sorry for not making the test program portable, I had to suffer myself: The
18f26k22, which was the only other controller I had which would fit on the
board at all, has no pps and no open-drain function. After finally choosing the
keyboard over the soldering iron, I made a copy of serial_software.jal and
modified it to mimic open-drain behaviour.
Am Donnerstag, 12. November 2020, 16:38:45 MEZ hat Rob Hamerling
<[email protected]> Folgendes geschrieben:
Hi Kiste,
On 12/11/2020 12.57, 'Oliver Seitz' via jallib wrote:
Hi Rob!
It does make a difference: On a pic18f26k22, all the RAM seems to be working
properly. To my knowledge, the 18f27k42 was the first 8-bit PIC controller with
more than 4k of RAM. Yet to test would be 18f[2|4|5]7q43 with 8k and
18f[2|4|5]7q84 with 13kb of RAM. Both again with a different layout, Access
bank on these is comprised of parts of bank 5 and 4 of 64 banks in total.
I have a 18F27Q43 here and tried to use your program. That didn't go straight
forward: fusedef 'debug' was refused, TX and RX on my test board were at
different pins, and the serial lib gave errors (PIR3 and PIE3 had to be changed
to PIR4 and PIE4). After the required (provisional) changed the program finally
compiled fine! The output is quite different from yours, see attachment, but
also not as expected I think! I doubt if this helps to find the cause of the
problem, but at least it proves that it is not unique to the 18f27k42.
Regards, the other 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/0c59a330-f251-c28e-6bd9-eec1e9a759ea%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/1955662830.4818762.1605212057510%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/AM0PR07MB62412E4C90417CF19C32BC81E6E70%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/1904697747.4845460.1605214657141%40mail.yahoo.com.