Honestly, the one thing that could get me to use µLisp more would be a more
interactive REPL.
I agree that this is needed, and I’d welcome suggestions.
I tend to develop Lisp programs by having a text editor window open on the same computer. I compose the functions in the text editor, and then copy and paste them into the Arduino IDE’s Serial Monitor, but it would work for the terminal too.
Yes, the Arduino IDE runs just fine on Linux. I was asking for the uLisp interpreter to run on Linux, not the microcontrollers.
I think the meaning is to run uLisp itself within Linux. I’ve been thinking about looking to see if I can port the ARM version to run on Raspberry Pi. It should be doable, as there are some fairly Arduino-like libraries for using the GPIO features on the Pi.
I think that functionality would blow up the ATmega328, but the main question would be which terminal to emulate or respond to. Ecma48 control codes should be most of what is needed, but I think Windows doesn’t really do those until with the new terminal program that isn’t installed by default.
I think what’s needed is a more general solution - a better way of interacting with uLisp running on a microcontroller when developing applications.
Perhaps I’ll create a new thread to discuss the options.
One feature I think might be worth having, especially as the various versions pick up functionality that isn’t entirely shared, is *features*.
Output to strings strikes me as interesting.
And I, too, vote for “version on Linux”! To produce there a standalone interpreter!
Also — version for iOS! There is NONE, presently. All their “Lisps” are Schemes.
Speaking of which, I also vote for “version on CP/M” and perhaps even “version for MS-DOS”! 😁 Seriously, CP/M is POOR in that regard. The best thing they have is Mulisp, and it is non-standard. More standard is XLISP, but it’s a RAM hog.
I KNOW “there are more capable variants on Linux” and I don’t care. I want to be sure, exactly what I develop will run also on the microcontroller.
Hi David,
Good to hear from you again , hope your doing well.
I would be glad with following (in order of importance to me, being the first most important and going to less).
1- Format
2- Arrays
3- Outputting to a string
4- Interrupt would be nice to have (ARM)
So I have chosen the easiest things almost :-)
Kind regards,
Ronny
Oh David ,
And I totally agree with some members here , a backspace in the REPL would be very nice , in case you make a mistake in typing.
Regards ,
Ronny
Regarding the “bsckspace in the REPL”-topic, David suggested in the past, when we talked about editors, a buffer. But the idea to have a compile-time option is interesting indeed. It does not need even to “go far”, “ability to correct the last ten characters” or something would already be a huge improvement.
I think this is a good idea, but implementing it presents some problems.
There aren’t yet any built-in variables in uLisp, or keywords, and if *features* was a list the user could add to, like in Common Lisp, rather than a fixed list generated from uLisp, then it would need to be in workspace memory and would use up some of the limited memory available.
Any suggestions?
Unless you expect to eventually add keywords to uLisp, there’s no real reason not to just use plain symbols. After all, the only real reason Common Lisp has keywords is to address the package system and the resulting uncertainty about which package a symbol is being read into. uLisp doesn’t have that.
As for implementation, it might be possible to hardcode a list in flash memory, and have the evaluator special-case the symbol *features* so it returns a reference to that list if nothing is found in the environment. That way, using the default features doesn’t cost anything in workspace, but it’s a little pricier in code size.
Thinking about it, I should probably just try and implement something like that, see if it works…
I’ve been thinking that it would be very easy to add keywords to uLisp, if they would be useful for anything else.
They’re quite useful as a way of defining enumerated types, for use in case, etc.
So, it works … on a von Neumann machine like the ARM. The AVR, which needs the optimisation the most, is a Harvard machine, and would need some way to know when to follow conses into code memory. Annoying.
For real life prototyping usage, there are real things we need, if it can be done, then ulisp will be more powerful than micropython, not just from language point of view. I see real power and potential. Embed dev boards will become cheaper and more capable in every year. We need real tools, and ulisp can be that tool!
My priorities :
Am I too mad? I hope not. If MicroPython can do, ulisp should be able to do more :)
Thank you for your enthusiasm!
- Arrays
This is definitely on the list of things to be added!
- More sensor library support, including more common dht11, 22 kind sensors
- More lcd display support, like nokia5110 lcd, it’s so common.
- Detailed guide how can we add sensor support, how can we contribute?
Currently there’s no way for users to upload new sensors to the library, but if you post them on the forum I’ll add them to the library.
Perhaps there should be a style guide for defining sensor interfaces; such as how they should be named, etc.
- Common camera sensor support, like ov2640,
- k210 capable of so many good things. It has builtin fft chip. How can we use it with ulisp. Also how can we use built in microphones? Most k210 and adafruit boards comes with it.
I thought about this when I was working on the K210 boards. To be useful the camera and microphone need to be interfaced in a way that would allow uLisp programs to access and process their data, and I couldn’t see an obvious way to do this. Any suggestions?
- Tinyml support. Most difficult one. New arm m4 boards comnes with built-in sensors, k210 boards already had that. How can we add that?
I’m not sure how that could work. Suggestions?
Thanks, David
MicroPython does not even attempt to support the more memory-constrained systems that uLisp does. I suspect that it is also implemented in a way that mirrors CPython by compiling to bytecode and then interpreting that, rather than being entirely an interpreter like uLisp is. MicroPython (and CircuitPython) are also not built on top of the Arduino environment, which can be frustratingly inefficient.
I’m not saying it’s impossible to make uLisp match or exceed them in capabilities, just that these are things to keep in mind.
You’re welcome. Thanks for your fantastic work.
I agree and hope to have it. Then we can help more.
I couldn’t see either. Seems like only Chinese knows. Like how to work with ESP WiFi’s. It’s only on paper.
It seems they builded all Arduino core from Kendryte Standalone SDK. Some code - especially related to DL algorithms looks like closed licensed.
So if there will be any starting point, it should be first Arduino core - which is mostly hit and miss(but some things interestingly works well like lvgl) - then Standalone SDK.
About TinyML - the book : https://www.amazon.com/TinyML-Learning-TensorFlow-Ultra-Low-Power-Microcontrollers/dp/1492052043
The Code and explanations - boards - sensors - everything : https://www.tensorflow.org/lite/microcontrollers
Basically gathering rich sensor data from microcontrollers and using that for creating and training Deep Learning models, then optimizing these models for microcontrollers. End goal is limiting cloud dependency, more intelligent IoT devices, etc. Which I imagine you all already know.
All TinyML supported boards are already supported by ulisp. We just need more sensor driver - interface, etc. If we have that, we can quickly prototype with them using ulisp and it will become much more important than we can imagine.
This is the getting starting guide for more curious : https://www.tensorflow.org/lite/microcontrollers/get_started