Re: [Flashforth-devel] changes to FF for PIC18F26K42

[Mikael N. <mik...@fl...>]

Interesting chip.

I did a quick test on a 14k50 and moved it, works out of the box.

IRQ_STACK udata
irq_s0   res PARAMETER_STACK_SIZE_IRQ   ; Multiple of h'10'. Interrupt 
parameter stack.
flash_buf res 0x40

hex  ok<$,ram>
f070 40 dump
f070 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f080 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f090 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0a0 :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
ok<$,ram>
: tt 1  ;  ok<$,ram>
f070 40 dump
f070 :e4 21 82 74 74 ff 01 0e ec 6e ec 6a 12 00 ff ff .!.tt....n.j....
f080 :ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f090 :ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0a0 :ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 
ok<$,ram>
tt . 1  ok<$,ram>
see tt
2306 0e01 movlw 01
2308 6eec movwf (+sp) a
230a 6aec clrf (+sp) a
230c 0012 return
  ok<$,ram>


In addition all the hardcoded constants (0xC0 0x3F) should be 
parameterized with symbolic constants.
These can be found in the flash write code and in I@ I! IC@ IC!.

BTW,
There is a ff51 branch in git which you could base your changes on.
It will soon be the latest master code.
It uses FSR2 as return stack pointer for R> >R R@ and for saving the HW 
stack to the user area in PAUSE.
see >r
0f3e cfed movff (sp-) (+rp)
0f42 cfed movff (sp-) (+rp)
0f46 0012 return

BR Mike

On 2017-12-29 04:41, Peter Jacobs wrote:
> Mike,
> 
>    I have been looking into the changes needed for running FF on a
> PIC18F26K42 microcontroller.  It seems that most of the changes will
> be just to a few of the configuration parameters (like changing the
> EEPROM and RAM prefixes to bc00h and c000h, respectively, to allow the
> 14-bit data space address) but I've come to a halt when I see that the
> K42 family has 128 bytes of flash write latches per row.  The current
> flash_buf is hard-coded to 64 bytes and lives in access memory, as I
> understand the code. Could the FLASH_BUF section be moved to udata,
> after the other access variable reservations and just before the
> IRQ_STACK section?  Are there implications for doing so?
> 
> Regards,
> 
> Peter J.
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael