Over at the plugdata project, we’re looking at supporting the OWL platform with the built-in Heavy compiler/flasher. I can’t seem to find a pinout diagram for the OWL Platform and I’d love to get one to experiment with. The only diagrams I’ve found are for earlier revisions. Is there such a diagram available somewhere for Rev07?
Hey @JoshuaACNewman ,
What kind of experiments do you have in mind exactly?
OWL patches don’t interact with hardware directly. OWL firmware does that, while the patch only communicates with firmware via a shared memory area. For that reason you shouldn’t have to deal with pins and such unless you’re making some kind of custom module based on OWL.
If you want to know which pins are used by existing hardware, you can have a look at its CubeMX project i.e. for Lich it’s here or maybe at the main.h header that CubeMX generated
I’m not sure why they never documented pins on OWL mk2, might be simply due to lack of demand for this. They did document pins for Xibeca which has a different form factor and MCU, more audio channels, but still runs the same OWL firmware.
1 Like
The short answer is, yes, it’s for building custom modules.
The longer answer is that our intention with the project is to design toward compatibility for hardware platforms that have good audio capabilities and broad artistic purposes, from finished modules (e.g. Lich, Daisy) and instruments (e.g. Organelle) down to dev boards (Daisy Seed, Owl, Raspberry Pi).
I haven’t been able to figure out precisely what the capabilities of the Owl board are, even though they seem to be quite in line with what we’re trying to target. We’ve got Daisy working now, Critter & Guitari is talking with us about a simple upload process, and the hvcc toolchain of Owl is directly compatible with how we’re already compiling and flashing.
That Lich header file seems like it might be the map I was looking for! Thanks!
Xibeca looks neat, but also doesn’t seem to be available for purchase?
Xibeca boards are currently out of stock due to chip shortage and were supposed to be available later this spring. And a new (pin compatible) version of OWL board is coming soon too. Maybe you can get some better info from @Befaco
Oh, great to know Owl development is ongoing! If it’s the same process to compile for and flash Xibeca, then that’s great news and we’ll watch for its return with great interest.
@Befaco Let us know if you’re interested in getting plugdata flashing the Owl family from within the IDE. We’d love to have your participation!
Correct, patch compilation and flashing process is the same. And the resulting binary is compatible with all OWL devices as it’s hardware independent.
What can be a problem for plugdata is that HVCC that we use is a fork with some additions made before the compiler got abandoned. There was an attempt to switch to the current version of Heavy, but it got stuck in limbo for almost 2 years.
Hi Joshua! Short answer is YES!
Did not knew about plugdata, and its defiently looking beautiful!
AS @antisvin stated, Xibeca has been out of stock for way too much already, but we hope to get new units in Q2 or Q3 this year (fingers crossed!) Also, we are waiting for @mars to become a bit more available to nail down some hardware details.
From Befaco perspective we can help you with hardware so you can do some tests. But development wise, this si the place to be and antisvin and mars your sources of information! 
1 Like
I think you’ll find Dreamer is at work integrating your changes already!
I need to update this work. OWL stuff has been merged into HVCC last year, but I didn’t get around to continue the PR.
@JoshuaACNewman this was done over a year ago already 
plugdata integration should be fairly straightforward, since we already have the necessary compiler and other stuff in the toolchain. We just need to add the OWL firmware part and some hooks to the UI with any necessary choices.
Will try to get back to OWL testing and updating the PR soon-ish.
@Befaco I have a Lich already on which I’m doing all my tests.
Hi all, just wondered if there is any news on this? I’d love to be able to use PlugData with my Owl.
No there is no news. I’ve looked at what would be the minimum requirements to get the OWL toolchain working, but I haven’t pieced together anything tangible that works with the plugdata workflow yet.
Work on this is happening on github: https://github.com/plugdata-team/plugdata-heavy-toolchain/issues/13
I’ve started some work to try and bash together a minimal prototype for adding OwlProgram to the plugdata toolchain and into the plugdata compile dialog.
So far I’ve managed to successfully build and flash the test-patch: https://github.com/RebelTechnology/OwlProgram/blob/develop/TestPatches/HeavyTest/HeavyTest.pd
However using this patch from the Patch Library I am getting linker errors regarding the patch size: https://www.rebeltech.org/patch-library/patch/_Lich_Windrone#Source
/home/dreamer/Sources/_projects/_wasted/_hvcc/plugdata-heavy-toolchain-wstd/Heavy/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: ..//patch.elf section `.text' will not fit in region `PATCHRAM'
/home/dreamer/Sources/_projects/_wasted/_hvcc/plugdata-heavy-toolchain-wstd/Heavy/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: region `PATCHRAM' overflowed by 632400 bytes
collect2: error: ld returned 1 exit status
make[1]: *** [compile.mk:179: ..//patch.elf] Error 1
make: *** [Makefile:110: patch] Error 2
The patch size seems to be extremely large somehow, any insight into what’s going on would be helpful.
However I’m not using the regular make HEAVY=patch method of building, because we first export the OWL code directly using our PyInstaller version of HVCC in the plugdata toolchain.
We first export the hvcc code to a temporary directory <temp_path>/Source and then copy OwlProgram next to it in <temp_path>/OwlProgram.
Then from the OwlProgram directory we execute the following:
<path_to_our_toolchain/bin/>make -j4 TOOLROOT=<path_to_our_toolchain/bin/> BUILD=../ PATCHNAME=<patch_name> PATCHCLASS=HeavyPatch PATCHFILE=HeavyOWL_owl.hpp load
Hey @dreamer, good to hear that there’s some progress here! I guess you can take a look at what’s in readelf -a patch.elf output and compare it to what you get from OWL’s HVCC version.
I hope it’s not doing something funny like JSON parsing at runtime
There is no patch.elf created by the linker as it fails exactly at this stage.
Versions shouldn’t really differ that much. And as I said the HeavyTest.pd builds just fine.
Btw if I manually build/run with OwlProgram (same version, namely my fork: https://github.com/Wasted-Audio/OwlProgram ) it does work.
Could it have something to do with gcc versions? That’s the only thing I can definitely point to that is different between my local build and the one in the plugdata toolchain.
In the toolchain we are using arm-gcc v10.2 (this is pinned because of libDaisy) and locally I have v12.2
hmm, not sure what I did now, but my board just gives the infamous E. is unresponsive and gets super hot -_-
Ah right, sorry about that pointless suggestion If you just want to link a larger patch executable without being able to run it on hardware, you can edit Source/flash.ld and change the line PATCHRAM (rwx) : ORIGIN = 0x2000c000, LENGTH = 144K /* total RAM is 192kb */ to specify LENGTH = 1M or something like that.
Also, we have an option to build patches up to 512kb in size, but they would run only on OWL3 (or Xibeca) boards. This is done by passing PLATFORM=OWL3 when running make commands. It’s not enough to solve this issue (and compiler output is obviously not correct here either way).
Regressions due to toolchain change are certainly possible, I guess you could test the patch generated by OWL’s HVCC with 10.2 GCC to see if it’s also has this issue. Don’t forget to run make realclean; make libs when changing toolchain.
There is really almost no difference in HVCC or Heavylib of the OWL branch or the Wasted Audio branch.
And as said: when I manually build+load it does work (although right now my Lich seems to be completely dead somehow …)
Here’s the readelf outputs for arm-gcc 10 and 12. First one built for OWL3:
https://mrtoasted.com/~dreamer/owl/elf_gcc10.txt
https://mrtoasted.com/~dreamer/owl/elf_gcc12.txt
And for good measure also a build with the linker script patched for OWL2:
https://mrtoasted.com/~dreamer/owl/elf_gcc10_owl2.txt
And the patch used:
https://mrtoasted.com/~dreamer/owl/WindDrone.pd
Ok, so first of all I’ve mentioned wrong linker script, the default one is called owl2.ld and by setting platform to OWL3 you will use owl3.ld which has more RAM for patch code, specifies a different patch address and enables support for double precision FPU. I think you might have figured that out already, just mentioning it to make sure there’s no confusion.
So you say that both files built with GCC10 here are not working? It looks their size is ok and they should fit even in OWL2 SRAM.
Btw, I’ve tried running ./build.sh here and a few things failed, are there any uncommitted changes to this?