#22

ok so read up on linker scripts & tried to compile hempl for aleph last night, outside of avr32lib/aleph repo:

https://github.com/rick-monster/hempl
with:
scons cpu=AT32UC3A0512

no response from aleph on the serial port. Notice that power button works correctly with the new firmware flashed but other than that totally dark. Didn’t brick the aleph though - was able to reflash bees and back to normal… Any idea what might be going wrong or how I might be able to debug?

  • is it possible the usb UART is set up differently on the mizar32 board to aleph?
  • there was a bunch of stuff I didn’t understand in the aleph linker script. Is my revised hempl linker script missing vital stuff?
  • EVK1100 build target seems to be broken in the hempl master branch - maybe next step would be try to figure out what’s up with that?
  • Or somehow import config headers for the aleph board to hempl?

EDIT:

ok! on linux at least we can use fmemopen magic to spoof stdin/stdout! Fingers crossed it also works with avr32-gcc…

EDIT: aiieeeeeee! miniPicoLisp also uses a bunch of weird junk in a .d file (is that assembly!?) - tried hacking the picolisp from hempl into a clone of new aleph repo - somehow got it compiling but blows up on the device when you actually try to load simple (+ 1 1) expr using in-memory stream stdin. Trying again now to add aleph build target for hempl…

#23

It’s working it’s working!!! …

we have picolisp on aleph now! After many blind alleys, wrong turns & red herrings I finally figured out how to make picolisp accept input from a buffer. So we can run the usual avr32lib event loop, but there can now be a type of event to send a lisp expression for evaluation in the repl - just need to hook up some interesting lisp commmands like trigger dsp params, write to screen etc… Kind of curious how long will be the garbage collection pauses - will this be actually useable in the OS for a music computer??? Exciting stuff and there’s also @zebra’s pforth interpreter to try out I should try to hook that up tomorrow so we can compare lisp vs forth on this platform…

NOTE: umm yeah so although I can add numbers, define simple variables & functions etc it still blows up for some reason when lisp throws into debugger - but pretty sure now I will be able to catch & fix that. Most probably calling some undefined method on non-existant/hacked i/o streams. 4am now yeah better try and sleep…

EDIT: recovering gracefully from lisp errors now!

Because I just started hacking without planning properly or knowing for certain it would eventually work, code is all sitting in a mangled version of @zebra’s aleph blank app. So things need cleaning up a bit - but next question is how easy/hard is it to hook directly into avr32lib api calls (so is glue code necessary or can all the coding for that get done in lisp?). Time to hit the picolisp docs…

3 Likes
#24

that is so cool! now i just need a time machine so i can actually get a few hours to play with it.

FYI, pforth app isn’t in any kind of state. i just tossed the sources in there. i did look at it a bit since and got everything compiling. but need to make the same decision about how to restructure main and the event loop around the interpreter loop… i will have a gander at your solution…

#25

some points for anyone reading that code:

  • in order to arrive at the solution I eventually managed to refactor minipicolisp’s reader to not use stdio. What I ended up with is pretty much lisp-implementation-as-a-library. This minipicolisp was the starting point for my current version.

  • Host triggers the lisp by sending lisp expression as a char*, then print is via a host-defined callback function

  • That callback is currently defined here, but should be passed as an arg to init here

  • currently lisp doesn’t notify host program of lisp errors - shoud fix that really…

  • Hempl project includes a lightweight stdio implementation for avr32 providing proper stream abstraction for filesystem/uart, which is better, but I eventually gave up getting this to work inside avr32lib.

  • Would be nice to figure this out, even though I went round the stdio problem instead!

1 Like
#26

chucked the picolisp code into the old aleph repository & suddenly the thing initialises cleanly. Here’s some code https://github.com/rick-monster/aleph/tree/picolisp. Attempts to initialise the lisp image in the right place within @zebra’s new aleph repo framework were unsuccessful. With new aleph framework it needed some horrendous hack where the repl checks every time if it’s the first time - heinous!

I don’t have the patience to figure out why without a debugger - happy to offer pointers to anyone that wants to compile this for their teletype if it proves valuable on aleph…

Looking at mix app I was able to pilfer some code to hook up encoders to lisp function. So far I have the following functionality

  • mostly working lisp repl over serial (now with space-age backspace functionality)
    -… garbage collection works - the heap was specified as a whole megabyte by default which I guess is all the memory on aleph. with heap specified at 256kB gc seems totally instantaneous - see how that changes with an actual running program on there. gc explodes if you ask for much bigger heap than that…
  • lisp errors drop you into a debugger, as opposed to seventh circle of unresponsive segfault hell
  • encoders and front panel switches trigger lisp functions - you define what those things do by typing a function definition at the repl
  • lisp functions for playing etchasketch
  • decent callbacks from C into lisp

Here are the features required to turn this from a cool hack into an actual useful thing, then start putting together some performance scenes in lisp. In no particular order:

  • hook up lisp function (in C) to load a bfin prog from sdcard (think it’s quite easy - pulled in some code from bees to load waves on boot)
  • hook up lisp functions (in C) to query and tweak bfin params
  • lisp function to query the adc
  • steal the framed serial comms from aleph so you can send different messages over serial like we have in bees
  • an emacs mode for interactive coding on aleph from the comfort of your laptop - poor man’s slime would be just awesome and not fundamentally too difficult…
  • handle grid events
  • lisp function to light up grid
  • lisp function to callback another lisp function after a timeout (returns immediately)
  • handle keyboard events just like serial events
  • display lisp repl on aleph screen
  • lisp function returning the list of all lisp function definitions in RAM
  • lisp function to save all lisp function definitions in RAM to onboard storage for session persistence without sdcard
4 Likes
#27

OMG, aleph-picolisp is really coming along! great work!

sorry i’ve continued to be out of the loop, demands on time have made it really so hard to do anything fun like playing with aleph/TT.

yeah, the new aleph repo linked against new libavr32 isn’t really ready, sorry about that. libavr32 needs a handful of significant changes to work with aleph code, and haven’t really decided how to do that without also requiring changes to all the modules. when i look at it i just want to clean things up with sweeping refactors that affect all the repos.

anyways we should definitely fix that, should not even be hard. for the moment of course developing against the working aleph framework is fine - we shouldn’t have to break compatbility with the app code, between the old framework and the new.

i don’t know how useful it would be to have more than one interpreted language available. maybe detrimental actually, since ideally all scripts would be written in the same language and swapped on the fly? (or maybe they each have their areas of strength? what do you think?) so although i have a somewhat unreasonable desire to build things in FORTH right now, i should just start learning picolisp. [ tangential question: how different is it, on a practical level, from, say, common lisp? ]

in any case, your list of features reads like a good list for any interpreter to support. maybe could go on GH in case others want to contribute to small tasks? (i would love to but just can’t make promises right now.)

beyond cool, it would facilitate development in a great way

i will put a bootloader rewrite top priortiy of my task list since i don’t think it should be a great big task.

but yeah, anyone who wants to take advantage will need the ICE.

Hempl project includes a lightweight stdio implementation for avr321 providing proper stream abstraction for filesystem/uart, which is better, but I eventually gave up getting this to work inside avr32lib.

i missed this. i guess it would make a good GH issue for libavr32 repo.

1 Like
#28

depends whether lisp gc pauses are noticeable with bigger program running! As I understand it forth has no gc, which could be a crucial advantage. Who knows…

I also have been lured toward forth by an honest-to-god forth cpu running on little icestick fpga using 100% open-source verilog flow. Exciting times for sure!

Very very different - common lisp has soooo much stuff e.g native arrays, hashes, macros, reader-macros, compile-time-vs-run-time, lexical and dynamic vars, streams, format (printf(); on acid), loop (for(;; ); on crack). picolisp is probably closer to elisp than CL or scheme but I don’t know enough elisp or picolisp to really say for certain. Best place to start is probably here:
http://software-lab.de/doc/tut.html
but watch out there is some stuff in there you won’t find in the miniPicolisp that runs on aleph.

which ice is best? any idea if this one will do the job and play nice on linux? I don’t want to wait a month for this thing to arrive in BC from china

no prob I went sneaking around your github anyway to find it. Was clearly untested/experimental but yeah I was lured into this trap trying to jump on the spring cleaning bandwagon. Anyway it got things going - we’ll figure out what’s up with it eventually and get things into neat little boxes or something…

1 Like
#29

which ice is best? any idea if this one will do the job and play nice on linux? I don’t want to wait a month for this thing to arrive in BC from china

i don’t think you can use the AVRDRAGON for avr32? not sure.

the second one looks exactly like the official atmel jtagICE mk2, but i guess it is a clone? the official models have generally worked well for me, and i’ve seen varying results with clones (as one would expect.)

i’ve only ever used linux. i haven’t installed debug tools in a while; last0 i did it required you to get Atmel Studio (an eclipse fork) and pull the relevant executables out of there.

#30

ok well I did find this writeup from someone using avrdragon for 3UC3A0512 https://www.alvidi.de/data_sheets/pdf/bootloader/first_step.pdf

also listed on atmel’s tools page page for uc3 range the avrdragon is listed - so I will give that a try - 70 bucks is not too much to give it a whirl. Won’t test it on the aleph without successfully programming a less valuable board first - mizar32 would be an obvious choice for 25 euro then I could also play around with hempl a bit. Shame the postage to BC from italy will probably be more than the dirt-cheap board!

also think this is the exact same chip as aleph http://www.alvidi.de/shop/product_info.php?info=p32_AVR32-Development-Board.html though it starts to get pricey. Anyone know a cheap avr32 dev board widely available in north america?

EDIT: More I think about it probably should just wait with this whole thing on news of those aleph clone pcbs. For example I guess bees will just crash without bfin present, then how to debug without the screen or encoders!?