We’ve just made a new release for libDaisy, and it’s a pretty big one!
Aside from a few minor things that will only affect some projects, there are no serious breaking changes in this update, but we are brining in a lot of new (and highly requested features).
New features include:
Support for USB MIDI
FatFS Support for USB Drives
Multi-volume support for FatFS (for dual SD card and USB drive access)
A driver for the MAX11300 ADC/DAC/GPIO device has been added (pretty cool Eurorack-friendly IC that a few people have already thrown on some hardware).
Added new constants for the Daisy Seed pinout in the daisy::seed namespace. These constants match the Arduino pin names, and will be clearly laid out in a new version of the pinout diagram that’ll be published very soon.
Added new C++ API for GPIO and Pin types that is much more intuitive to initialize and use.
All old GPIO code is still valid for now, but will be removed in a future update.
Initial support for the upcoming Daisy Bootloader has been added. More info on this soon
In addition, we finally fixed the bug with the audio that would occasionally cause channels to be reversed!
The only real breaking change involved is the changes to the FatFS Initialization since it is now possible to work with SD card or USB Drives. An example of how to migrate can be seen here:
// new object for managing FATFS interface
FatFSInterface fsi;
int main(void) {
// Daisy, SDMMC, etc. initialization is unchanged
. . .
// before:
dsy_fatfs_init();
// now:
fsi.Init(FatFSInterface::Config::MEDIA_SD);
// and instead of the global FATFS object you can now:
FATFS& fs = fsi.GetSDFileSystem();
// and instead of the global SDPath object you can now:
const char* rootpath = fsi.GetSDPath();
. . .
// and then file system works as usual now
f_mount(&fs, rootpath, 1);
}
Features such as USB drive access, and USB MIDI will be coming to oopsy, etc. early next year.
We will also be going through the doxygen documentation to try to make that easier to navigate, and more useful along with creating more guides to help people work with the entire ecosystem of hardware and software.
Let us know if you have any questions, requests, and as always: Happy hacking!
So I’ve got SD card working on Daisy with OWL recently and I’ve had a look at new code in libDaisy for unified FatFS volumes. I’m a bit surprised that the new FatFS drivers use a scratchbuffer for USB MSC backend code, but not for SD.
The path, and FATFS objects can be acquired from the new FatFSInteface objects, and any FIL object(s) can be placed in AXI SRAM (or any other memory with USB).
That’s required not just for FIL instances, but also:
WaveTableLoader
WavWriter
anything else in user code used as destination for f_read or source for f_write
Second correction is that USB DMA won’t work with ITCM/DTCM and it’s already possible to use DTCM with .dtcmram_bss section in libDaisy link script. So almost any memory area but this one is available for USB. I imagine ITCM would also be exposed eventually and would become the second exception. This was mentioned in PR notes, but not added to changelog somehow.
Yeah, this is pretty much just the diskio generated by cube with some cache-maintenance added in.
The USB scratch buffer is only used for unaligned data, but it is interesting that the SD diskio doesn’t do something similar.
Also, good point about the other objects that contain FILs. That’s not new, but is not likely documented anywhere. I’ve made a note to add some notes to each of those classes, and possibly write up a little FatFS guide to go over the memory peculiarities of the different media as well.
Yes! I’ve been meaning to fix the pdf generation for a while, but there was some weird issue with the generator we were using at the time when we switched from Travis CI to Github Actions.
Regarding Daisy Seed availability. They will be back in stock this month! We’ll be making a forum post as soon as we have them ready to go, and back on the site!
@shensley Actually it does have it and I think I understand what’s going on. You’ve initially used non-DMA version that doesn’t need such workaround, obviously. But it’s present in their DMA-enabled template. So you can just update your version to add missing functionality and then you can get rid of redundant buffers for all WAV files readers/writers.
Note that the code in question is used to avoid unaligned access, but naturally it should also be checking that destination is in D1.
Oh nice! I didn’t check to see if they’d updated that lately or not.
When we made the original files, the “DMA template” output didn’t have the scratch buffer or the cache maintenance.
I’ve noticed a few other things that have changed about the generated output that could be positive changes to how some of libDaisy was set up initially (like local clock tree configuration for each peripheral instead of having a single global clock config, among other things).
Also, just a heads up to anyone checking it out so far. We did find a bug with the latest release:
Trying to use FatFS and the Logger (or USB MIDI) in the same project will result in a linker error (redefinition of the USB HS IRQHandlers).
I’ve already merged the fix to master, and if we don’t find any other issues in the next day or so we’ll make a v3.0.1 release just for that.
Can you give us some sneak-peaks into how it is going with the “upcoming Daisy Bootloader” (assuming this is something to get us around the 128k-program-limit)?
@Ragorh there is a little bit of a discussion on the existing functionality on this thread, and we should have a brief usage guide added to the libDaisy docs within a week or so.
Given that we’re still in the early process of working with the bootloader, the process itself is still likely to change a little to make it a bit simpler to work with, but once the guide is published, we’ll keep it up to date as anything changes.
