What new features would you like to see in uLisp?

#25

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

#26

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.

#27

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

#28

I should add; it kills me to knowing first neural network codes mostly written with lisp: I have Tanimoto’s book, and I would love to work on Deep Learning with Lisp, even a tiny bit, maybe becomes possible with ulisp…

#29

Thank you for all the suggestions. There’s a beta version of ARM uLisp containing some of the requested features:

#30

A post was split to a new topic: Contributing to the Sensor Library

#31

I bought Particle Xenon from a local shop; because it’s retired I can be able to find cheap : https://www.sparkfun.com/products/retired/15070

The Board has powerful features, especially onboard 4MB SPI Flash, great for ulisp, here is the list of features :

  • Nordic Semiconductor nRF52840 SoC
    • ARM Cortex-M4F 32-bit processor @ 64MHz
    • 1MB flash, 256KB RAM
    • IEEE 802.15.4 - 2006: 250Kbps
    • Bluetooth 5: 2Mbps, 1Mbps, 500Kbps, 125Kbps
    • Supports DSP insturctions, HW accelerated Floating Point Unit (FPU) calculations
    • ARM TrustZone CryptoCell-310 Cryptographic and security module
    • Up to +8 dBm TX power (down to -20dBm in 4dB steps)
    • NFC-A tag
  • On-board additional 4MB SPI flash
  • 20 mixed signal GPIO (6x Analog, 8x PWM), UART, I2C, SPI
  • Integrated Li-Po charging and battery connector
  • JTAG (SWD) Connector
  • RGB status LED
  • Reset and Mode buttons
  • On-board PCB antenna for mesh network
  • u.FL connectors for external antennas for mesh network, and NFC
  • FCC, CE, and IC certified. RoHS compliant

I bought this because with your array support on ARM, and addition of my sensors, I’m hoping I can try some TinyML demos, because Ulisp save image - load image capability is there . When I recieve the board, I’ll try with ulisp then I’ll share my experiences.

I hope you can add tensorflowlite for microcontrollers libraries to ulisp, especially for that chip. The board has enough ram for extra stuff. I’ll definitely love to demo that if it can be there.

Thanks for all of your effort.

#32

Looks interesting - I’ve found one at a pretty good price too and ordered it.

#33

Yeah, it priced 11$ at particle store : https://store.particle.io/products/xenon

If you add to these sensors on below to the board, you can do all TinyML Demos, which I have most of them:

  • VC0706 TTL Camera
  • IMU|LSM9DS1
  • Microphone - MP34DT05
  • Gesture, light, proximity - APDS9960

Mems microphone seems not very effective on demos, there for I will use MAX9814 which Adafruit used on their demos, other than that, it will look same I hope.

I can use your help with some of these sensors, they are not yet supported in ulisp, which I intent to use.

You can review all of this from here :

Youtube Demo :

#34

They also used that, which I forget to add to my answer :

  • Stereo 3.7W Class D Audio Amplifier - MAX98306

and that too :

Electret Microphone Amplifier - MAX4466 with Adjustable Gain

I had MAX9814, but it’s enough for the job.

#35

OK, a feature idea: a buffer of e.g. the last 5-10 commands given to ulisp. And when you press some definable key, for instance up and down (but should be user-definable in the source), scroll up and down through this buffer. The command should be presented without immediately being executed, requiring the user to either press Enter, or to - edit it. :) It could be based NOT on “physical lines” (the way readline handles it), but based on “entire s-expressions”.

Now, WHY would such a facility be needed? Well, in order to test a function with complex inputs. Then, you can just re-adjust the function arguments and simply hit Enter, instead of typing off all the function with all arguments again.

#36

Interesting! Are there any other IDEs that provide this feature?

#37

SLIME has a rather extensive history facility, which is indeed based on complete inputs rather than line-oriented.

I do suspect that this is something that would be much easier to provide in an off-chip IDE, rather than building it into uLisp.

#38

Anything you fire up with “rlwrap” on Unixoids does something like that: e.g. rlwrap sbcl, rlwrap ecl — this gives “line edit history” to ANY program that by itself does not have it. Just the orientation to a “line” instead of a sexp might not be ideal for Lisp, as it often gives you a “line” that is an incomplete form. I think this is a matter of preference.

#39

How 'bout having Control-C abort a running function
and/or abort the current input?

Say I’m entering a multi-line function and “CRAP!” I see
a misteak :) on the previous line. Just lemme hit a CTRL-C
and go back to the REPL prompt. Thoughts?

    -Rusty-
#40

I’ve started a new thread to revive this topic:

#41

OK, ONE thing comes to mind which I might propose: “reliable portability”. Bringing it to Pi Zero may eventually help that, too.

See, when you try to compile 1980s’ programs, all sorts of libraries are missing, and even with stuff from the early 2000s, I am usually having great issues, not least due to non-standardized sizes of floats, integers, pointers and whatnot.

uLisp has become, let us be frank, a “serious” language. David, there is no question about it.

What I would thus propose is to make a “maximally portable variant” of it, cutting, of course, some corners, but making something that can be compiled under DOS, Mac OS, Windows, Linux, … — GPIO / files may “have to go” (perhaps reading source from pipes), but it would simply be nice that this thing… “stays forever”, as it is really, really marvellous.

Just an idea. :)

#42

@johnsondavies

Dear David,

I have a funny idea that in my latest creations (not tried with ulisp) proved VERY useful:

a “RUN LIMIT”.

That is, the maximum number of operations of your interpreter before the program halts (perhaps with a chance for your to continue it, IF you wish - I do not even provide that). While you cannot control what operations and what loops and what recursions the user does - you CAN control whether your interpreter is supposed to execute them.

I do it this way: runlimit==0 means “infinite run”, and NOTHING is stopped (you could make that the default, though I actually make “5 * instruction memory” the default). Any other runlimit setting might count, for instance, single or tens or hundreds of operations (to fit into a 16-bit integer), countdown, and when it reaches 1, it terminates and returns the user to the prompt, with an indication that his runlimit ran out.

The thing is, RARELY do people want an infinite loop. If your board loops infinitely, it does either something very smart or something very stupid. (When it happens to me, 95% of cases it is the second thing.)

I know, the board could simply be reset instead - but that will clear all unsaved instructions and certainly all data, whereas “having a run limit” totally helps “post mortem analysis”.

Yeah, I know, Turing would not approve of my solution to the Halting Problem, but once you have it, I promise, you will LOVE it. Given that your ulisp seems also advertised in educational settings, I think that a run limit will prove useful for anyone to figure out “what happened”. - The downside, of course, is that some algorithms may require an infinite run limit, but then again, “if you are so smart to make such an algorithm, be so smart and set the run limit to 0”.

#43

Intereresting idea!

I know, the board could simply be reset instead - but that will clear all unsaved instructions and certainly all data, whereas “having a run limit” totally helps “post mortem analysis”.

You know that you can already interrupt a running program by typing “~”? This isn’t as severe as Reset, as it leaves all your functions and variables unaffected.

The difficult part of your suggestion is the “post mortem analysis”. Ideally one would want your “run limit” to leave you in a state where you could examine the values of local variables, etc, and even carry on from where you stopped. The “~” escape key doesn’t allow you to do this either.

I’ll think about whether the “~” escape key could behave like the (break) function call, to let you examine the state of your program, or continue. Would that be useful, and provide something close to what you’re looking for?

#44

Ah, David, wonderful, you ARE always one or more steps ahead! :D

I actually must say, I do not suggest you to do anything, then, the present functionality of ~ would perfectly suffice. Like, the user can set then the desired variables with SETF, and just “watch what happens”. I just had no idea one could “stop the whole thing”, which is absolutely sufficient in the vast majority of cases.

(In fact, when I am debugging, I am usually just making the function merely print a list of its arguments immediately after having been called, and that normally suffices. My suggestion stemmed from the fact that my project has non-interactive phases and could not be stopped in your much more elegant way.)