Re: [Flashforth-devel] FlashForth on the PIC18F26K42

[Jordan N. <jni...@gm...>]

Hi Mikael,
I've been working to get my changes integrated back in, and I've made
a tentative pull request to get some feedback.
I used your idea of the MOVFF macro, and ifdeffed the parts that where
different for the k42.
Do you think it has made it too unreadable?
In quite a few cases, it is just the register names + a banksel that
seperates the k42 from the others.
Perhaps having a set of defines so the k42 used the same name would be clearer?

It builds for the non-k42 chips, but I still need to test that it runs.
I've never made a pull request before, so I apologise in advance if I
have something there.
Looking foward to hearing your thoughts,
Thanks, Jordan.
On Wed, Sep 12, 2018 at 6:25 PM Mikael Nordman
<mik...@fl...> wrote:
>
> 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
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel