I’m a veteran DSP programmer and have recently created an ecosystem from scratch for Cortex M7, running on the Daisy Pod for the moment. I’ve finished created and algorithm that I’d like to deploy, and PolyEnd Endless seems like a good tool for the job. Two questions. Is either the hardware or the API published? I currently use the Eclipse based STM32CubeIDE for development and Segger’s RTT for setting parameters, verification, etc. I works great. I’d just like to hook into some packaged HW like the PolyEnd. Second question is the website says “preorder now”. What does that mean, that units are not yet available?
If this is not the right forum, can I get some information on where to make this inquiry?
As you are a dev. I think the best thing to know for you would be that the SDK is just an abstraction layer on top of the firmware/hardware of the device.
It exposes the most important parts (main loop, buffer and user input control) but doesn‘t offer full/indepth control over the hardware, unless you go all the way in and write your own firmware from scratch of course
@Sandroid Exciting that there is an SDK. This looks like a good platform to port my work on DaisyPod to. I get all the physical stuff I’d have to build myself. Excellent! I do have some questions. I’ve read through the SDK. It looks like it does all I need, but …
How do I set the audio buffer size to trade latency against efficiency?
How do I know the memory map of the processor to choose memory allocation for the proper access speed for the various data? Do I not need to worry about this because the cache works so well? The example says to use static allocation - correct - but this question follows.
Is there an SWD port so I can load and debug via my debug probe rather than blindly loading a binary via the flasher and not know why something doesn’t work? Or is my only choice to make sure that is works on Daisy each time and then assume it will work on PolyEnd. That’s probably workable but not ideal.
Suppose I want to implement a software timer for my own purposes? Can I hook into the background process? That seems a missing aspect of the SDK - a background callback. Use the LED polling for this? If so, I need to know the period of the LED callback.
If these questions are too detailed, who do I ask?
kWorkingBufferSize is what you want to change. In the example from the Repo it‘s just set to the maximal avaiable size / length
I’m not sure honestly. There isn‘t anything exposed. But maybe there is a port on the pcb board directly.
I can try and source answers for you for all the others questions directly from the developers. It might take a couple days but i‘ll update you once i know more.
I‘ve personally just been compiling down to binary and testing from there. But i also haven‘t tried to build anything overly complex yet (Gated Reverb and some Audio degradation stuff).
That’s doesn’t sound right. The comments mention that the working buffer is in slow memory. Why would the primary codec/DMA buffers be in slow memory? Maybe you didn’t understand the question
If you can get more info, that would be wonderful. And one more question. I notice that there are gestures for footswitch press and footswitch hold, but not footswitch release. Why? This seems like an obvious want if you want an effect that is only active when the footswitch is depressed. Again not a show stopper, but a pretty obvious want.
You are right i misread what you were asking for. So let’s do this again
You don’t. The buffer size is a constant 128 samples per channel.
Your patch/compiled code is placed in external ram so there’s no need to worry about it - but it goes through the cache and you can keep that in mind when optimizing the code.
As i assumed: the debug port is only on the board (and we think it is not soldered in the production version) - not led out.
There was a time when it was considered to expose a timer, they then decided to keep it simple for now and not expose it. The LED refreshes with a fixed cycle when the value from the patch changes. (it’s 20ms).
