If Lua is small enough then it would be worth it.
It’s very flexible and its instruction size matches the M0+'s register size.
It’s also quite easy to learn (I learnt it after C# and before C++).
If there’s any doubt that Lua wouldn’t be suitable, then it might be worth giving pawn a go to see if it would make a suitable backup.
Weird…
Best stick to the systems that are designed to be lightweight and embedded into other programs.
Well it’s seems to be working
But I got no clue on memory usage
I’m not sure how to optimize it if I needed to
Could still try the elua implementation but I can’t get that into Arduino ide, so if anyone wants to try that one be my guest
Is there a way to benchmark this on how fast it is or see the memory consumption?
And what are the wire options for pex if we go lua. It’s going to have to send a text stream up I believe but could send bytes or parallel stuff back or any other interface. Pex isn’t wired in with the LCD is it?
I have no idea how to check but I’m sure there’s a way, check the docs.
For speed or size?
It would depend on what’s causing the bottleneck.
No sense trying to optimise before there’s a known issue.
I’m not sure how to test those, might be worth making a separate thread asking about that.
The answer might involve hardware debugging.
Otherwise mbed might have a timer class, or it might be possible to hijack one of the CPU timers.
I don’t think the RTC would be suitable because it’s wall clock time instead of high-speed small scale time spans, but I could be wrong.
The language doesn’t affect the wiring.
Most likely the ESP would have to link to the Pokitto using either USART (serial connection) or SPI.
Text is just a block of bytes in a pre-organised text encoding.
No, it isn’t. You can just get the Pokitto to draw its own LCD and have the ESP send data or draw commands to the Pokitto.
Why would you want to manually drive the LCD from the ESP though?
If you’re going to start going down that route that then you might as well solder buttons,
a screen and an SD card onto the ESP chip and leave out the Pokitto,
(at which point transferring the data isn’t really needed either).
If the hat is supposed to just be a slave for the sake of internet connectivity, then it should stay a slave,
otherwise you just end up trying to mangle loads of different ideas together without a tangible end goal
(a plague known as feature creep).
There is one but I’ve never read it so I say nothing of how useful it would be:
I’m sorry. But maybe your right that the esp32 should be a standalone thing. But I don’t think I can manage that
For now it’s simple. It should connect the pokitto to WiFi and Bluetooth using a lua script to manage that and that same script can be used as a co processing like 3d and other stuff (see pico8 alone in the dark)
I’m just saying, keep the scope small and targeted.
If you start trying to do too much then you end up flitting between the diffferent things and never actually getting any of the things finished.
(I say that from experience.)
Focus on the wifi, bluetooth and programmability first.
Worry about the possibility of trying to get a wifi support chip to act as a GPU later.
(Though I must admit, looking at the ESP’s spec and thinking about it, it does seem a bit weird turning such a powerful thing into a hat. Might be worth looking at other options later on if there are some cheaper chips.)
Either way, there’s not much point trying to move on to doing GPU stuff until it can be scripted.
If it was destined to just be a GPU then there would be other options,
but the main point of it is the wifi, so getting it to a point where it can do wifi stuff should be the first step.
Even if that’s just through sending simple byte-based commands without a scripting language at first,
the rest can follow from there.
If you’ve got it up and running on both ends and you’re at the stage where you can transfer data between the Pokitto and the ESP then it should just be a matter of transferring and loading a compiled script.
I don’t know what stage you’re at though.
Also I don’t have the equipment to test anything so my usefulness is soon going to be somewhat limited for anything other than looking at code and trying to discern software errors.
Oh, and in case you can’t translate the Java to C++ for whatever reason, here’s a list of all the different Lox implementations people have made:
Out of the ones I skimmed, this one is my favourite because it’s C++11 friendly and const-correct:
It would need a bit of tweaking to run on Pokitto though.
Particularly I don’t think std::runtime_error is available on Pokitto because exceptions are disabled.
(That said, a lot of the other C++ variants are using C++11, C++14 and C++17 features… In fact I can’t find one that isn’t using at least one C++11 feature)
i keep looking back at this potentialy amazing use with the esp32 but cant seem to do it.
started looking at mongoose os as perhaps the solution
outside looks like a solid system, it even lets you program it from a browser with javascript or c wich is a bit wierd
it opens up solid wifi, i guess all it realy needs is a decent conection library to the pokitto
So I think WiFi is a main point but not the only thing
My problem with doing a custom thing is that OTA updates or pokitto programing the esp is complex
Esp32 or esp8266 are both powerful and I think can be used as external co-processing Chip