There are a couple items on my end of year list, including some kind of JTAG interface discovery. I was originally planning to add it as a JTAG mode to the main firmware, but time and licensing mean that won’t happen for a while.
JTAGulator - The gold standard. CC-BY license, but written in spin for parallax.
blueTag - JTAGulator clone on RP2040, but licensed GPL (so no integration)
JTAGenum - Arduino JTAG finder, license not mentioned.
arduinull - Arduino JTAG finder, license not mentioned, but very short (200 lines)
To meet my year end goal, I think the best bet is to port blueTag to the Bus Pirate hardware as another external firmware. I cannot integrate it directly because it is GPL licensed, or at least that is my understanding.
After I get familiar with JTAG again, and have targets to test against, I’ll add a native JTAG mode to the main firmware.
I use blueTag on one of my spare Picos. I like it because it will also look both SWD and JTAG, which the JTAGulator doesn’t do.
I used the JTAGulator at work, and the only thing I miss about it when using my janky blueTag setup is that I’m 3.3V specific because I don’t have any level shifters - just right into the GPIO ports. it would be sweet to run it on the BP hardware to take care of that.
I noticed the SWD stuff in the code, and thought that was a bonus. Especially becaiae it’s half the code which made the 1200 line file less intimidating
Thank you This is next on my list when I get the infrared mode stuff completed. Hopefully this weekend or Monday, depending on how difficult it is to capture the modulation frequency (it’s not going great).
blueTag command line interface is working in JTAG mode. It doesn’t do much yet, but that’s next.
I’m trying to do minimal changes to blueTag to stay in sync with the upstream project. So far I’ve added a helper function and extern’ed a variable via a .h file. The display uses \n instead of \r\n though, so it’s gonna get dicey.
Formatting aside (last thing to do), the SWD part of bluetag is now working in JTAG mode. Here it detects a RP2040 PICO board.
There are a lot of global variables, which is fine for how bluetag is intended to be used as a stand alone script. I switched everything over to a struct that is passed around to keep it a bit more contained in the Bus Pirate firmware.
As to the "\r\n" vs. "\n" thing … isn’t there a terminal (client) setting that allows you to make them essentially equivalent?
Or, is blueTag actually using newline to get to the next line without changing position on that line? (if so, it’s rare to see software relying on that these days…)
I’ll have to look. Historically there is a reason we use rn, but I don’t recall why.
I’d really like to get it to a place where the display of findings is totally unlinked from the finding process, but with minimal impact on the original fork.
The other thing I’m pondering is an optional pre check to filter out ground or power pins. Pull a pin high and low, if it is stuck at either mark it for skip. Optional of course.
FWIW, if you use my BusPirate/BusPirateSetup script, it tries to set up the terminal software correctly. For example, for tio, it uses tio -n --map INLCRNL,ODELBS -b $BAUD $PORT