Now that the PocketBeagle 2 is available with the amazing AM62X SoC, I wonder if there are any plans for a board support package that allows bare metal programming (similar to the abadoned StarterWare)?
However, this package currently supports only TIs own AM62X-board. Is it planned to have any definitions/configurations for the PocketBeagle 2 to be used with this SDK and the CodeComposer Studio?
That is not really what is needed, a BSP that allows each core to run independently. An SDK like the Pi Pico that allows true parallel programs on both of its cores. Yet, still have symmetric multiprocessing capabilities.
Hmm, I have never used Pi pico sdk, so not really sure how it would be better than going the Zephyr route, but I can try getting Ti SDK to run if I get time. However, no commitments for now since Zephyr will probably be higher priority.
You can run both cores independently. One use case is VFP (variable frequency pulse train) that can hold 50% duty cycle without deadband issues(truncated pulses in this case). Both cores simultaneously running their own frequency profiles.
Not sure what the difference is between a RT linux kernel and zephyr, so why continue walking down the same path. With that said about zephyr, that board is now in a state of zero differential value while you are playing in crowded field with others that are doing very well.
You can run both cores independently. One use case is VFP (variable frequency pulse train) that can hold 50% duty cycle without deadband issues(truncated pulses in this case). Both cores simultaneously running their own frequency profiles.
I see. That does sound interesting. It would have been nice if there was some open source solution for this. That way we could push the support upstream rather than keep chasing Ti SDK downstream. Hopefully it is trivial enough to get Ti SDK run on pb2.
Not sure what the difference is between a RT linux kernel and zephyr, so why continue walking down the same path. With that said about zephyr, that board is now in a state of zero differential value while you are playing in crowded field with others that are doing very well.
RT linux is soft RT from what I understand whereas Zephyr is hard RT. Also, the hardware requirements of Zephyr and Linux are too different to really compare. Zephyr can run on like 4 kb of ram vs linux where I am pretty sure you at least need a few MBs.
Also, micropython on the pico is very user friendly. Just load the uf2 file and connect with the target on usb. In the spirit of this userbase and how deep python is entrenched it might be a better fit for that board. I did some stuff in it and it is impressive, main point is, simple, simple to load and code. I don’t see why that would not work on this board.
MicroPython has a Zephyr port. So if the board supports Zephyr, running MicroPython on it is pretty simple. That is how we have upstream MicroPython support on BeagleConnect Freedom.
This is not really “chasing” the TI SDK. The point with that bare-metal stuff is, that there no code/APIs/whatever needs to be provided and maintained.#
What is required are
the register definitions (which are already there in the SDK and which don’t change)
a configuration for the specific board (peripherals, timing settings for peripherals); once done, they also do not change any more
nice to have: a few examples how to access specific parts of the hardware (but this is also on a very simple level as this is only for demonstration purposes - and TI already has some in their SDK, so only some PocketBeagle 2 specifics would be needed).
I’m aware of a couple of different bare metal AM62 projects, but neither are quite ready for significant public use.
There are some headaches with TI’s clocking control scheme and security, so it isn’t completely trivial. I’m aware of at least one project that has managed to move this stuff from the R5 to the A53 cores. Unclear if this can run fine on the HS-FS parts.
For now, the Zephyr stuff for the A53s is probably the easiest starting point–and it is pretty good. I’ve been working on things to try to reduce the learning curve and do make things like snagboot run trivially. Still a while before I have it packaged clean for use with something like west flash.
So, for my own junk, I’m somewhat oddly using the Crystal programming language to implement a bare metal programming environment.