PCB prices take a sharp jump when they exceed 100mm on a side. There also seemed to be a shortage of BlueFruit EZ-Key modules. These reasons were enough to shrink the size of the board by eliminating the EZ-Key from the schematic and layout. In order to retain functionality, the data pins were moved to the accessory port pins so anyone could attach an EZ-Key board with a simple 2x6 header connector. This port is also useful for anyone messing with the firmware who wants to add more buttons or encoders rather than letting pins sit unused.
The newest version of the board arrived and was populated with buttons and encoders. Component depth was graciously similar between the bases of the buttons and encoders so there was no need to extend buttons or encoder knobs.
With a usable set of hardware, programming was started. As with most projects like this, the serial port was integral to making working code. The first step was to get accurate serial data back from the board while monitoring with the Teensy. PJRC’s encoder library was used and it worked well even with the inexpensive encoders.
After there was proof of good readings from the serial port, it was time to turn them into keyboard commands which could interface with OpenSCAD. By using keyboard commands and emulating a USB keyboard, there was no software to install so the OpenVectorKB was plug-and-play for any OpenSCAD user. A video was taken to demonstrate the functionality.
The enclosure was finally printed and all the button caps, encoder knobs, and LEDs were installed. The LEDs were not difficult to program, but displaying the magnitude/precision values was a little tricky. For a solution, one of the far left or right LEDs lights up in red and the adjacent LEDs show how precise the adjustments will be. Blue LEDs to the left of the red indicate the value is greater than one and which order of magnitude. Similarly, green LEDs to the right of the red indicate if the value is editing the tenth’s or hundredth’s place.
Updated layout
The newest version of the board arrived and was populated with buttons and encoders. Component depth was graciously similar between the bases of the buttons and encoders so there was no need to extend buttons or encoder knobs.
Assembled board with encoders and tactile switches
With a usable set of hardware, programming was started. As with most projects like this, the serial port was integral to making working code. The first step was to get accurate serial data back from the board while monitoring with the Teensy. PJRC’s encoder library was used and it worked well even with the inexpensive encoders.
Reading serial output from the hardware
After there was proof of good readings from the serial port, it was time to turn them into keyboard commands which could interface with OpenSCAD. By using keyboard commands and emulating a USB keyboard, there was no software to install so the OpenVectorKB was plug-and-play for any OpenSCAD user. A video was taken to demonstrate the functionality.
Early video demonstration of the OpenVectorKB
The enclosure was finally printed and all the button caps, encoder knobs, and LEDs were installed. The LEDs were not difficult to program, but displaying the magnitude/precision values was a little tricky. For a solution, one of the far left or right LEDs lights up in red and the adjacent LEDs show how precise the adjustments will be. Blue LEDs to the left of the red indicate the value is greater than one and which order of magnitude. Similarly, green LEDs to the right of the red indicate if the value is editing the tenth’s or hundredth’s place.
Changing precision/magnitude with LED feedback
The rest of the weekly summaries have been arranged by date.
Disclaimer for http://24hourengineer.blogspot.com/
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, is not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, is not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
Comments
Post a Comment