In addition, I was thinking about SSB64 and how with this I could change the button mappings to allow for C-stick smash attacks with the GCN controller. I haven't uploaded my changes to the code yet as I still want to tweak things.
You can see this in action in my short videos I've made on it
Hey everyone, got another update for this project to share.
After working closely with a few individuals it was discovered that some of the pre-existing GPIB software (such as KE5FX's tools) has some hardcoded serial port settings, one of which being the use of hardware flow control. After getting builds of the software tools with these disabled, some buffer problems were found using the default settings, under Windows, without the flow control. Running the software with WINE on Linux did not produce these issues. With some small tweaks to either the software or to Windows USB settings would fix the issue but that's not very intuitive. A better long term solution would be to wire up the hardware flow control lines in the next hardware revision for use in a future firmware update.
That's what I've done with the revision 4 PCB. In addition, I grounded a few unused digital lines on the micro to be able to, starting with rev4+, check what the hardware revision is in software. I also added two LEDs to the FT230X to allow it to signal on TX and RX.
Thanks! You can always pick them up on my website www.galvant.ca if you want to financially support my work and future firmware development. I understand that's not an option for everyone so if you choose to build it yourself, be sure to send me a picture!
Anyone who has been watching my YouTube videos will know that I've been working on this USB isolator for quite some time (for no particular reason other than getting distracted by other projects). I figure now is a good time to post the project here on the forum so more people can check it out.
The boards pictured below are of rev2. I just finished off rev2.1 which fixes a few small things (such as LED placement) and adds a jumper header to bypass the linear regulator. This way a user can also use the barrel connector with a 5V supply.
I received inspiration for the project from other USB isolator projects on the internet. Mine features a few improvements to many of them:
- USB-B and micro-USB connectors on the host (upstream) side. - In addition to accepting power via the barrel connector (which goes through a basic 7805 low dropout linear regulator), there is also a micro-USB port for device-side power. This allows you to use the now common cell phone charger cube to power your isolated device. - Push-button switch for easy USB disconnection events. - Bypass jumper for linear regulator, allowing for 5V power from the barrel connector. - Encased in a small box to protect the IC from the world.
You can find it on my website: http://galvant.ca/shop/usb-isolator/ where I'm currently collecting pre-orders for anyone interested. Any and all support for my work is greatly appreciated and goes a long way to allow me to keep making OSHW.
In the future I'd appreciate the business, even if you're looking for un-assembled boards. I'm trying to work on OSHW full time instead of getting a "real job". I'm almost going even on a monthly basis, and I don't even own a car.
But hey, its within your right to order them else where.
I just uploaded a new build to the dev branch on GitHub which speeds up command recognition. Before this build I had the micro do comparisons on input vs each stored "valid" string in memory until a match was found. This resulted in a lot of unneeded character checks.
With the update, only the characters that differentiates each command are checked. So, while this technically reduces how strict the language set is, it speeds this section of the code execute up enough that large numbers of internal commands being sent no longer require the occasional delay to prevent the buffer from being filled.
Next I want to investigate speeding up the port manipulation and see if that improves performance at all. If it does make a difference, both of these changes will be packaged together in a final firmware v6.
[quote author="mountaindude"]So I am pretty much a GPIB noob... sorry if I ask something totally obvious.
Would I be able to control my GPIB / HPIB equipped tools with this board? Such as a HP 3478 bench meter, Fluke 8842 bench meter, HP 6632A power supply (to name the ones most commonly used around here).
Would it work from a Mac? Guess it should, as long as a terminal program capable of fast serial is used, right?[/quote]
Hey sorry I missed your post. Yes as long as those instruments have GPIB/HPIB ports on the back (and they are functioning!) this project will let you control them.
I have never *personally* used it with OSX, but I know that FTDI does have an OSX driver so it should work just fine. If you are going to use a terminal program be sure that it sends your entire string at once, rather than sending each character as you type them out.
After many days, I just finished off firmware version 5 for my adapter. This is probably my biggest update yet. A lot of people asked for compatibility with the Prologix commands so that's what I focused on. Here is an overview of the new firmware:
- Nearly all Prologix command set support. The adapter should now work with some pre-existing software tools and examples on the internet that were originally intended. Some will require a few changes for baud rate and flow control settings. - Improved termination character handling - SRQ support (but no parallel polling, only serial) - Improved stability - Device mode (first version so there may be fixes in the future) - Most settings can be stored in EEPROM - Basic FIFO buffer for data sent from the PC
Yep! I just finished my MSc and I'm trying to do OSHW full time.
Is your plan to just vary the voltages on D+ and D- until you find the maximum charge rate? Totally an option but I've found that many devices will require you to disconnect the 5V supply between changing the voltages on D+ and D-. IE the device will set its charge rate when connection is initially made and does not continue to monitor those other lines. You'll need to break the 5V connection each time while hunting for that optimal rate.
A current monitor would probably increase the BOM by too much. I'd like to keep this one as minimal as possible. I am thinking about a more "advanced" version which could include a current monitor. Let's see if people like this version first!
Lots of devices use the shorted configuration. In fact, everything that actually follows the USB charging spec does. My Samsung Galaxy Nexus cellphone and my Blackberry Playbook tablet both check for shorted D+ and D- lines.
I usually forget to generate a PDF so I will do so later today. Thanks for the reminder :D
Hey everybody, I've got another project of mine to show today.
Inspired by the USB Condom, the USB Wrapper helps protect your device against untrusted USB ports by severing the USB data lines and only allowing the power lines to connect through. This ensures that no data information can be transfered between the power source and your device. This helps against known attacks such as juice jacking: http://krebsonsecurity.com/2011/08/bewa ... e-jacking/
This however does present a problem. In legitimate USB chargers, the data lines are used to communicate to your device how much power they are capable of sourcing. The exact means by which they do vary between manufacturers. The standard calls for the D+ and D- lines to be shorted together, while companies like Apple will apply specific voltages on both lines depending on the charger. By entirely disconnecting these data lines, your device does not know any information about the charger, and will thus assume it is a standard USB2.0 port. This limits means the device will self-limit the charging rate to 2.5W, even if the charger can in fact handle more.
To deal with this, the USB Wrapper has two slider switches allowing you to tell your device what kind of charger it is connected to. This also allows you to mix and match chargers and device manufacturers which don't follow the same signalling rules. For example, an iPhone with a Samsung charger cube. It features selections for dedicated charger port (D+ & D- shorted), Apple, Sony, and open circuit. For Apple, there are 4 options, 500mA, 1A, 2.1A, and 2.5A.
[quote author="dougal"]I hate to sound negative, but isn't the ATMEGA32U4 a bit overkill for this?
I did something similar last summer using a Digispark, which uses the ATTiny85. In my case, I used the DigiUSB library to emulate a mouse instead of a keyboard, with a small amount of movement to prevent the screensaver from activating.
[quote author="Sjaak"]The exposed pad is also used to dissipate the heat generated by the small IC. Mostly it is not electrically needed, but just thermocally (?). For prototyping you prolly get a way with it.[/quote]
True. Thankfully I'm not sinking/sourcing any real amounts on the micro so heat dissipation isn't a problem here.
[quote author="joeforker"]Tell me more about your hand-soldered VQFP, I am impressed.[/quote]
These were the first boards I soldered together that featured parts without exposed leads. I used my reflow/toaster oven, but I did not use enough paste for several of them. Thankfully, I had left plenty of pad exposed on the PCB. I applied plenty of flux and a small amount of solder to my iron. Just dragging over the pads then sucked up the required amount under the pins to make the connection. It went surprising well. In fact, you could probably do the entire board by hand without the initial reflow step so long as you do not require the center pad to be connected. Just make sure to leave enough exposed on the PCB to give you something to work with.