Enhancements by DJShepherd

[DJShepherd]

Hey everyone! First time contributor but long time fan of the project! I have been developing a handful of features on my own fork that suit my own personal workflow and general enhancements that I wanted to make. Thought I'd reach out and ask if it was worth it or not to create branches and PR's to contribute to the main project.

• I/O performance increases, mainly by reduction of buffer copies
• Enhancements to controlling/configuring most of the GPIOSettings class
• Added an easy API to help develop advanced glitch test setups for a new DUT
• Bugfix/inconsistency with the limit for sending data over bulk vs ctl
• General code cleanup and refactoring (splitting overly large functions up, constant and enum usage, common code reuse, etc)
• Suppression of optimization for the SimpleSerial glitch demos

Feel free to decline my work, just thought I'd say hi and thanks to everyone's hard work and to extend my own assistance! :)

My branch for reference: DJShepherd/chipwhisperer/DJShepherd/develop

~DJ Shepherd

[colinoflynn]

Wow, awesome thanks! As there is a pretty large number of changes will review here too to see if any conflicts with anything else we had ongoing. One quick high-level question: we've been slowly moving some of ChipWhisperer to Apache2 license, would you have any problem with that (currently a lot is under GPL, but some is MIT & some is Apache2)? We haven't fully done that yet & some stuff may stay GPL for other reasons, but wanted to check with you as well since this would be one of the larger external commits it looks like with many files touched. In particular the demo firmware (victims/firmware/etc) would become Apache2 & most of the Python interface for example.

[DJShepherd]

@colinoflynn thank you! As I mentioned, I can break down my develop branch into specific features so you don't have to absorb such a big change at once (unless desired, haha). As far as licensing goes, I don't mind. Whatever I can provide for the greater project belongs to the project, as far as I'm concerned. :)

[alex-dewar]

Took a quick look over and it looks great! Some parts definitely look a lot cleaner than before. Only thing I'd like to see changed is moving the constants into the class they're used for. IMO it get a bit annoying having to swap back and forth between files when working on something, and it might be nice as an end user to have an easy way to print the constants out, something like scope.io.consts or similar.

[DJShepherd]

@alex-dewar Thank you! Yeah I understand the const stuff, definitely a change I can work on and implement into my stuff.

[DJShepherd]

Sorry for the delay with getting this implemented. I've been doing new chip bring-up these last few months at work sooo RIP my free time haha.

I am beginning to jump back onto the project and I think I'm going to break up all these enhancements into separate PR's/features. I'm gunna start with some of the IO optimizations and the glitch demo optimization suppression. I'll slowly work on getting the others opened into a PR.

IO Optimizations Glitch Demo Optimization Suppression

[DJShepherd]

Opened some PR's for the next pieces of my contribution. API changes with the CONSTS are a lot, to say the least... breaking that up into smaller chunks of their own respective setting, starting with VCC glitch HP/LP setting. On the side, I added the looper API (as a draft, for now).

Main hold up for good testing is that I think I burned my CWLITE mosfets. I have the HUSKY, but I have to find time to set that up. Hopefully soon!

VCC Glitch Mosfet Control Update GlitchController Updates and Looper Script

[alex-dewar]

Thanks for working on this! I'm going to be busy with traveling for the next week or so, but I'll take an in depth look once I get back.

[DJShepherd]

As mentioned in the VCC Glitcht PR, I have been working on the next enhancement as well. This is the GPIO API refactoring. I have the feature branch ready to go, but it's dependent on the VCC change merging in. When that gets the okay and gets pulled in, I'll create the PR.

An added benefit to this GPIO change is that it halves the serial/USB traffic related to pin management after simplifying reading and writing GPIO modes/states.

Compare: DJShepherd/fast_glitcht...DJShepherd/gpio_api_update

[DJShepherd]

When I have approval for the API design, I have a handful of branches ready to create a PR for. GPIO Refactor Ext Clock Refactor Target Power Refactor IO Trigger Refactor Glitch Output Refactor

I'll edit this list as I finish the features.