Memotech Bill wrote: ↑
Thu Sep 16, 2021 10:11 am
RichardRussell wrote: ↑
Wed Sep 15, 2021 9:15 pm
ejolson wrote: ↑
Wed Sep 15, 2021 8:15 pm
I think mcu/pico should disappear.
Even before the Pico version was proposed, a question
had been asked about porting BBC BASIC to Microcontrollers. So there may well be other similar ports and mcu/
should be appropriate to those too, otherwise the name is misleading.
I'm guessing that there must be some
Pico-specific content, so that should go in a Pico-specific directory. If that's not mcu/pico/
it could be console/pico
. Failing that there should at least be pico
in the filename.
Either way what's important is that we don't take a mis-step with the structure of the repository at this stage which might make it difficult to add a version for a different microcontroller in the future.
Not being at all familiar with modern microcontrollers and their special requirements, I'm trusting you and Bill with this.
I have attempted to achieve this:
- I have put the FatFS source files back the way I originally had them.
- I have moved the Pico specific SD Card low level access routines into mcu/pico
- mcu/lfswrap.c is generic. To make this clearer I have renamed a number of routines / variables from pico... to fsw...
- mcu/lfspico.c contains the pico flash access routines. However it is mostly generic, with just a few #ifdef PICO blocks. I therefore renamed it lfsmcu.c. Also renamed lfspico.h to lfsmcu.h.
- I have also created a separate mcu/pico_vga folder for my VGA & USB keyboard code. Mainly because this includes a "tusb_config.h" file, which must not be visible when building USB console mode.
Eric, please will you review and let me know if you have any comments. If you are happy I will attempt to create a pull request for Richard.
One question: Why are the linker script files in console/pico? Would it not be more logical to have them with the remainder of the source files in mcu/pico?
When I made the first reorganisation there was no /mcu/pico directory. That was later added as an include directory to work around a problem with the SDK. Such an include directory is not needed with the alternative workaround involving changes only to the CMakeLists.txt file.
My original intention was all mcu related files should be in /mcu and the Pico ones have pico in their filenames. For example lfswrap.c was supposed to be general for any microcontroller and lfspico.c contain specific code for programming the built-in flash memory on a Pico.
The load map is in console/pico under the assumption that it is build specific and console/picovga will need to use a different load map with a second stack for the second processor.
Anyway, that's the logic behind the original reorganisation. As stated before, my preference is to delete the mcu/pico directory as it was only there to hold the include stub for the first workaround to the printf bug. I prefer having a flatter source tree when there are less than about 50 files. The reasons for this is personal preference based purely on personal productivity. As long as there aren't more subdirectories than source files--like some Java projects--it is not important.
If Bill's changes were made to a post-merge fork from Richard's tree, a pull should be easy. If not, the pull is likely to create all sorts of weird conflicts. Again, Git is not diff but a system for handling metadata of who made what change.
At any rate, I'm happy. Thanks for working on this!