Pitch shift problems

@shensley Thank you for reply. Configuration was ok, except for Optimize. Even after changing to -O3 it didn’t work when using the code above. Serial console is still blank. But there is some issue indeed: in Device Manager the COM3 where Daisy is connected, it shows “Standard Serial over Bluetooth link”. I know that Daisy is on COM3 because the Blink example works fine. Please, how I can correct that?

By the way, Device Manager shows COM3 and COM4 with the same text. I tried uploading the blink code in these two ports and it worked. Seems weird…

When the device is in bootloader mode it doesn’t use the COM port configuration to upload, the STM32CubeProg looks for a DFU device, so the COM3 (and COM4) you have may be another device built into your PC. While in bootloader mode, the Daisy appears under “Unversal Serial Bus Devices” as “DFU in FS Mode”

image

Once one of the serial programs is running on the Daisy Seed, it should show up in the COM Ports section of the Daisy as “STM32 Virtual ComPort”. In my case this is COM73.

You should be able to see that appear and disappear as you plug and unplug the daisy.

image

Once you’re able to identify the COM port you can set that in Arduino to match under the “Port” settings, and the serial monitor should work.

@shensley thank you again. Yes, in Universal Serial Bus Devices I have DFU in FS Mode when in bootloader mode. However, the COM port isn’t being updated with STMicroelectronics… when DS is plug into USB.

With the Daisy Seed plugged in, and running the Serial Program, can you see it inside of Zadig? You may just need to set the driver for it, though I haven’t had to change mine.

Right now, with the sketch I sent you mine shows up there as DAISY_SEED CDC in FS Mode, and has the usbser(v1.0.0.0) driver, though I’m fairly certain I’ve tested it with libusb and winUSB under the same configuration.

Here’s how it looks in Zadig on my machine:
image

I’ve just followed the instructions on git page “Using Zadig to Reset USB Driver (Windows Only)”. Here is mine:dseed. Still not working…

and by the way, I’ve tried to uninstall the COM3 and COM4 ports (both, driver and device) from Windows system, but it comes back to “Standard Serial over Bluetooth link (COM3)” whenever DS is connected to USB port.

@shensley Solved: It finally worked when I changed USB driver on Zadig to USB Serial (CDC). Then a new COM port was created on Device Manager with the correct setting: DAISY_SEED CDC in FS Mode.
Anyway, it should be advised on Git/Zadig configuration that some drivers may not work as expected, and one should try others.
Thank you.

1 Like

andrewikenberry
19d
@TGargasz Arduino SDRAM support and flushing out the SPI / I2C libDaisy functionality are the very next things on our to do list.
They should be getting handled within the next week or two.

@andrewikenberry Any word on progress?

@TGargasz yes, we are currently working on Arduino SDRAM support and should have it live by end of this week!

We’ll be jumping on the SPI / I2C next week.

@andrewikenberry Fabulous! The timing is spot on my anticipated schedule! My trial version of VisualGDB has expired and being on a disabled income I don’t have a Benjamin to toss at it until I fill the penny jar. I have quickly grown comfortable with Visual Studio 2019 Community Version with the VM Ware extension for Arduino. The VM Ware extension is only $12/yr which is palatable. I know about the free debugger for Visual Code but I’m sour on VC because I could never get Intellisense or code completion to work properly in any environment that I tried it in.

@TGargasz v1.2.0 of DaisyDuino has just been pushed, and adds support for SDRAM.

Not sure how long it usually takes before Arduino Library Manager picks it up, but I think its relatively quick.

To use the SDRAM you can declare any type as a global variable using the DSY_SDRAM_BSS attribute.

For example:

// This creates 1MB of chars
char DSY_SDRAM_BSS my_big_buffer[1024*1024];

void setup() {}

void loop() {}
5 Likes

@andrewikenberry, @shensley WooHoo! Thanks a million times!

1 Like

So, getting back to my original problem, how do I use this?
Can I just place all the variables I use in my code in the SDRAM by using the DSY_SDRAM_BSS attribute?

As long as they’re global variables, yes.

I’d suggest you try to keep most variables inside the H750. Accessing the SDRAM will use more current and generate more noise that could get on the audio.

@MikeDB have you been noticing this in practice?

I do agree that most variables should be left on the internal SRAM, and the external SDRAM should only be used as necessary for large chunks of memory that don’t fit in the internal RAM sections.

Personally, I haven’t done a lot of detailed profiling to compare noise/distortion from similar code running on each memory yet. Theoretically, what you mentioned about increased noise due to current, etc. is plausible, but in my experience I’ve mostly aimed to keep as many (non-sequential access) variables/arrays on the internal SRAM for speed of access rather than negating additional noise. I have done a few projects that use a substantial amount of the SDRAM without a noticeable increase in the noise floor (access is mostly sequential, with a few jumps here and there, for what its worth). However, I am very curious if you have been experiencing additional noise from SDRAM usage.

I haven’t tried it on the Daisy yet, but I have my own board with a Raspberry Pi linked to a STM32H750, PCM5102 DAC and an external memory and the STM32 seems to generate far more power and ground noise accessing external memory than it does for example driving the SAI and SPI lines. Of course the Daisy layout is different so it may not be an issue, but I was highlighting it could be an issue for people to look out for. I was about to respin the board with just the Pi4 and a Daisy but then they announced the CM4 compute module so doing a quick redesign.