Ideas

This page is for long-running ideas. Feel free to add whatever you think could be interesting. Maybe features you would like to see implemented, fun projects that could be built using Physical Bits, cool experiments, I don't know...

Also, if you're interested in contributing some code to the project this would be a good place to look for inspiration.

---

Extensible VM

This would allow users to add support for any additional hardware that I don't have by extending the firmware. I'm thinking something along the lines of Firmata, where you can either use a general purpose sketch or use it as a library. I'm not sure how to implement this, though, or which extensions points should be added. At the very least, I think the users should be able to define their own primitives. It would require some language support so I would have to change the UziScript compiler. Some of that support is already there in the form of the prim keyword, but I have a feeling that it won't be enough...

Support other HW (apart from Arduino)

I think this shouldn't be too difficult but I don't know. I'm particularly interested in the NodeMCU platform.

Language improvements

These are some ideas for how to improve the UziScript language. Some of these could also be useful for later optimizations.

1. Constants. The const keyword could be used to define constant values. These values could be inlined by the compiler in the appropriate places and that could probably save some memory.
2. Array support. I'm thinking static arrays shouldn't be too hard to add. Maybe they could be implemented as syntactic sugar on top of regular variables. I don't know.
3. Struct support. Something similar to the array might work for structs as well.
4. Pointers? I'm not sure about this but it could be fun.
5. Strings. I'm worried about the impact of strings in the memory usage. Maybe I could just add a subset of the ASCII table? Or maybe use some sort of compression?
6. HEX literals. This could be useful for specifying bit fields.
7. Private variables? Some variables could be marked as private so that they don't appear in the inspector panel. Although maybe this is useless and imported vars should be private by default.

More electronic components

It would be nice to extend the VM and language with support for more electronic components. I'm thinking:

• LCD displays
• Matrix LED 8x8
• DHT11 temperature and humidity sensor
• MPU6050 accelerometer and gyroscope
• SD card module
• Stepper motors
• Rotary/Optical Encoders

This would be much easier if the VM was extensible, as mentioned above.

Online editor

ACAACA suggested by kristiank

Wireless programming

ACAACA Bluetooth, Wifi?

Serial instructions

ACAACA expose the serial to the user so that it can communicate with other devices. When using the main serial port it must detect connection to the middleware, in which case the data should be tunneled (?) inside the middleware protocol.

Print instruction (for debugging purposes)

ACAACA An instruction that allows to print a message in the output panel when the device is connected.

Monitoring dashboard

ACAACA similar to thinger.io. Multiple graphs and widgets available, some kind of workspace for the user to place the controls. Maybe we could use the minimorphic library?

Game engine plugin

ACAACA very cool idea suggested by sebasgb. Unity, maybe godot? It would be useful for making alternative controls for videogames. Or maybe cool videogames for robots? I don't know... Fun either way.

The Java issue

ACAACA I don't like to depend on Java. I mean, we moved to Clojure partly because of Java but it doesn't mean I have to like it. I would like to avoid relying on the users having to install java on their own. I see several options:

1. ClojureScript and Node.js: This sucks as well because then we replace java with nodejs. Not really better, is it?
2. GraalVM Native Image: This seems to be the best solution, we would simply compile the middleware to a native executable. However, I haven't investigated too much about it and I don't know the limitations or how much work it could be...
3. Redistribute the JVM: This seems to be the easiest option. It doesn't get rid of java but at least we bundle the JVM with our software and avoid requiring the users to download and install Java by themselves. I didn't like this idea very much because OpenJDK is a little big (~300Mb) but I recently learned that you can make your own runtime including only the modules that you need using this tool called jlink. It's really easy to use. I was able to get the JVM down to ~40Mb. Really nice. I haven't tested it enough, though, so I will probably wait a bit before going all in on this solution...

Hardware interrupts/timers

ACAACA

Arduino CLI

ACAACA Board detection and automatic firmware upload

Mobile app

ACAACA I'm not sure about programming from your cellphone, it seems the screen would be too small for the GUI. But maybe it could work well enough in a tablet. What would be interesting, though, is to be able to control the devices from a cellphone/tablet. Maybe the dashboard I mentioned above could be made into a mobile app.

Simulator

ACAACA

Optimizations

ACAACA