It seems like the solution is to generate a set of files in an image of the old repo that each point to the same path in the new repo.
Simple plain-text with a raw URL should work. I could hack something together in a hour or two in python.
Oh, I have more patches to the bus-pirate library. I removed the timeouts, and instead rely on checking the number of received bytes against the number of bytes I'm waiting for (with an eventual timeout if the connection is lost).
This results in the turn around for many commands (like large_bulk_write_read) dropping from ~0.1 second execution to ~0.015 execution time, and that includes the USB latency and the time it takes the hardware the bus-pirate is talking to to respond.
Can I IM you to get SVN write access? I'd be happy to take over maintenance of the pyBusPirate library.
Incidentally, if you've depreciated the old SVN, it would probably be a good idea to delete everything from the head of the repo. Just have a single file with info about the new repository in it.
That way, if someone (like me), does a checkout (like I did), you would just get a "Nothing here, go to the new place" message. With a VCS, all the history will still be there, it would just be more apparent that the repo contents are depreciated.
I've mostly been working with the SPI module, though I went through the whole package and did formatting cleanup (I run sublime text with sublimelinter, which makes it very hard to work on code that's not PEP8 compliant).
The main thing I've done is the `0b00000100 - Write then read` function is now exposed as the function `large_bulk_write_read` in the `SPI` class.
There is also a `check_in_SPI_mode` function in the SPI class as well, which I'm using to make my code capable of exiting and restarting without causing any of the BP IO lines to toggle. It turns out if you try to re-enter binary mode when the BP is already in binary SPI mode, it kicks you out of the SPI mode, which de-asserts the CS line until you re-enter SPI mode. This is a way to get around this.
Ideally, there should be a dedicated "What mode am I in" command, that if issues when you're in basic binary mode before switching to a certain bus mode won't cause the system to switch to one of the bus modes. The problem is, right now, if you're not in any bus mode, issuing the "What mode am I in" command (0b00000001) will put the BP in SPI mode.
I'll probably continue tweaking, though the test-harness I am building with the BP is now working. I'm not sure how SVN write access is managed (I've only used SVN in very small groups), but I can push my updates to the repo myself, if you let me know how.
I'm working on an application that uses a bus-pirate as a test SPI interface.
I have a few scripts that talk to the bus pirate using a modified version of pyBusPirate.
However, there seems to be no way to determine the current bus pirate mode (binary vs ASCII) without resetting the IO lines.
Right now, the scripts simply re-enter binary mode upon startup. However, this de-asserts CS, which is something I would really like to avoid if at all possible.
Is there an equivalent to the '?' ascii-mode command in binary mode? If so, I can simply issue that command, and check to see if there is any return, which should tell me whether I'm in binary or ASCII mode.
Ideally, there would be a command (say, 0b00001110), that returns the current command mode.