Re: [Flashforth-devel] FlashForth on the PIC18F26K42

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

Hey Jordan.

This is great !
I suspected that it would be a substantial effort, so I did not even 
start.

It would be best if you can merge master into the k42 branch and test 
that some  legacy PIC18 chips work with the code.
After that the k42 branch can be merged to master and pulled to my main 
FF repository.

I can contribute with testing on some legacy PIC18 chips, I have a 
fairly large selection.

Part of merge can be done with ifdefs and part with macros.
I wonder if movff can be macro or can movff be replaced by a M_MOVFF 
macro which generates
movff or movffl instruction based on the selected chip. Using macros 
would make the code more readable than a myriad of ifdefs.

Having a separate source file for the k42 could also be acceptable, 
since the k42 is so different.
Or dividing FF into file(s) with common parts and file(s) with k42 
parts.

BR Mikael

On 2018-09-12 07:51, Jordan Niethe wrote:
> Hi everyone,
> 
> I have been working on getting FlashForth running on the PIC18F26K42
> as part of my final year engineering project.
> I thought people might be interested in my work to that end, which can
> be seen at
> https://github.com/iamjpn/flashforth on the k42 branch.
> 
> The 26K42 has quite a few differences from the other PIC18s.
> * The BSR is now 6 bits rather than 4 bits, and data memory ranges
> from $0000-$3FFF.
> However, for the 26K42, banks 16 - 55 are not implemented and banks 56
> - 63 are SFR.
> This made me decide to keep the same memory mapping as the other
> PIC18s, with the RAM starting at $F000.
> I further split the memory, to keep all the SFRs available:
> $F000-$F7FF in FlashForth = $0000-$07FF in hardware
> $F800-$FFFF in FlashForth = $3800-$3FFF in hardware
> 
> All this requires a lot of bit masking, makes storing more complicated
> and makes half the RAM unavailable.
> It would be a better idea to just RAM at  $C000 on the 26K42, which is
> what I'm now working on.
> 
> The larger memory size also means that movff does not have enough
> reach, movffl needs to be used.
> You need to be using the latest MPASM or movffl will not work.
> ( https://www.microchip.com/forums/FindPost/1064775 )
> 
> * Many SFRs are no longer in the Access Bank.
> A lot more bank selecting needs to be done.
> 
> * No more USART.
> The 26K42 has a new, different UART module, different code needed for
> this.
> 
> * Instruction Memory
> The 26K42 uses a block size of 128 bytes for writing and erasing
> program memory.
> 64 bytes was previously assumed throughout FF.
> 
> * Timers
> Slightly different set up
> 
> * EEPROM
> Begins at address $310000 instead of $F00000
> 
> * Naming
> A few names used in FlashForth conflicted with names used by the
> 26K42, so had to be renamed.
> 
> I have not yet touched multitasking, HW flow control, cpu load, cpu
> idle mode or USB serial emulation, will work on these next.
> I have not used my changes in anger yet, but it seems to be
> functional.
> 
> The changes I have made make FlashForth no longer compatible with the
> other PIC18s. After it is fully working on the 26K42 it would be nice
> to integrate the changes back in.
> I'm a little unsure what is the best way to go about this.
> It would need quite a lot ifdefs if used in a similiar way to how
> currently differences in devices are handled, but I'm not sure what a
> better approach would be.
> 
> I hope this is interesting to people,
> Jordan Niethe.
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael