Have look at how I handle buttons in my games, I think it’s much better and can detect newpress, held and released.
3 Likes
I do like the ability to detect when a button has been held for a number of frames, but I must admit I think the Pokitto could use an equivalent of Arduboy’s justPressed and justReleased.
Edge triggering feels more natural.
2 Likes
You’ve just reminded me.
A number of the Buttons functions return uint8_t when bool would make more sense.
uint8_t makes sense for the ones that return the amount of time a button has been held for, but bool makes more sense for the pressed/released variants.
In fact it might be best to divide the buttons API into a simple version that only does pressed, released, justPressed and justReleased (i.e. edge triggered variants) that are all bool oriented, and the more complicated version that counts the number of frames a button is held for and can do more advanced precision timing.
Either way I think we also need to have an enum class for the button types instead of using uint8_t. e.g.
enum class Button
{
Left = 0, Up = 1, Right = 2, Down = 3, A = 4, B = 5, C = 6,
};
constexpr const std::size_t ButtonCount = 7;
Then the current Buttons::pressed(BTN_UP) becomes Buttons::pressed(Button::Up) and Buttons::pressed(10) becomes illegal.
Would the PokittoLib V2 have to stay using C++03 to be compatible with mbed online?
im going to assume so since we still have no way to compile on all platforms
I thought that would be the case.
That means desiging an improved API is going to be 100 times harder.
no constexpr,
no explicit conversion operators,
no enum class,
no nullptr,
no automatic type deduction,
no delegating constructors,
no range based for loop,
no template aliases,
no varaidic templates,
no explicit defaulted and deleteed constructors,
no long long int,
no static_assert,
and that annoying double right angle bracket issue.
1 Like
Does it have to be the same way on all platforms? Which are the problematic ones?
mac side has no working toolchain so far and raspberry pi. im not sure how desktop linux is going
we where trying to go platformio to unify but it seems there some limitations for debuging and still a total pain to get working
one of the problems is theres to many dependancies for some versions of the toolchain, which end up being points of failure. also im not sure but the mbed cli is still using the c++03
my hope is to just have a standalone command line program like a gcc, then we can just deal with a makefile on everything aside from windows
I got linux desktop working like this: I exported a project from the mbed ide, got arm-none-eabi-g++ (I think it’s in ubuntu’s apt) removed a few wrappers from the makefile and added the checksum. Now I just run make.
1 Like
You should post that makefile.
If we could get that running with Code::Blocks or Visual Studio then we could have an offline IDE that everyone can use.
(And then I can try to design some bits to be included in the new API without having to worry about avoiding all the useful C++11 features.)
1 Like
Here it is.
Edit: it might also be good to look into this: https://community.nxp.com/thread/388993
4 Likes
It will be really useful to implement the methods to retrieve how much RAM and CPU usage for Pokitto.
Now there are only some empty placeholder derived from GB
static uint8_t getCpuLoad();
static uint16_t getFreeRam();
Don’t know if hardware debugger can retrieve this kind of information too?
Not sure where to put this, but I got the linker script to calculate the checksum so it’s not necessary to run an extra step with external tools during the build.
The following files are in PokittoLib/mbed-pokitto/targets/cmsis/TARGET-NXP/TARGET_LPC11U6X/TOOLCHAIN_GCC_ARM/TARGET_LPC11U68 which is what’s used when you export for Make-GCC-ARM.
LPC11U68.ld - add this near the end, before the last }
PROVIDE(__valid_user_code_checksum = 0 - (
_vStackTop +
(ResetISR + 1) + // The reset handler
(NMI_Handler + 1) + // The NMI handler
(HardFault_Handler + 1) // The hard fault handler
) );
Now just declare __valid_user_code_checksum and add it to the table in startup_LPC11U68.cpp:
extern void __valid_user_code_checksum(void); // pretend it's a function
void (* const g_pfnVectors[])(void) = {
// Core Level - CM0
&_vStackTop, // The initial stack pointer
ResetISR, // The reset handler
NMI_Handler, // The NMI handler
HardFault_Handler, // The hard fault handler
0, // Reserved
0, // Reserved
0, // Reserved
__valid_user_code_checksum, // <-- good stuff
0, // Reserved
0, // Reserved
0, // Reserved
SVC_Handler, // SVCall handler
Before you can build, remember to patch the Makefile. Simply replace LD_FLAGS := ... with:
LD_FLAGS :=-Wl,--gc-sections -Wl,--wrap,main -Wl,--wrap,_memalign_r -Wl,-n --specs=nano.specs -mcpu=cortex-m0plus -mthumb
To build, get the toolchain for your OS (Windows/Linux/MacOS) here.
If you’re on Ubuntu, don’t use the old ARM GCC in APT. Extract the gz2 file somewhere, put softlinks in your path to the files in the bin folder (eg, ln extracted/bin/arm-none-eabi-gcc /usr/bin/arm-none-eabi-gcc -s) and you’re set.
Now just run make.
2 Likes
To flash a Pokitto from Linux, install mtools (sudo apt-get install mtools) and do this:
sudo mcopy -o -i /dev/sdc BUILD/file.bin ::/firmware.bin
(replace sdc and file.bin accordingly)
No need to mount/unmount the CRP DISABLD drive.
1 Like
Semi-related (mods - if this should be split into a different thread then please do so).
I am coming to the opinion that we should start putting some tools together to work along-side pokittolib/pokittolib2. Yes I know we have img2pok and @Jonne has his music tracker and there are probably a couple of tools that I don’t know about also. But I was thinking more specifically for people coding games, or other apps that might require a similar approach to graphics.
Also I think that were possible, these tool should be platform independent. I would expect img2pok could easily be re-written in javascript and run through a browser window, similarly a tile/map editor could be created to work the same way.
Does anyone else have any thoughts on this idea?
I think rather than making a tool, what should be done first is to document the graphics/audio formats.
If the formats are properly documented then anyone can go off and write their own tool,
so we end up with lots of different tools for different jobs instead of just the one tool that may not suit everyone’s needs.
(Personally I’d prefer offline tools to online tools. Web browsers chew up enough memory as it is and sometimes internet isn’t available.)
Doesn’t need to be online, I was just thinking that browser-based would be completely platform independent and nobody would need special tools for creating the software, just notepad.
As for graphics formats, they seem to be constantly evolving, especially when you look at how many screen modes there are.
Perhaps.
It would have to be tested on most of the major browsers though,
so it still takes the effort of multiple testing.
All the more reason to document first and create tools later.
If the documentation is kept up to date, tool authors can update at leisure.
(Well designed tools will probably have a plugin system to accomodate new formats.)
I made a start on a very early experimental version of what the 2.0 lib could look like under the assumption that we’ll be able to get some other IDEs that are capable of using C++11:
1 Like
Is there any reason why we don’t simply deprecate interrupt-based button handling? All games do polling in the end anyway (if( button pressed ) ...) and reading from GPIO takes up just as many cycles as reading a variable in RAM.
How about inverting the architecture: reduce the Core into a minimal HAL+Loader, with no public API (games wouldn’t even know it exists). Interface libraries (Mode*.h, Arduboy2.h, Gamebuino.h) would build on that to provide the wanted API without having to worry about simulator/hardware differences and we wouldn’t depend on defines so much. The core could be in C/C++98 and the libraries could provide C++11 if they want to, so mbed would still work to some degree. This would also make it simpler to port games from other systems (simple Arduboy games could just #include "Arduboy2.h" and work, provided the ino files are valid C++).
1 Like