Re: [Flashforth-devel] FlashForth on the PIC18F26K42
Brought to you by:
oh2aun
From: Jordan N. <jni...@gm...> - 2018-10-09 05:25:37
|
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 |