-
Notifications
You must be signed in to change notification settings - Fork 5
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.
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...
I think this shouldn't be too difficult but I don't know. I'm particularly interested in the NodeMCU platform.
These are some ideas for how to improve the UziScript language. Some of these could also be useful for later optimizations.
-
Constants. The
constkeyword 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. - 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.
- Struct support. Something similar to the array might work for structs as well.
- Pointers? I'm not sure about this but it could be fun.
- 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?
- HEX literals. This could be useful for specifying bit fields.
- 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.
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.
As suggested by kristiank in issue 37, it would be cool to be able to publish an online version of the IDE:
Maybe it would make sense to host the latest release somewhere online? This way people could very easily get an impression of the environment, see the blocks, see the different panes and options for language etc.
I think having a non-functional editor online just to let users "preview" the environment would probably be easy to implement. I just need to decouple the GUI from the middleware server and host the files using github pages, as I do now for the Physical Bits website.
However, I think it would be really cool to have a fully functional online editor (kind of like the Arduino create). In order to do that we could follow the same route Arduino took with their Arduino create plugin and ask the users to download the middleware as a separate package that the online editor will connect. I think the current "web release" will do just fine if I disable the "open-browser" option. It would be nicer if it was installed as a background service, though.
I would like to be able to program robots without the annoying USB cable. I've tested the HC-06 bluetooth module and it seems to work fine. I only had to change the firmware and middleware to use 9600 baudrate and everything worked. I don't remember why I set the baudrate to 57600 in the first place so I'm worried that there is something I'm not seeing. That's why I will wait a little before releasing this change.
For boards that have wifi capabilities it would be nice to provide a version of the firmware that allows to connect through TCP. The middleware is already capable of connecting to a socket as well as a serial port (I use the socket for the arduino simulator) so I think we would only have to update the firmware.
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.
An instruction that allows to print a message in the output panel when the device is connected. This would be useful for debugging purposes. To avoid increasing the program size too much I think I would probably store the messages in the program source but I wouldn't encode it when sending it to the firmware. Instead I would let the firmware refer to each print message using indices. However, that is a problem if we lose the program source because then the IDE won't know which message to print. Since this is just a debugging feature I think those messages could be ignored, maybe.
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?
This was a very cool idea suggested by sebasgb. We should probably target Unity (and maybe godot?). It would be useful for making alternative controls for videogames. Or maybe cool videogames for robots? I don't know... it would be fun either way.
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:
- ClojureScript and Node.js: This sucks as well because then we replace java with nodejs. Not really better, is it?
- 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...
- 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...
ACAACA
I really hate having to force the users to upload the firmware manually. Now that the Arduino CLI exists I think we should take advantage of it. I haven't looked into it very much but from what I could see, it would allow us to easily detect the available boards and upload the firmware automatically. I have to check the limitations and how to redistribute the tool but IMHO this is the way to go.
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.
ACAACA
ACAACA