2020-03-14 08:13 AM
Hi, first of, I am not sure if this is the right forum to ask this type of question. Feel free to redirect me if needed.
So I am using STM32F446RE development board for an electric guitar looping pedal project. For my application, I require some amount of external memory to be added to save a couple seconds of guitar signal, to then be able to play it back in a loop. This raises the question: What would be the best type of memory to use for this application?
I am sampling at 48Khz/12bit and ideally would like to save at least 20 secs of music, which would require at least 1.5 to 2Mbyte of external memory.
Note that altough I understand the principles of SPI communication, I have never used it in a project, which is why I ask for your help on this one.
So I started looking for SPI/QSPI, DIP8 or SIOC8 memory IC on Digikey, and it seems my best two options are the following:
What would be the most efficient for my application? I would ideally like to be able to overwrite data written in memory (to, for example, add two signals together), so using Flash memory might cause some headaches when dealing with erasing and rewriting data (might also be too time demanding, depending on the chip).
On the other hand, since the SRAM module do not feature enough memory in a single IC, I would need to interface with multiple, I estimate at least 4 slaves, which I think shouldn't be too complicated with a correct managing of ChipSelects. How hard is that to manage? Do you have any example code to guide me through this?
I would really appreciate your insight on my issue,
Thank you very much
2020-03-16 04:02 PM
Would it still be feasible with the F429? This is a school project that is supposed to be a "prototype"/proof of concept, so I am not as worried by audio quality (I do still need a reasonable amount of clarity in the audio). At the moment, when using the F446RE, I am hearing a slight hissing, which is acceptable.
Looking into the F746G Disco, it really does seem to offer more performant audio features. I notice it is running a Cortex-M7 processor, is that a big change from M4 in terms of programming complexity? I'm guessing it should be roughly the same, and I will be able to disable all the unused features such as RTOS, Ethernet, etc., directly from Cube MX as well?
Also, I am a uncertain as to how my code would differ, as I am currently using both ADC and DAC embedded inside the F446, while the F746 Disco features an audio codec. I have not been able to find any example online regarding the usage this F746 board in audio signal processing. Will I still be able to
Also, I notice that contrary to other board I have used, this one does not feature some Extension headers to access the GPIOs, as all of them are used by on board features. There are however some Arduino Shield headers: Can I use these to program External interrupts to detect the press of a button, considering I will not be using Arduino? I would only need to interface with 2 to 6 buttons to add functionnalities to my pedal.
Sorry I am asking so many questions, I did my best to look into how I would be able to port my code from F446 to F746, but have not found any example related to audio DSP. I would really appreciate if you could point me to some resource that could guide me through programming.
Thanks,
2020-03-17 03:39 AM
> when using the F446RE, I am hearing a slight hissing, which is acceptable.
I'm afraid it will be worse when you start combining the signal with itself.
> it is running a Cortex-M7 processor, is that a big change from M4 in terms of programming complexity?
The only difference you should be concerned with is the L1 cache. See the discussion here.
> I will be able to disable all the unused features such as RTOS, Ethernet, etc., directly from Cube MX as well?
No peripheral is enabled unless your code explicitly enables it. Save yourself the headache and don't let a bug infested tool write the code for you. Yes, theoretically you should be able to convince CubeMX not to configure these peripherals, but I've seen too many strange things in code generated by CubeMX.
> I have not been able to find any example online regarding the usage this F746 board in audio signal processing.
There should be some in the apllication examples for the board, e.g. in STM32Cube/Repository/STM32Cube_FW_F7_V1.15.0/Projects/STM32746G-Discovery/Applications/Audio
> will it be seen in an unintelligible compressed format?
Maybe yes, but conversion functions are provided in a library. See the readme and the source.
> There are however some Arduino Shield headers
They are just simple pin headers, arranged that way to be able to connect arduino shields without much fuss. You can use the pins any way you like.
2020-03-17 02:46 PM
Sorry I thought I had answered you. SDRAM does seem to be the best type of memory. However, I wasn't able to find it in large enough quantity in a DIP8/SOP8 package.
2020-03-24 12:10 PM
Hi berendi,
Sorry for taking so long to answer, I had to put this project on hold for a minute. I have decided to look into using an SDIO 4bit approach instead of buying a whole other devboard after all. However, when trying to compile a blank project with only SDIO 4bit and FatFS enabled, I keep getting Keil IDE errors about multiple definitions of functions that were created by CubeMX.
This got me thinking back to your previous statement: "Save yourself the headache and don't let a bug infested tool write the code for you. Yes, theoretically you should be able to convince CubeMX not to configure these peripherals, but I've seen too many strange things in code generated by CubeMX."
And I'm starting to understand where you are comming from. So then what is the ideal way of generating code, if it is not by using the CubeMX tool?
And how would I go about adding functionnalities such as ADC/DAC, DMA, SDIO, etc? Could you point me to some resources?
2020-03-25 02:03 AM
If there is no tool that can generate code that works for you, then I'm afraid that you should do as everyone else in the history of computing, i.e. write it yourself.
You can start from the examples in STM32Cube/Repository/STM32Cube_FW_F4_V1.25.0/Projects.
Note that SD cards have more or less unpredictable latency when writing, it would be quite tricky to get it right in realtime. I have no idea how I would go about it, but video cameras manage it somehow, so it's not impossible.