How to make a natively written patch available

clevijoki 2018-09-10 01:09:43 UTC #1

I've made a patch I want to share, written in C++.

I have been developing via linux and the make dfu command, uploading firmware directly with my own "factory patch" However I suspect there are other ways to do it via sysex.

How does this work? I built the FirmwareSender app but I can't figure out how to make it work. It also seems to have the ability to upload a patch into a single slot, how would I build a patch that can be uploaded this way? I've used some other features of the CMSIS library that would require being linked in as well.

I can just make the OwlWare.bin available but it may not be ideal if people want to use other patches at the same time.

bfabricius 2018-09-10 09:52:29 UTC #2

hi @clevijoki,

im not 100% sure i understand your question fully, but you can share you patches online if you want using the online patch library here: https://www.rebeltech.org/patch-library/patches/latest

if what you are looking for is an alternative way to program your owl device, you can use FimwareSender for that. Either compile and run it from command line yourself or you can also check out how, a virtual machine that will support compiling and deploying polyglot patches to owl devices eventually. It is work in progress but should work for C++ patches out of the box: https://github.com/bfabricius/howl

There should be enough documentation to get you going
Ill be adding plenty of new features whenever i have the chance, also programming user patches to specific user slots.

Cheers,
Ben

clevijoki 2018-09-10 16:03:34 UTC #3

I can't use the online patch compiler, as I link with other SIMD features that it does't allow me to use. e.g. I use q7_t and related CMSIS DSP functions.

If you look at the firmware source code there is a libs.mk that requires adding new CMSIS objects in there:

github.com

pingdynasty/OwlWare/blob/master/libs.mk

# object files
OBJS += $(PERIPH) 
OBJS += $(BUILD)/startup.o
OBJS += $(BUILD)/libnosys_gnu.o
OBJS += $(USB_DEVICE) $(USB_OTG)
OBJS += $(DSPLIB)/FastMathFunctions/arm_sin_f32.o
OBJS += $(DSPLIB)/FastMathFunctions/arm_cos_f32.o
OBJS += $(DSPLIB)/CommonTables/arm_common_tables.o

OBJS += $(DSPLIB)/TransformFunctions/arm_cfft_f32.o
OBJS += $(DSPLIB)/TransformFunctions/arm_cfft_radix8_f32.o
OBJS += $(DSPLIB)/TransformFunctions/arm_bitreversal2.o
OBJS += $(DSPLIB)/TransformFunctions/arm_rfft_fast_f32.o
OBJS += $(DSPLIB)/TransformFunctions/arm_rfft_fast_init_f32.o
OBJS += $(DSPLIB)/CommonTables/arm_const_structs.o

# OBJS += $(DSPLIB)/FilteringFunctions/arm_biquad_cascade_df1_init_f32.o
# OBJS += $(DSPLIB)/FilteringFunctions/arm_biquad_cascade_df1_f32.o
OBJS += $(DSPLIB)/FilteringFunctions/arm_biquad_cascade_df2T_init_f32.o
OBJS += $(DSPLIB)/FilteringFunctions/arm_biquad_cascade_df2T_f32.o

This file has been truncated. show original

I can't force those into the online compliler (I can try including them .c files as relative paths but it fails with that, it seems like permissions won't let the online compiler read the files)

At some point though, the online compiler genreates a sysex file that can be uploaded, if I could just generate that myself via the make files somehow that would be good enough. Technically, what does the online compiler do here to just compile the object? is it making a shared lib?

I can also make the firmware (OwlWare.bin) into a sysex file via FirmwareUploader -file option. But then I haven't found a way to actually upload it to the pedal to ensure that it works correctly, but that could just be my misunderstanding of how to run FirmwareUploader.

mars 2018-09-11 14:48:31 UTC #4

Hiya!

The online compiler runs OwlProgram, which is our build tool. It creates a 'dynamic' patch that the firmware can load into RAM and execute, and which can also be stored in flash (in what we call a user slot). It is this dynamic patch that is wrapped up as a sysex that you can download from the patch library.

HOWL is @bfabricius project which is designed to make it easier to run OwlProgram by wrapping up all the dependencies in a VM.

If you compile offlline with OwlProgram, through howl or directly, then you can control all the compilation settings yourself.

If you could post a link to your patch code then we can maybe offer more advice.

best,

Martin

clevijoki 2018-09-13 14:25:04 UTC #5

The code is here:

github.com

clevijoki/NESPatch/blob/master/NESPatch.h

#pragma once

/*
Copyright 2018 Clint Levijoki

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy,
modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the 
Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE 
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/

class NESPatch : public Patch
{

This file has been truncated. show original

I will try OwlProgram, I should be able to modify it to make it work.

So is the dynamic patch compiled to run at a specific memory address then, and it just overwrites that 'user patch' memory address?

mars 2018-09-13 15:45:38 UTC #6

Yes that's right. The dynamic patch is linked to SRAM address 0x2000c000. Loading the patch doesn't change the nested interrupt vector, so all interrupts are handled by the main firmware. Communication between firmware and dynamic patch is done through the ProgramVector which is a struct in shared memory.

OwlProgram manages all this, and produces a binary which can simply be copied (by the firmware) to the correct address then branched to.

mars 2018-09-13 17:00:43 UTC #7

I got it to compile by first adding this near the top of the patch:

#define AUDIO_BLOCK_SIZE 128
#undef abs
#undef max

and then adding the file NESPatch.hpp to a directory along with the dependencies:

arm_abs_q7.c
arm_float_to_q7.c
arm_q7_to_float.c
arm_copy_q7.c
arm_max_q7.c

I've got a copy of it here: https://www.rebeltech.org/patch-library/patch/untitled_d0160b4a9e47
Unfortunately using the CMSIS DSP library directly means that it won't compile for Javascript - but it should run fine on the hardware!

Looks interesting - and I see we use the same random shift register!

github.com

pingdynasty/OwlProgram/blob/master/LibSource/basicmaths.c#L42




void arm_srand32(uint32_t s){
 r32seed = s;
}


/**
* generate an unsigned 32bit pseudo-random number using xorshifter algorithm.
* "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." 
* -- John von Neumann.
*/
uint32_t arm_rand32(){
 r32seed ^= r32seed << 13;
 r32seed ^= r32seed >> 17;
 r32seed ^= r32seed << 5;
 return r32seed;
}


float randf(){
 return arm_rand32()/4294967296.0f;
}

It would be good if you could dynamically allocate memory and use getBlockSize() instead of relying on AUDIO_BLOCK_SIZE being correct.

hth,

Martin

mars 2018-09-13 17:03:13 UTC #8

ps I compiled it, with all files in a folder called NES, using this command:

make PATCHSOURCE=NES PATCHNAME=NES clean run

(requires renaming NESPatch.h to NESPatch.hpp)