I’m beginning to get the impression that you don’t actually know what your end goal is.
You can’t have all the things, so you need to prioritise.
yes sorry, this is an evolving idea
right now the rpg is off the table, just the esp32
i like the idea of a novice/intermediate visual language though i think that might just spit out the lower level language, i see that more of a interface to make it usable on pokitto
Truthfully I’m struggling to imagine someone who couldn’t manage a text-based programming language managing to do complex stuff with the ESP.
If the UI was closer to the old fashioned BASIC computers that plugged into a CRT via the UHF port then it might work out alright.
Instead of treating keywords as a collection of characters, the old BASIC computers treated keywords as single characters to save space and reduce input time.
Though to be honest I think any kind of UI on the Pokitto would be difficult to program with.
So yet another question, is this still intended to be like the original idea of being able to upload bytecode-based programs to the ESP to be able to control it in a way that’s usuable for games?
ok so lets break it down in 2 parts
esp32 bytcode language, or something like it (and maybe a bad idea) is to use it as a serial terminal
like basic/forth/lua (i think its called a repl) and a pokitto programs send text comands up, wich it could grab from a file off the sd card.
it would alow simple comands "connectWifi()" to runing programs. and it would send data back as a string that would be parsed on pokitto
second part and just an idea is to have programing on the pokitto wich would be a block based representation of the program and an interface to visualize it and modify it since we dont have a keyboard, having a gui based thing (like you have a menu of functions and conditions)
That sounds much more like a proper goal.
I’m not entirely sure about sending strings back and forth.
It would be good to try to keep the communication compact.
I still think the UI is probably going to be a bit difficult.
The best approach I can think of is to have commands stored either in categories or alphabetically, have the categories navigated with right and left and cycle through the commands using up and down.
Read Evaluate Print Loop
Depending on how things turn out, it might be better to send the bytecode rather than text commands
ok so how to send anything back and forth?
would you still consider sending text commands up to esp32?
It would depend on which language was being used, but ideally something that’s at least partially binary.
No sense sending the string “255” if you can send a single byte.
I’m looking at existing projects one that popped up is nodemcu
I’m not able to edit that project but looking at Arduino uno to esp commination it’s sending serial strings back and forth
Only language I have is the build in basic and forth
Both aren’t the best 
Basic and Forth are good languages.
(Forth actually is an RPN language.)
When you say you’re not able to edit it, do you mean the licence forbids editing the code?
If so then maybe Pawn would be a better option.
It’s got an Apache 2.0 licence so you’d have to document all changes, but it’s very close to C so for most people who do Pokitto stuff it would be very familiar.
An attempt to recreate a sample from the language guide:
main()
{
print "Input two values\n"
new a = getvalue()
new b = getvalue()
while (a != b)
if (a > b)
a = a - b
else
b = b - a
printf "The greatest common divisor is %d\n", a
}
They’ve also got a very in depth “implementer’s guide”.
I did something silly
Including regular lua 5.3.4 disabling some system file
And we’ll it compiles and runs … I think
Update: got lua working kinda
Should I still look into pawn?
Problem with nodemcu is that it’s a rtos using part of the flash as a virtual drive and other high end wierdness I can’t work with. Also I cant get any of the esp32 toolchain to work apart from the Arduino one
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?
Direct access would be less latency and could render on esp instead of giving draw commands to pokitto
Any examples on pex uart stuff. Chip to chip isn’t something I’ve done before. Only displays over spi
That seems a bit backwards to me.
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.)
Wel I have a esp8266 as well to test on but jonne was interested in the esp32 since it’s so much performance for very cheap price
Still even the esp8266 (cheapest WiFi we can buy) can still be used as a co prosesor
I can try running lua on that one just to see
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.