In my opinion, the more complicated your code becomes the more useful real debugging support is. You can save hours compared to using debug prints etc.
1 Like
I haven’t had time to do any more investigation myself but from what Jonne has said it sounds like getting PlatformIO to work has been a huge pain to get up and running. I don’t quite understand the reasons why the hardware debugging is behind a paywall. Do you need extra hardware to do the debugging on device or should it be possible via USB? Does it use gdb or something else?
At this point I’m wondering if it would be worth just making a simple Makefile to handle compilation, similar to how the Uzebox setup works. Potentially it could target both simulator and actual hardware, plus be suitable for cross platform development on Windows, Mac and Linux. It isn’t as friendly for beginners as something like the Arduino IDE but potentially could work with IDEs like Visual Studio etc.
Thoughts?
As much as I detest cmake and makefiles, I’d really like for there to be other options available for Mac and Linux (despite not using either), so it might be worth considering.
(And frankly Visual Studio is my favourite IDE, even if I preferred the 2010 UI to the modern ones.)
if prefer a makefile on mac/linux since thats alteast one les dependancy (make comes pre isntalled on both platfroms)
whats the exact pipeline we would have to folow for that?
Sorry, haven’t had any time to pursue this any further.
Hopefully at some point, because I’d really prefer a solution like PIO.
Until then it’s impossible for me to make anything for pokitto.
1 Like
Sadly not.
Yup. It means making a platformio.ini.
The makefile should serve as a good base for what settings need to be filled with what though.
It should at least give a clue as to what the compiler settings should be.
Otherwise it’s going to just be a matter of knucking down and fighting the documentation.
On the other hand, aparently Code::Blocks can use custom makefiles to build.
We’re already recommending Code::Blocks for the simulator, so maybe that would be a good stepping stone?
(Also EmBitz is a fork of Code::Blocks, so the UI is quite similar - shouldn’t be a major leap for those who are used to EmBitz.)
That was a fast reply.
I was thinking more about how far you had gotten.
If you had a half-built platformio.ini, that could possibly serve as a starting point.
Can’t get mbed online or EmBitz working?
Or just don’t want to use either?
While I’m thinking of library things.
I cannot deny how useful Arduboy2's justPressed is.
I find myself using Buttons::held in an attempt to simulate it, so a future buttons API would do well to accomodate both the current ‘timed’ functions and something more like justPressed.
Come to think of it, if the buttons are updated via interrupt, what metric/time interval is used for defining the timeHeld (and related functions)?
Is it the number of calls to update or pollButtons?
I’m sure as hell not going to develop anything with a webbrowser and EmBitz only works on windows.
PlatformIO seemed the most logical route for me to use the pokitto-libs with mbed for this target using a cli toolchain, but yeah no time to investigate.
I ran in to lots of dependency/path issues when trying to build the hello-world example. Maybe I can have another shot at it, but it’s probably best to start the effort from scratch (don’t have my files from then).
Same here. Platformio is a pain in the ass to set up
You mean the pokitto-libs are a pain in the ass to use with other toolchains? 
No. If you try to compile just the normal LPC11U68 target, it won’t work out of the box
1 Like
Hmm, indeed I can’t compile the mbed hello world example.
Submitted a bug-report about this to PIO.
Exactly
In any normal IDE (including the mbed online IDE) you can pretty easily solve the mbed compile problem.
But I tried to fix it on the PIO and it was just horrible with its convoluted platform descriptions etc. Not enough documentation was available to get around them.
This is why I’m thinking it might be worth trying to get Code::Blocks using @FManga’s makefile as a first step.
Code::Blocks might not be the most popular IDE, but it’s free, open source and supports GCC.
It’s mac development is a bit behind due to lack of mac developers, but its Linux and Windows branches seem to be fine.
(My only issue with it is that it’s hosted on sourceforge. Ever since the 2013 GIMP incident I’ve been very mistrusting of them.)
Not sure what you mean with ‘normal’, but in this case it seems there is a specific issue with mbed for NXP targets within PIO.
Hope someone more knowledgable about PIO-internals can fix this.
Do note that PIO is complicated because they aim to have as many platforms/frameworks/boards/libraries as they can with a single frontend. Quite ambitious if you ask me.
Technically PlatformIO isn’t really an IDE, it’s a sort of middleman between the IDE and the compiler.
Traditionally an IDE (i.e. a ‘normal’ IDE) either directly manipulates the compiler or uses makefiles.
I suppose in a way PlatformIO is kind of like another modern attempt at a better makefile, with mixed results - great for some platforms, not quite as great for others.
I never claimed it’s an IDE 
I’d call it a ‘unified toolchain’ or something. Anyway, those interested lets continue here: [Solved] Using PlatformIO for compilation
1 Like
I agree. And I put in a pretty serious effort to try to get it working. I still think its one of the priorities to get it fixed.
1 Like
I was addressing what a ‘normal’ IDE is.
I’ve moved all the PlatformIO specific parts.
maybe we should give