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.

Reply via email to