Hi David, first i want to thank you for such great work on such amazing machine like pico, i would like to ask you for a video to explain how to use c language on pico without using the c/c++ sdk , thanks again.
You're welcome. I'm not a c expert; but I think you can use GCC to create a C program without using the C/C++ SDK. However, If you want to use any other RP2040 features like UARTs, PIO, GPIO, DMA, etc, you will have to include a number of libraries that are included in the SDK. I would include the "reset" routines I've developed in ASM to initialize the RP2040. Try using the steps I outlined in my bare metal videos , but use the GCC to create the .S file from the c file. I've got a lot to discover in assembly, so it might be some time until I get to a bare metal C program. Thanks for watching!
That would be interesting. I've done several AWG videos as well as MIDI. I've thought about making a little monophonic synthesizer. I'll have to get a lot smarter on how pitch shifting is done; I've used it with limited success with Audacity, but that's on a batch basis. If the math skills of the RP2040 aren't up to the task, maybe a RasPi 5. Thanks for the idea.
Very interesting. I wonder if it would be faster to execute the code that changes the CPU clock speed before coping everything to SRAM and executing there. Is the copy effected by the CPU clock speed? If not, then it would not matter but if it is, it could have a significant difference when your code gets really large and speed up the startup time. Also, given that a lot of the initialization code only gets executed once and is probably under 16Kb, what is the performance difference between executing the initialization before the copy and not coping that initialization code vs coping the code and executing the initialization from SRAM? Maybe the difference is only a few milliseconds but would be interesting to know if boot up time was critical.
You are correct; it would be MUCH faster to change the clock speed before copying. I did this to see if I could make it happen by using a program I already knew that worked. Now that I've worked out the bugs (and I had a lot of them), I would keep the reset program in XIP flash and move the "real" program at high speed into SRAM. I think the speed difference is in the order of seconds, not milliseconds since the clock speed coming out of reset is V-E-R-Y slow. Thanks for the excellent insight!
I'd love to have serial terminal (talking through USB) send a wave file sample to be copied into Sram for playback to an R2R ladder ADC at variable speeds. For a super cheap and simple ARB generator, does this sound feasible?
Yes it can, in this case I used the values from the linker script to calculate the size to copy. Regarding word alignment; I believe you are right; I'll have to check into that. I know that you can have word align directives in the linker script between sections; however my data was not in a separate section for this run. A lot of the tutorials showed using a NOP as a pad character; it would be really handy if I didn't have to do that. Thanks for the suggestion.
Thanks very interesting.
Glad you enjoyed it
Hi David, first i want to thank you for such great work on such amazing machine like pico, i would like to ask you for a video to explain how to use c language on pico without using the c/c++ sdk , thanks again.
You're welcome. I'm not a c expert; but I think you can use GCC to create a C program without using the C/C++ SDK. However, If you want to use any other RP2040 features like UARTs, PIO, GPIO, DMA, etc, you will have to include a number of libraries that are included in the SDK. I would include the "reset" routines I've developed in ASM to initialize the RP2040. Try using the steps I outlined in my bare metal videos , but use the GCC to create the .S file from the c file. I've got a lot to discover in assembly, so it might be some time until I get to a bare metal C program. Thanks for watching!
thanks, @@LifewithDavid1
What about some audio effects? Maybe real-time pitch shifting? What about a real-time Pi Pico version of AutoTune? Or a nice reverb?
That would be interesting. I've done several AWG videos as well as MIDI. I've thought about making a little monophonic synthesizer. I'll have to get a lot smarter on how pitch shifting is done; I've used it with limited success with Audacity, but that's on a batch basis. If the math skills of the RP2040 aren't up to the task, maybe a RasPi 5. Thanks for the idea.
Very interesting. I wonder if it would be faster to execute the code that changes the CPU clock speed before coping everything to SRAM and executing there. Is the copy effected by the CPU clock speed? If not, then it would not matter but if it is, it could have a significant difference when your code gets really large and speed up the startup time. Also, given that a lot of the initialization code only gets executed once and is probably under 16Kb, what is the performance difference between executing the initialization before the copy and not coping that initialization code vs coping the code and executing the initialization from SRAM? Maybe the difference is only a few milliseconds but would be interesting to know if boot up time was critical.
You are correct; it would be MUCH faster to change the clock speed before copying. I did this to see if I could make it happen by using a program I already knew that worked. Now that I've worked out the bugs (and I had a lot of them), I would keep the reset program in XIP flash and move the "real" program at high speed into SRAM. I think the speed difference is in the order of seconds, not milliseconds since the clock speed coming out of reset is V-E-R-Y slow. Thanks for the excellent insight!
I'd love to have serial terminal (talking through USB) send a wave file sample to be copied into Sram for playback to an R2R ladder ADC at variable speeds. For a super cheap and simple ARB generator, does this sound feasible?
Just so happens that I did 3 videos on AWGs. This is the first one: ua-cam.com/video/_lZ1Pw6WAqI/v-deo.html
See Episodes 15 and 16 also. Good luck
Can the assembler calculate the size to copy? Also, is there a word align directive, so you don't need to manually add the NOP?
Yes it can, in this case I used the values from the linker script to calculate the size to copy. Regarding word alignment; I believe you are right; I'll have to check into that. I know that you can have word align directives in the linker script between sections; however my data was not in a separate section for this run. A lot of the tutorials showed using a NOP as a pad character; it would be really handy if I didn't have to do that. Thanks for the suggestion.