port to hvcc

[dromer]

Hey there,

I've been working on an updated hvcc using python3 with some new targets (dpf): https://github.com/Wasted-Audio/hvcc Would you be interested to get your pd2dsy wrapper integrated as a new target?

I don't have a daisy myself to test (yet), but it seems your templating is relatively simple at least.

Let me know what you think.

[stephenhensley]

Hi @dromer

You had me at python3 (since this is the only thing in our ecosystem of tools that requires python2).

This sounds great, and we'd be happy to help where necessary.

The current pd2dsy is based around board-based templating since the official boards , and at some point I'd like to move to a JSON model of some sort that would better allow for custom hardware, etc.

Feel free to let me know if there's anything I can do to help or if you have any questions. I'm not too familiar with the hvcc code base myself, but can help out with anything Daisy related.

[dromer]

I have to get back into it, maybe I'll purchase a daisy just to motivate myself to get going :D

[dromer]

I started working on it in this branch: https://github.com/Wasted-Audio/hvcc/tree/feature/daisy - no working builds yet, but I'm also totally not familiar with the daisy setup :) I'm taking just about the same approach as with DPF, Makefile is where the magic probably needs to happen.

For now I made the board configurable via an extra optional parameter to pass on a json with extra metadata information (I want to do something similar in DPF later). However I thought eventually we could simply run a for-loop and just add/build all the boards at once, what do you think? Do patches need to be tailored to a specific board always?

[stephenhensley]

Cool to see! Yeah, the makefile will be where most magic happens (along with the startup/linker files provided in libdaisy/core).

The specific board is pretty core to the way pd2dsy is set up right now. Setting that allows for using just that one c++ class, and it's common API, which reduces the need for a much more specific interface for configuring which pins do what on a given piece of hardware.

Long term, I would like to move toward something that can be configured purely in json or something so that working with custom hardware is just as easy as working with one of the electrosmith breakout boards, but we're not quite there yet.

Another consideration is that the memory is fairly limited on the Daisy. So we don't want to do very generic things like build for all boards if it can be avoided since it'll bloat the binary a bit. The current limitation is only 128kB, and we're working on an update that will expand this to allow for larger (about 512kB or so) binaries.

[dromer]

Made a little bit of progress on this: https://github.com/Wasted-Audio/hvcc/pull/18

However when building a target I get some conflicts:

$ make
mkdir build
arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard  -DUSE_HAL_DRIVER -DSTM32H750xx -DHSE_VALUE=16000000  -DCORE_CM7 -DSTM32H750IB -DARM_MATH_CM7 -DUSE_FULL_LL_DRIVER  -Ic/ -include stm32h7xx.h -I../../libdaisy -I../../libdaisy/src/ -I../../libdaisy/src/sys -I../../libdaisy/src/usbd -I../../libdaisy/Drivers/CMSIS/Include/ -I../../libdaisy/Drivers/CMSIS/DSP/Include -I../../libdaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../../libdaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I../../libdaisy/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I../../libdaisy/core/ -I../../libdaisy/Middlewares/Third_Party/FatFs/src -O2 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -Wno-stringop-overflow -g -ggdb -MMD -MP -MF"build/startup_stm32h750xx.d" -std=gnu11 -Wa,-a,-ad,-alms=build/startup_stm32h750xx.lst ../../libdaisy/core/startup_stm32h750xx.c -o build/startup_stm32h750xx.o
arm-none-eabi-g++  -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard  -DUSE_HAL_DRIVER -DSTM32H750xx -DHSE_VALUE=16000000  -DCORE_CM7 -DSTM32H750IB -DARM_MATH_CM7 -DUSE_FULL_LL_DRIVER  -Ic/ -include stm32h7xx.h -I../../libdaisy -I../../libdaisy/src/ -I../../libdaisy/src/sys -I../../libdaisy/src/usbd -I../../libdaisy/Drivers/CMSIS/Include/ -I../../libdaisy/Drivers/CMSIS/DSP/Include -I../../libdaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../../libdaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I../../libdaisy/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I../../libdaisy/core/ -I../../libdaisy/Middlewares/Third_Party/FatFs/src -O2 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -Wno-stringop-overflow -g -ggdb -MMD -MP -MF"build/HeavyDaisy_petal_test.d" -fno-exceptions -fasm -finline -finline-functions-called-once -fshort-enums -fno-move-loop-invariants -fno-unwind-tables -Wno-register -std=gnu++14 -Wa,-a,-ad,-alms=build/HeavyDaisy_petal_test.lst HeavyDaisy_petal_test.cpp -o build/HeavyDaisy_petal_test.o
In file included from HeavyContextInterface.hpp:20:0,
                 from HeavyContext.hpp:20,
                 from Heavy_petal_test.hpp:37,
                 from HeavyDaisy_petal_test.hpp:43,
                 from HeavyDaisy_petal_test.cpp:33:
HvUtils.h:33:4: warning: #warning Could not detect platform. Assuming Unix-like. [-Wcpp]
   #warning Could not detect platform. Assuming Unix-like.
    ^~~~~~~
In file included from Heavy_petal_test.hpp:39:0,
                 from HeavyDaisy_petal_test.hpp:43,
                 from HeavyDaisy_petal_test.cpp:33:
HvSignalTabwrite.h: In function 'void __hv_tabwrite_stoppable_f(SignalTabwrite*, float)':
HvSignalTabwrite.h:77:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (o->head != HV_TABWRITE_STOPPED) {
               ^
In file included from Heavy_petal_test.hpp:43:0,
                 from HeavyDaisy_petal_test.hpp:43,
                 from HeavyDaisy_petal_test.cpp:33:
HvSignalTabread.h: In function 'void __hv_tabread_stoppable_f(SignalTabread*, float*)':
HvSignalTabread.h:141:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (o->head == ~0x0) {
       ~~~~~~~~^~~~~~~
HeavyDaisy_petal_test.cpp: In function 'int main()':
HeavyDaisy_petal_test.cpp:72:39: error: no matching function for call to 'StartAudio(void (&)(float**, float**, size_t))'
     hardware->StartAudio(audiocallback);
                                       ^
In file included from HeavyDaisy_petal_test.hpp:49:0,
                 from HeavyDaisy_petal_test.cpp:33:
../../libdaisy/src/daisy_petal.h:83:10: note: candidate: void daisy::DaisyPetal::StartAudio(daisy::AudioHandle::InterleavingAudioCallback) <near match>
     void StartAudio(AudioHandle::InterleavingAudioCallback cb);
          ^~~~~~~~~~
../../libdaisy/src/daisy_petal.h:83:10: note:   conversion of argument 1 would be ill-formed:
HeavyDaisy_petal_test.cpp:72:39: error: invalid conversion from 'void (*)(float**, float**, size_t) {aka void (*)(float**, float**, unsigned int)}' to 'daisy::AudioHandle::InterleavingAudioCallback {aka void (*)(const float*, float*, unsigned int)}' [-fpermissive]
     hardware->StartAudio(audiocallback);
                                       ^
In file included from HeavyDaisy_petal_test.hpp:49:0,
                 from HeavyDaisy_petal_test.cpp:33:
../../libdaisy/src/daisy_petal.h:88:10: note: candidate: void daisy::DaisyPetal::StartAudio(daisy::AudioHandle::AudioCallback) <near match>
     void StartAudio(AudioHandle::AudioCallback cb);
          ^~~~~~~~~~
../../libdaisy/src/daisy_petal.h:88:10: note:   conversion of argument 1 would be ill-formed:
HeavyDaisy_petal_test.cpp:72:39: error: invalid conversion from 'void (*)(float**, float**, size_t) {aka void (*)(float**, float**, unsigned int)}' to 'daisy::AudioHandle::AudioCallback {aka void (*)(const float* const*, float**, unsigned int)}' [-fpermissive]
     hardware->StartAudio(audiocallback);
                                       ^
HeavyDaisy_petal_test.cpp: In function 'void ProcessControls()':
HeavyDaisy_petal_test.cpp:83:15: error: 'class daisy::DaisyPetal' has no member named 'DebounceControls'; did you mean 'InitAnalogControls'?
     hardware->DebounceControls();
               ^~~~~~~~~~~~~~~~
               InitAnalogControls
HeavyDaisy_petal_test.cpp:84:15: error: 'class daisy::DaisyPetal' has no member named 'UpdateAnalogControls'; did you mean 'InitAnalogControls'?
     hardware->UpdateAnalogControls();
               ^~~~~~~~~~~~~~~~~~~~
               InitAnalogControls
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-missing-attributes'
make: *** [../../libdaisy/core/Makefile:224: build/HeavyDaisy_petal_test.o] Error 1

You can probably better discern how to proceed :)

If you want to try, you can run a build like this (using your examples): hvcc petal_test.pd -m meta.json -n petal_test -g daisy -o . With a meta.json like:

{
    "board": "petal"
}

Then make sure there is a libdaisy/ and cd daisy/source/ && make.

[stephenhensley]

This line:

cc1plus: warning: unrecognized command line option '-Wno-missing-attributes'

is making me think that your compilation process isn't using the arm-none-eabi cross compiler when compiling for daisy.

I do recall seeing a ton of warnings last time I compiled one of the pd examples, but most of them seemed harmless.

Is your libdaisy still on the (very old) commit 347eb0f? If it's been updated that could also cause some of the issues you're seeing. The template files would need quite a few changes to be brought up to speed with the current state of the library. We're actually going to be doing a bit of an update to that in the next week or two, but for now you should still target that ref if you're not already.

If it's not either of the above, and you're still stuck, I can carve out some time to give what you've got a try sometime this week or next, and let you know if I can see what's going wrong.

Hope that helps! Exciting to see the progress!

[dromer]

It should be using arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

My libdaisy is on 3ade553ede6f1730688a4d41ebb9b98ca74cb5b5

[stephenhensley]

@dromer gotcha, maybe it was just the way it was reporting to the command line.

Ah, the ref you're on is the current master branch for libdaisy. You can manually revert back to the previous location by doing the following from the libdaisy directory:

git checkout 347eb0f

That should fix all of the issues with conversion arguments, etc.

I also recommend you update your arm-none-eabi to the latest version. Package managers in linux frequently lag behind by many many versions, and chips including the H7 may not be fully supported. We have a guide for installing the versions of the tools for each OS as well.

This is the version we use, and recommend others use:

arm-none-eabi-gcc.exe (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)

[dromer]

that commit hash does not exist according to git

[stephenhensley]

Ah, that's my mistake!

I must have mistyped:

d47eb0f

Sorry about that!

[dromer]

Ok! that gets me further, but now my knowledge of gcc/makefiles/etc. goes kaput:

arm-none-eabi-g++  build/system_stm32h7xx.o build/startup_stm32h750xx.o build/HeavyDaisy_petal_test.o  -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nano.specs --specs=nosys.specs -T../../libdaisy/core/STM32H750IB_flash.lds -L../../libdaisy/build  -ldaisy -lc -lm -lnosys -Wl,-Map=build/HeavyDaisy_petal_test.map,--cref -Wl,--gc-sections -o build/HeavyDaisy_petal_test.elf
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: cannot find -ldaisy
collect2: error: ld returned 1 exit status
make: *** [../../libdaisy/core/Makefile:200: build/HeavyDaisy_petal_test.elf] Error 1

Please have a look if you will, the basics should be there as described.

[stephenhensley]

I totally understand!

Now that you've checked out the proper version of the library it needs to be compiled (this can be done by running make directly from the libdaisy/ directory. (This only needs to be done when updating the library, or the first time you clone it).

[dromer]

-rw-r--r-- 1 dreamer dreamer  3.7K Jul 15 19:15 HeavyDaisy_petal_test.d
-rw-r--r-- 1 dreamer dreamer   18K Jul 15 19:15 HeavyDaisy_petal_test.o
-rw-r--r-- 1 dreamer dreamer   90K Jul 15 19:15 HeavyDaisy_petal_test.lst
-rw-r--r-- 1 dreamer dreamer 1013K Jul 15 19:15 HeavyDaisy_petal_test.map
-rwxr-xr-x 1 dreamer dreamer  1.6M Jul 15 19:15 HeavyDaisy_petal_test.elf
-rw-r--r-- 1 dreamer dreamer  276K Jul 15 19:15 HeavyDaisy_petal_test.hex
-rwxr-xr-x 1 dreamer dreamer   98K Jul 15 19:15 HeavyDaisy_petal_test.bin

:champagne:

[stephenhensley]

Woo! Nice! 💥

[dromer]

do you want a zip with some files so you can confirm if these actually work? :D

I'm now using the patches in your example/ folder (going to copy them over for documentation. renaming saw to seed for consistency)

[stephenhensley]

That'd be great! I can give them a try some time in the next few days or so.

[dromer]

which files do you want, everything I listed?

[stephenhensley]

You can just zip up all of the bins. That's what I'll be using to upload them onto the Daisy.

[dromer]

There you go: https://mrtoasted.com/~dreamer/hvcctest/heavydaisy_build-test.zip

[dromer]

I'm tempted to merge this into my develop tree. If you run into issues we'll work on fixing those.

Plenty of work needed to make hvcc streamlined for all generators, most of which I myself don't even use. I did just order a Befaco Lich kit that I can build and test out the OWL stuff with.

Tempted for a Daisy Field in the future (or a Patch, if you ever sell kits :D)

[dromer]

@stephenhensley and?

[stephenhensley]

@dromer thanks for the ping! The week got away from me. I'll try to flash up the bin files to verify today.

Also worth mentioning I've been working with a few others on a more standardized JSON format for board implementations that would allow for breadboard/custom hardware without having to rely on the premade board support classes, etc. Once we've got this a bit more ironed out I'll be sure to share the details with you.

[andrewikenberry]

@dromer I'd be happy to send over some Daisy hardware.

Get in touch and we can work something out.

aikenberry [at] electro-smith.com

[dromer]

@stephenhensley sure! we can see how to get hvcc to read in such details and use that inside the templates. Would indeed make things much more flexible for the diy enthousiasts :)

@andrewikenberry expect an email shortly ;)

[dromer]

/me pokes @stephenhensley with a sharp stick

And? :)

[stephenhensley]

@dromer

Sorry for the delay, things have been a bit busy.

Checked the seed, pod, and petal examples and they all work as expected!

Interestingly, the binary size is a smidge (1-3kB) bigger than the local copies I have from the current system. Though, there could be a number of reasons for that.

[dromer]

That's somewhat odd, but "all work as expected" is good enough for me :D

I want to look at a little bit of cleanup and call it "functional" for now (good enough to merge to develop) and hopefully we can do some more testing before this goes into the 0.2 release

[stephenhensley]

@dromer yeah, totally could have been that I built the previous binaries with different optimization settings from the default, or an older version of libdaisy.

[dromer]

Current work merged to develop: https://github.com/Wasted-Audio/hvcc/commit/5e4836477d990b6f5f53dfbe41d120990bad4c4a

I'll likely add a generator-key to the meta-file because in some cases it would be nice to use the same source-files for different output targets.

[dromer]

Something like:

{
    "name": "testmodule",
    "daisy": {
        "board": {
            <daisy_json>
        }
    }
}

Alternatively the board def can be just a string and then use included templates for daisy products. I'm also tempted to allow a list, so you can build several targets at once.

[stephenhensley]

Interesting for building several targets.

For some context on the meta-files that we plan on supporting, oopsy (the max/msp gen~ integration) already supports JSON for most basic component connections, and has some short generator code that actually renders the c++ template necessary.

For reusability sake, I'd like to keep this format the same across all integrations so that we can easily update board definitions in a single place and generate code from as many places as possible. Ideally, the actual generator code would be reused as well, but for now it's written in javascript for oopsy.

That said, there are still a few things missing (like custom connections for OLEDs, Multiplexors, shift registers, etc.).

I shared this on the forum, but might as well put it here as well. This is the oopsy-compatible JSON that would be used to generate the Daisy Pod.

The defines get added into the makefile's C_DEFS list (or added as a define at the top of the header), though these are oopsy specific and wouldn't do anything in pd2dsy yet.

The components are the physical mappings from pin(s) on the daisy to some named class in libDaisy.

The aliases are used as alternate names that can be used to map the parameters via the objects in oopsy, or in our case Pd.

For pd support, I don't think supporting the aliases is very necessary. We can use the component "name" there.

---

We're wrapping up the work on the alternate bootloader/memory configurations now, and will be beginning to work this stuff into pd2dsy just to get it to a place where there is better all around hardware compatibility, and then we can work to help you migrate those changes into hvcc as well. Unless you happen to jump on it before we get there. We'll probably start working the meta data stuff into the existing pd2dsy in the next few weeks, and I expect it to come together pretty quick.

Figured I'd keep you up to date with where we're at as well.

Here's the reference JSON for the Daisy Pod.

{
    "name":"pod",
    "defines": {
        "OOPSY_TARGET_HAS_MIDI_INPUT": 1
    },
    "components": {
        "sw1": {
            "component": "Switch",
            "pin": 27
        },
        "sw2": {
            "component": "Switch",
            "pin": 28
        },
        "knob1": {
            "component": "AnalogControl",
            "pin": 21
        },
        "knob2": {
            "component": "AnalogControl",
            "pin": 15
        },
        "encoder": {
            "component": "Encoder",
            "pin": {"a":26, "b":25, "click":13 }
        },
        "led1": {
            "component": "RgbLed",
            "pin": {"r":20, "g":19, "b":18 }
        },
        "led2": {
            "component": "RgbLed",
            "pin": {"r":17, "g":24, "b":23 }
        }
    },
    "aliases": {
        "switch": "sw1",
        "button": "sw1",
        "switch1": "sw1",
        "button1": "sw1",
        "switch2": "sw2",
        "button2": "sw2",
        "enp": "encoder_press",
        "switch3": "encoder_press",
        "press": "encoder_press",
        "knob": "knob1",
        "ctrl": "knob1",
        "ctrl1": "knob1",
        "ctrl2": "knob2",
        "led": "led1"
    }
}

[dromer]

Just released https://github.com/Wasted-Audio/hvcc/releases/tag/v0.2.0 which puts "official support" for Daisy in.

Will close this topic and track any future hvcc support over there :)

[stephenhensley]

@dromer Awesome!!

Once we've got the custom board json, and alternate program configs set up and working here, I'll make some issues on the Wasted Audio fork, and help get that stuff migrated in there.