With all of the various features, integrations, and various bug fixes we have on our plates we figured that it was time to put together a roadmap for the development of Daisy.
This felt necessary for two main reasons.
First, we have promised many features, and are working very hard to make them happen, but not everything can happen at once. So we want to have a transparent platform where you’re able to see what we’re working on, and where features are in the queue. This will also be flexible based on all of your feedback.
Second, we have had a few people express interest in helping out, or contributing in various ways. Without something like this in place, it has been really difficult to encourage contributions. So we’re hoping that by having this we’ll open the door to more discussion, feedback, and contribution.
The main roadmap sections of the trello board are the various timelines:
Planted - These are planned features that do not have an active timeline.
Germinating - These are features/fixes that are queued up, but are generally about a month or so away from being worked on.
Blooming - These are things that have an active timeline with an estimated date of completion. These have been measured as the most critical features/fixes and will have most of our attention.
As things from the Blooming column are completed we’ll shuffle things over in the other columns.
If you’re in a web browser, clicking any of the colored labels will indicate the text that goes with it, and there is a card in the Resources list that describes them as well.
If you have any opinions, feedback, or other feature requests that are missing from the roadmap feel free to comment back here and let us know!
I think that one more feature that belongs there is support for MCU utilization measurement. It was asked about on forum before and can be done easily with DWT->CYCCNT register.
Ah, yes. I believe this has been mentioned. I’ve just added it to the board in the Planted column. Though, since a simple implementation looks like it could be done fairly quickly. It may get moved up, and handled sooner.
Yes, counting is as trivial as it sounds. The register can be reset before audio CB, read after it’s finished and scaled based on MCU frequency, SR and audio buffer size. I.e. 400 MHz / 48kHz SR = 8333.(3) cycles/sample, so you’ll just need to divide CYCCNT by this value to get fraction of CPU time used.
A few extra calls must be made in advance to use this, something like this should work:
Am I missing an existing debug logging functionality?
I had to do my own simple class based on the USB CDC example, but maybe that’s something that belongs to DaisySeed class?
Something that is really straightforward:
seed.StartLog(UsbHandle::FS_INTERNAL, false);
seed.PrintF(“Hello world %d\n”, 123);
the boolean parameter enables halting the execution until a key is pressed on a PC, which helps a lot during startup code debugging.
This is definitely a good idea for an addition! I’ll add it to the list, and create a github issue for this feature!
Also, worth mentioning with JTAG debugging and semi-hosting, it’s possible to simply use printf(), but having some built-in USB debugging would be valuable.
If its a generic “Logger” class maybe it can also use UART as well.
Great, I’ll then mature my implementation a bit and publish it.
What is the general approach here - should I try to assemble requirements first and get them agreed upon or should I just go ahead and create a pull request and then we simply work from there?
I just added a github issue to libdaisy for this feature. Perhaps you can lay out any requirements, etc. you already have. Anyone else, including myself, can weigh in. This can also be done in a PR, but the issue could help sort out any decisions before you start reworking any code you already have.
And absolutely, that would be wonderful! I was planning on working on convolution at some point, but I wasn’t going to have a chance to get to it for quite a while.
There are a few places in the roadmap that refer to PD and specific enhancements but I don’t see anything about PD itself-generally. I’m assuming that PD is pure data. Is there someplace that describes how pure data is-will be supported and if not could you say something about it? I’ve been thinking about what it means and reading Miller Puckett’s paper ‘Max at 17’. I see a lot of questions relating to where PD would run and how multiple processors would be utilized. I see that there is a ‘card’ called pd2dsy in various logs, but I have not been able to view the card, perhaps because I have not used Trello before this.
