Thread: [Flashforth-devel] changes to FF for PIC18F26K42
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Peter J. <pe...@me...> - 2017-12-29 02:55:56
|
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. |
|
From: Mikael N. <mik...@fl...> - 2017-12-29 07:33:28
|
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 |
|
From: Peter J. <pe...@me...> - 2017-12-29 12:47:52
|
On 29/12/17 17:33, Mikael Nordman wrote: > BTW, > There is a ff51 branch in git which you could base your changes on. > It will soon be the latest master code. Thanks for the hints Mike. I will try the adjusting the ff51 branch for the new PIC18F26K42 chip and then learn how to package the changes with git. (I use Mercurial, mostly.) This evening, I have tried the ff51 branch on the older PIC18F26K22 chip. It looks good. It emits a "S FlashForth 5 PIC18F26K22 20.12.2017" banner when the interpreter restarts so, for a while, that did have me wondering if I had the correct branch checked out. I am reasonably sure that I did, although I am not yet confident with my use of git. Cheers, Peter J. |
|
From: Mikael N. <mik...@fl...> - 2017-12-29 08:00:45
|
Here's one gotcha.
The division code relies on FSR1H beeing 4 bits.
clrf DCNT, A ; count to 16; 19
UMSLASHMOD1:
change to
movlw d'16'
movwf DCNT
UMSLASHMOD1:
BR Mike
|
|
From: Mikael N. <mik...@fl...> - 2017-12-29 08:37:21
|
The flash and eeprom control registers have new names, NVMxxx instead of EExxx. Silly change. Maybe they are incompatible. M. |
|
From: Peter J. <pe...@me...> - 2017-12-30 06:01:39
|
Mike, Although the eeprom reading and writing for the K42 looks to be compatible to that for the K22, right down to the bits in the control registers, there are a number of other changes to bit locations (e.g. other registers for peripheral interrupt bits). I think that I'll take a bit of time to learn about the K42 family without the benefit of FF for the moment. To try out FF5.1, I'll stay with the K22 family. For other hardware projects, I've been happily using FF5.0 on some PIC24FV32KX30x micros. It appears that your new ff51 branch touches only pic18 code so, for PIC24 work, I guess that I should continue with the master branch. Cheers, Peter J. On 29/12/17 18:37, Mikael Nordman wrote: > The flash and eeprom control registers have new names, NVMxxx instead > of EExxx. > > Silly change. Maybe they are incompatible. > > M. > > ------------------------------------------------------------------------------ > > 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 > |
|
From: Mikael N. <mik...@fl...> - 2018-01-01 22:33:04
|
Hi Peter and all, The ff51 branch was merged to master today. The biggest change is the way the return stack is managed. FSR2 is used as the return stack save pointer in task switching and for R> >R R@ R> does not store into the HW return stack, but into the user area reserved for the return stack buffer. So R> does not work for modifying the return address anymore. It can only be used for temporary data storage. Another change is that PAUSE skips the task switch if there are no background tasks to be run. Therefore the newest versions of task.txt and doloop.txt must be used. A more complete table driven SEE is included. BR Mike On 2017-12-30 08:01, Peter Jacobs wrote: > Mike, > > For other hardware projects, I've been happily using FF5.0 on some > PIC24FV32KX30x micros. It appears that your new ff51 branch touches > only pic18 code so, for PIC24 work, I guess that I should continue > with the master branch. > Cheers, > Peter J. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X