-
Notifications
You must be signed in to change notification settings - Fork 5
Ideas
This page is for 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? UPDATE: Maybe I could use the EEPROM to store the strings so that they don't waste RAM. Then the user program can refer to each string by index. I won't be able to program a full string manipulation library but it should work fine for simple use cases such as showing messages in the LCD display or sending data through the serial port. I'll have to be careful when storing these strings to avoid wasting the EEPROM and thus shortening its lifetime, but I think I could write them at the end of the last program and only change the bytes when they change, assuming the user is not changing the strings all the time it shouldn't make a big difference (I think). I'll have to check the EEPROM code to verify. I'm also thinking with this implementation a simple ASCIIZ would be good enough (probably with some escaping character to avoid messing with the EEPROM wear leveling stuff).
- 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
So right now both the compiler and VM are very naive.
The compiler, for instance, doesn't know how to emit the TURN_ON/TURN_OFF instructions that include both the opcode and pin in one byte. Instead, when compiling something like turnOn(D13) it will emit something like READ_GLOBAL, and then PRIM_TURN_ON (which, if I recall correctly, could occupy between 2 and 3 bytes). This is just one example, I'm sure there are other instructions that are currently ignored by the compiler and they would produce much smaller encoded programs.
Another huge problem with the compiler is how it handles imported libraries. Right now, it simply parses the library code, it applies the corresponding alias to all its visible members (scripts and vars) and then it merges this AST with the original. If there are nested libraries, it will apply this process recursively. So this strategy works fine because we have the dead-code remover that will get rid of the unused scripts and vars but it's really wasteful if we import the same library twice (for instance, if we want to have two DC motors in our program). Since the import process doesn't really care it will merge the same code twice with different aliases, so we'll end up with duplicated code in our program. This is not as easy to fix as it seems, though, because the import can also statically modify the default value of any variable as well as the initial state of any task. So, even though the original code would be the same, the imported code could be different. We'll need to take that into account.
The VM, on the other hand, is currently wasting a lot of memory whenever a coroutine needs to grow. The VM currently allocates space for the new coroutine size, it copies the old data to the new space, and then never frees the old space. Due to the way the allocator is implemented this is not easily fixable. I'll need to change the coroutine allocation strategy to use something like a linked list of memory blocks (I know this strategy has a name but I don't remember right now).
Another thing that bothers me is the memory footprint of each script. I think there is a lot of room for improvement there as well.
MakeCode has this nice "Advanced" toolbox category that allows you to expand the available blocks by including some extra blocks. I think we could follow their lead and use this same concept to add more blocks without cluttering the toolbox. I think the mutex library could be a nice addition. Also, it would be awesome if we could extend the toolbox with some blocks libraries that users can choose to include (or even develop themselves).
The Snap! blocks programming language has the wonderful concept of "build your own blocks" which resembles a sort of lambda calculi for blocks.
Something like Google Docs, where multiple users can edit documents at the same time.
Building a community around the project is very important. There is a discord server for the Godot Engine that could be used as inspiration for creating our own.