Asd/usb isp - #111
Conversation
labbott
left a comment
labbott
left a comment
There was a problem hiding this comment.
I'm going to take another pass in a bit but generally I think this looks okay. I might go ahead and delete cfpa-update in a separate PR because that was very early experimental work and we definitely don't use it.
| // Docs don't have an encoding for pings/acks on USB so we just read a | ||
| // property | ||
| fn do_ping(&mut self) -> Result<(), IspError> { | ||
| self.send_command(CommandTag::GetProperty, &[1])?; | ||
| self.read_response(ResponseCode::GetProperty)?; | ||
| Ok(()) | ||
| } |
There was a problem hiding this comment.
This matches my experimentation and what blhost does as well
There was a problem hiding this comment.
LGTM, modulo some clap nit picking. EDIT: I think was looking at an old version that was still in draft.
There's a lot in this repo I would like to fix up but I don't want to block this work. Once we've updated embootleby I'd like to make sure that gets some cycles with the existing UART programming (I think this is overall very low risk).
|
This seems to work okay on one of my spare MCULinks (Note going back and forth was not automatic I use the jumper to force ISP mode) |
2 participants
This adds the ability to use the lpc55_isp library to interface with the ISP bootloader over USB.
It involved a bit of a refactor. Open to input on how it could be shaped better.
This will impact https://github.com/oxidecomputer/embootleby because of a new trait and a slight change in function signatures. Perhaps there is a clever way to mitigate this. Example of how the changes would look is in oxidecomputer/embootleby#9
The motivation for these changes is to provide a way for manufacturers to program Barbacks. The USB ISP is the primary programming interface.
blhostcannot handle multiple devices with the same device ID connected to the same computer, which is exactly what a brand new Barback looks like. By using our own tooling here we can avoid this limitation.