This seems to be some problem due to Windows not finding ~/2020-q2-update/bin/arm-none-eabi-g++ file when the Makefile is executed. Might be something wrong with PATH variable or the actual path value (on Linux it uses gcc-arm-none-eabi-9-2020-q2-update rather than just 2020-q2-update)
1 Like
Yeah that helped, the file path was off. Now I just need to wrestle with FirmwareSender for a bit…
EDIT: I think I need to take a break from this. Can’t make heads or tails of FirmwareSender and I’m just going around in circles. Maybe I’ll come back to this another time. Thank you for guiding me this far…
There’s a binary release of older version of FirmwareSender for windows, it should be still usable for converting firmware .bin to sysex format - Release v0.1 · pingdynasty/FirmwareSender · GitHub
EDIT: I think my machine magically recognized the file I added to Path and now it spits out a .syx file. Yay! Now I’m just getting an error for crc32, which I understand may be a linux thing and may not be something that can be executed on Windows. For what I understand, it checks for errors? Maybe I’m ok without it?
That’s the file I had been using. This how clueless I am: I don’t know where to put the .exe to get the compiler to find it. I’ve tried adding it as an environment variable and I’ve been putting it in all different folders hoping that it gets found but I keep getting the same error saying that it can’t be found.
Success!!
It looks like I had everything I needed already, I just had them in the wrong place. I had found that thread you linked previously, but didn’t quite understand it, but eventually used it to track down the mingw32 version of crc32.exe. I placed that in the same directory as FirmwareSender.exe (which was already part of PATH in my environment variables) and it compiled no problem.
From there it was about 10 minutes of updating the 1309.h to include the charge pump command (0x8d, 0x14) that you suggested (though I put it on line 59 since that seemed more closer to what was in the libDaisy file) and uploaded it to my Daisy.
And just like that, my screen works!!!
Thank you for sticking with me, I know it’s not easy to guide someone who is completely new with something like this. It is truly greatly appreciated. What a relief! If it helps, I’ll try to document later what I did with a little more detail in case its any help to others.
Thanks again!
1 Like
Congrats! Happy to see that my guess was correct.
Yeah so the crc32 command was used from external binary in that old version, I think that newer one includes checksum calculation in its code (except that there’s no binary for Windows ATM).
Since you say it works, I will confirm that it doesn’t create problems on Daisy Patch (probably would just get ignored by display controller) and add those commands to OWLsy in next release, so you won’t need a custom firmware on you device. Btw, I would be curious to see what state is it in - just a spaghetti on top of breadboard or did you make a proper PCB, etc?
Also, if you’re not using the second codec (apparently it’s become unobtainable a while ago), you could make a custom project for your hardware and reconfigure those 5 free pins (used by SAI2 on pinout charts) for something else. 3 of them can be used as analog inputs or there’s one full-duplex UART and 2 other UARTs with TX/RX only. Obviously usable as plain GPIOs for gate inputs/outputs or buttons.
Thanks for making OWLsy, having lots of fun with it!
I have a quick question: How can I restore the original slate of the Daisy Seed? Is this possible via USB and e.g. one of the web programmers (i.e., OpenWareLaboratory, Daisy Web Programmer) or would I require a dedicated hardware programmer such as the STLINK Mini to do so?
You can flash any Daisy patch in DFU mode or from Electro-Smith web flasher to overwrite bootloader. The firmware and patches are stored on QSPI chip entirely, only bootloader is on the internal flash. You can always restore OWLsy bootloader later if you want to return to using it.
1 Like
Great, thanks a lot for the explanation!
It’s in a pretty messy state, though that describes about 50% of my rack. I’m using a left over pcb panel from another project. Maybe I’ll make a custom panel at some point but I don’t plan on making a more robust pcb for the components. I haven’t implemented cv out or gates in and out. For now I’m content just having audio in and out for fx. Might add more in the future.
1 Like
Quit messy indeed! But at least the front panel is not cardboard.
So about unused codec, available pins are those marked as SAI2 on pinout (pins 31-35). If you’re still not sure about IO configuration that you want to use, I would suggest at least adding 2 push buttons that would let you set inputs for gates manually and also second gate output. This is something that I miss the most on Patch.
It’s probably better to use pins other than 31/32 for gate/buttons as those 2 pins have a nice UART or can be used for reading ADC values in case if you’ll ever need it.
Messy is just how I do it I guess lol. Anyway thank you for the suggestions about unused pins. I’m going to use the module for a while and see if any specific need arise, but I like the push button idea.
I’ll leave you with one last question. I was considering putting another of these together in the future, but the other Seed I have is the new version with the new WM8731 codec. Does Owsly support this coded currently? I saw that there are files in the hardware (?) folder but couldn’t tell if it was active etc. Just curious for future reference.
It almost does.
That codec is not particularly new - that’s what was used by OWL1 back in the day (8+ years ago). So there already was a driver in place, but in F4 MCU familiy a different peripheral was used for audio (I2S that got replaced by more generic SAI). I have a version of that driver for SAI too that runs on something that is very similar to Daisy Seed, but it’s not in OWLsy codebase yet.
It would be easy to port, but I don’t have a Daisy Seed with this codec to test it myself yet.
1 Like
Cool, not sure if this is helpful or not, but let me know if you want me to test it on my hardware
@antisvin hi, me again 
I saw that you posted an update. I just wanted to ask one thing then I won’t bug you anymore. I haven’t had a chance to test my wm8731 daisy with it yet, but when I do, do I need to change anything to the code to make it work (I noticed that a USE_WM8731 line was commented out?) to make it work or should it work as is? Thank you!!
Bugging is fine, that’s what this topic is for.
Yes, you could try building with USE_WM8731 instead of USE_AK4556. And do the same with their files in Makefile. There’s a good chance that something else is still missing, but you could give it a try.
At least SSD1306 should work now.
1 Like
Thanks! I’ll give it a try a little later and report back
Ok I tried using the new codec and sadly it didn’t seem to work (the screen worked fine though!). Here are the changes I made:
In hardware.h:
-comment out line 86
-include line 87 and line 88
In Makefile:
-Comment out line 16
-include line 38
Everything boots fine, I’m able to load patches from Rebeltech, but no audio out. Additionally, the knobs do not seem to have any effect, I’m not able to change any parameters, so I get the impression that something else beside the audio is not working correctly. If you’d like to have me try any other fixes, I’d be happy to, though I’m sure these types of fixes are easier when you have the hardware in front of you.
Thanks for giving it a try. I’ve noticed that it was configured for mono audio as that’s how it was used on another device. Just fixed it to use stereo. Besides that, you must comment out #define DUAL_CODEC in device.h in case if that wasn’t the case yet. If neither of the above helps, we’ll have to wait for a few months till I can troubleshoot this on device.