Sweet! In such case, I’ll add PR for H7 support. I think it should only need ST Cube package.
Also, once this is stable, we could have CI builds for new commits (at least for develop and master branches). Some of existing services offer this for free for open source software, so maybe we can make sure that new commits / PRs at least will build on all devices.
go for it!
with gcc cross-compiler?
Yeah, I suppose that there would be a way to install ARM-GCC toolchain. I expect that most of those services would work with makefiles (or docker images), so a compiler would be just another dependency for build pipeline. But I can do some research, maybe it’s too optimistic to expect that as part of their free offers.
Just noticed recent commit in development branch. I’m not sure if using MX_USB_Host_Process in loop() function would be a good idea. It runs once per 20ms on devices with screen, so at least screen update code should be changed to use shorter delay and just skip updates until 20ms have passed.
Also, since we’re using RTOS, maybe we should use RTOS support for USB (using “#define USBH_USE_OS”). This would basically call the same function in a separate OS thread , but that thread would be blocked if no new data is available. Could such trade of memory for CPU make some sense?
We’re not using pre-emptive task scheduling though, to avoid overheads. It’s part of the reason we’re getting so much audio performance out of relatively small microcontrollers - something like 98-99% of available clock cycles can be spent exclusively on audio processing.
If we can handle data send and receive in IRQs (as begun with the new usbh-irq branch) then the MX_USB_Host_Process function probably doesn’t have to do anything very time critical. I still haven’t quite got my head around how the library works though. It seems incredibly convoluted, with different attempts at abstraction competing with each other (callbacks, weak declarations, function pointers…). Just like most ST code, in other words!
Yeah, I know that cooperative scheduling is used, I’d expect this thread to run when audio task is idle.
Btw, I’m not sure that preemptive MT would make that much problems for performance - it still respects OS task priorities. And IIRC, in FreeRTOS even preemption for the same priority tasks will only happen if you enable time slicing.
My main point was that we’re running owl_loop with 20ms on devices with screen, this looks like a potential source of latency for everything that happens in loop() function that calls it. And it would only be effecting some devices, which can make harder tracking this sort of issues. I’m not sure if among MIDI transmit, USB host processing and digitalbus IO nothing is sensitive to 20ms delay - there are buffers involved, it may be possible to overflow them. It probably makes more sense just to test this and make PR, the change would be fairly trivial, so I’ll do it later.
Update on the repo: I’ve merged the feature/usbh-irq PR and library revamp into develop branch. All systems go!
And btw @mcc, if you’ve got a working programmer setup and can connect with openocd, then you don’t have to worry about which bootloader is installed since you can always reflash it. Just build from develop and enjoy!
Returning to CI topic, here’s example of it used for Daisy. Basically, they check code style conformance, build docs and code. Results are visible in github’s branch/PR pages and in Travis page
Travis is free for open source software. So it would be a good candidate to try once develop branch can run “make all” without errors.
I’m merging the PR now!
I’ve updated the Makefiles so that all object files are local to their subproject build directories, which means there should be no build conflicts between projects.
Check out OpenWare develop and do a git submodule update and you should be good to go with a big, fat, top level make all
I’m merging the PR now!
I held up trying to get the build working once this PR opened, so now that it is merged I will try rebuilding bootloader and see (1) does the new bootloader work 
and (2) does the usb irq patch solve the midi drop problem. Probably the local build PR will simplify my tutorial also. Thanks
And btw @mcc, if you’ve got a working programmer setup and can connect with openocd, then you don’t have to worry about which bootloader is installed since you can always reflash it.
Well, my “working programmer setup” entails disassembling the Magus. So I’m hoping I won’t have to do it more than once
That’s overly optimistic. You do it once and you get addicted to debugging. Before you know, you can’t live without those interrupts, stack overflows and hard faults.
I thought “I’ll do it once and just stop” too, but ended up porting firmware to a device where it was not intended to run. Don’t repeat my mistakes, don’t connect the programmer!
Both midiboot/magus and magus built on the first try. My tutorial instructions are a LOT simpler now. Will try to learn openocd tomorrow.
EDIT: I had a post here asking about an OpenOCD error but it turned out to be a known problem with Windows Services for Linux.
Btw, I think this config file name indicates that you’re using old openocd version. It looks like they’ve moved from multiple config files for different versions of St-Link to a single stlink.cfg.
I’m using OpenOCD 10.0.0. This is the newest official release on the website. Is there a newer version?
Looks like that was released in January 2017 and there have been no releases since then. Mine is built from development version source, but I guess last stable release could be good enough - unless there are some unreleased fixes specifically for Windows.
Understood, thanks.
I now have OpenOCD for Windows working and I can successfully run make info on MidiBoot. I’m not sure what steps to use to install MidiBoot. The Makefile contains commands for info, unlock, erase, erase-boot, erase-storage, dump, upload, and lock. I tried “upload” and I got:
$ (cd MidiBoot && make upload)
/mnt/c/Users/Andi/work/gh/OpenWare/openocd/bin-x64/openocd.exe -s C:/Users/Andi/work/gh/OpenWare/openocd/scripts -f C:/Users/Andi/work/gh/OpenWare/Hardware/openocd.cfg -c "program Build/MidiBoot.elf verify reset exit"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SW
D
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.240238
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 2000 kHz
Error: timed out while waiting for target halted
TARGET: stm32f4x.cpu - Not halted
in procedure 'program'
in procedure 'reset' called at file "embedded:startup.tcl", line 500
in procedure 'ocd_bouncer'
I thought, maybe I need to run “unlock” first? That didn’t run either:
$ (cd MidiBoot && make unlock)
/mnt/c/Users/Andi/work/gh/OpenWare/openocd/bin-x64/openocd.exe -s C:/Users/Andi/work/gh/OpenWare/openocd/scripts -f C:/Users/Andi/work/gh/OpenWare/Hardware/openocd.cfg -c "init" -c "reset halt" -c "stm32f4x unlock 0" -c "exit"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SW
D
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.237062
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 2000 kHz
Error: timed out while waiting for target halted
TARGET: stm32f4x.cpu - Not halted
in procedure 'reset'
in procedure 'ocd_bouncer'
How should I proceed? Also, I assume make upload is installing just the MidiBoot elf; is there a command to install the Magus elf I can run after that?
Posted this link already here - Make Owl Great Again! - #17 by mars
The bootloader gets write-protected as part of upload process to prevent accidental writes.
Also, once you get openocd to work, this may be good time to figure out how to use debugger. I can make a short guide for vscode if that would help.
Thanks… however reading that link it seems to be the instruction is
make PLATFORM=Magus clean all unlock flash
Unlock gives me only the “timed out while waiting for target halted” (same if I try $OPENOCD -c "init" -c "reset halt" -c "exit" as the docs seem to suggest).
Here is something interesting: If I try $OPENOCD -c "init" -c "halt" -c "exit", it appears to succeed. It says “target halted due to debug-request, current mode: Thread”. Is it possible it’s failing to halt because it’s already halted??
Or, do you suppose my pins might be plugged in wrong? I think it must be at least receiving power because the chip is warm when I touch it.
this may be good time to figure out how to use debugger. I can make a short guide for vscode if that would help.
Well, if a vscode or command line tutorial existed I’d definitely try it out before reassembling the unit! And I’d definitely link it in the tutorial I myself am writing. However remember, because I had to disassemble the unit to attach the debugger, the white board is not plugged into the IO board or any of the other hardware. Is there anything useful you can do with the debugger when the white board is just sitting alone on a tabletop?
If I change reset halt to halt in the Makefile, it seems to work. Hm. Experimenting…