New Pull Request: SPI Planks for I2C
therealdreg/BusPirate5-firmware → DangerousPrototypes/BusPirate5-firmware
Created by: therealdreg
Did you try the clock stretching version? I see you switched the wait in to wait gpio, and then program a custom wait instruction.
Why move it to the bottom of the loop though? Could the same not be done in the original place in the i2c clock stretch code?
bitloop:
out pins, 1 [7] ; Serialise write data (all-ones if reading)
nop side 0b1 [6] ; SCL rising edge
scl_stretch:
wait 1 pin, 1 [4] ; Allow clock to be stretched, in pins: 0=sda, 1=scl
To stay as close to the original debugged code as possible? It makes me nervous to mess with the PIO programs without extensive testing.
Comment by: DangerousPrototypes
@DangerousPrototypes
I didn’t move anything! I just created a label so I could replace the instruction where it was originally, that’s all!
Comment by: therealdreg
1 Like
btw @DangerousPrototypes,
This wait was a commented-out instruction! I removed it because it doesn’t belong in that PIO—we already have one specialized in CLOCK STRETCH…
Comment by: therealdreg
Ah, thank you. The diff confused me as to where that was added. That’s great then.
PIO update looks solid, but I am going to do some work on handling in the hwi2c mode code. I will add the pins to the mode config struct, and make the code universal for any pin placement. Then a universal config command to move pins, which can also be implemented in 1-wire, 2-wire, LED, I2C and other modes where the PIO program can be made flexible.
This might also be a great time to enhance the mode command to accept command line parameters, including pin placement.
@Ian, keep in mind that the I2C sniffer and other features assume certain positions (and modify things on the screen).
will you merge the PR and then implement what you have in mind?
1 Like
Yes, I have it in my repo now, I just want to clean up the if then else
I think there is a clean way to do this with the config struct instead of the if else tree.
I also want to give some thought to the plank command. Is it just for this one plank? How does the user know it’s for the flash plank and not the DDR5 plank? Is plank better as a global command that can totally set a mode, enable the right power supply and pull-ups based on the name of a plank or a code on the plank?
Preferably we’d offer “here is how you can change pins if you need to”, rather than “here’s a random hack in the firmware for this single adapter board”.
You’ve already done the hard work of getting the PIO program to work on arbitrary pins, I’d just like to take a moment to consider how this all fits together with this great new ability. If we merge and document it as it, then it will be much more work to redesign it later.
the PR is a dirty POC haha, you are right, For this kind of thing, I trust your judgment and good taste more than mine—go with whatever makes the most sense to you. Maybe a command like:
plank SPI_FLASH
and if you’re in I2C mode, it sets everything up accordingly?
1 Like
Let’s continue the discussion on the forum!
Comment by: therealdreg
Maybe two parts to this project.
- Create the infrastructure for arbitrary pin placement in 1-Wire and I2C (easy modes to do).
- Figure out how to collapse the pin assignment into the struct, eliminate if then else statement switching.
- Figure out how to handle switching between functions in same mode with different pinouts (eg sniff in I2C).
- How to configure the pinout.
- Figure out how to assign the pinout. I really don’t want to add mode configuration options (e.g. updating all the existing demos and examples).
- A random idea is a
pinoutcommand where each mode presents alternate pinout possibilities. I2C could be arbitrary assignment for SDA and SCL, SPI would have none, UART would have two options (high set, low set).
That pinout idea is a good one—if you need me to test something or if I can help you in any way, just let me know.