Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand Memory #14

Open
ehuegler opened this issue Jul 15, 2022 · 4 comments
Open

Expand Memory #14

ehuegler opened this issue Jul 15, 2022 · 4 comments
Labels
enhancement New feature or request
Milestone

Comments

@ehuegler
Copy link
Collaborator

As it currently stands, the pico can store about 8000 instructions in sweep mode. If using all 4 channels it would only be 2000 instructions. If the pico is timing itself, it loses 25% of its instruction storage.

If single stepping frequency, phase and amplitude, the max number of instructions would be about 15000.

It could be possible in the future to utilize the flash memory on the pico to store significantly more instructions, but that would add decent amount more complexity.

@ehuegler ehuegler added the enhancement New feature or request label Jul 18, 2022
@ehuegler ehuegler added this to the Stretch milestone Jul 18, 2022
@ehuegler
Copy link
Collaborator Author

ehuegler commented Jul 21, 2022

@dihm
Here are the number of steps the pico can store when using all available RAM:

  • Single stepping on 1 channel: 19214
  • Single Stepping on 4 channels: 4382
  • Frequency Sweeping on 1 channel: 8918
  • Frequncy Sweeping on 4 channels: 2134

*If the pico is timing itself internally it can only hold about 85% as many steps.

@ehuegler
Copy link
Collaborator Author

I have been able to get it working so the pico stores the table in the flash memory. That allows the pico to hold 6 times as many steps across the board.

The downside is that writing to the pico's flash is really expensive, so it takes about a quarter of a second to program EACH instruction, seems like it could be too slow to be useful. (It is so expensive because in order to write to flash you have to erase then rewrite entire 4kB blocks at a time).

Reading from the flash is not expensive though, so reading back a table from flash performs just as well as reading it back from RAM.

@dihm
Copy link
Contributor

dihm commented Aug 1, 2022

Thinking about this briefly, I wonder if we could do something like having a special table programming mode that could help with these things. When you are in this mode, the pico insists on only accepting set commands and can do some optimizations as a result.

For instance, we could have a special binary block set command for writing long tables as a single command with minimal overhead. More importantly, maybe we could have all table set commands initially to RAM, then have the pico automatically move full 4kb sized chunks to flash as needed. This may be hard to handle well since you'd need to handle writing to flash while accepting more set commands to RAM, which sounds hard. Maybe in special programming mode you could allow direct 4kb block writes to the flash? Anyway, just spit-balling ways to up the numbers in a way that is functional.

In any case, even 2000 instructions per channel is actually a lot given that includes sweeps. I'll admit that it sounds a bit far-fetched that we really need to allow for so many sweeps at a given time.

@ehuegler
Copy link
Collaborator Author

ehuegler commented Mar 15, 2023

There are several active issues in the pico-sdk repo which might make this more feasible in the future.
raspberrypi/pico-sdk#758
raspberrypi/pico-sdk#1169

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants