Page 25 of 27
Posted: 24 Jan 2017, 09:30
by nissarup
As this board is targeted at people hand wiring the entire keyboard, I would argue that hand wiring two more wires is not an insurmountable ordeal
It would also allow us to pick a better spot for a real reset-button instead of having to make a hole in the case at the exact point of the board.
Posted: 24 Jan 2017, 09:45
by matt3o
while I agree with nissarup I also want to make the board newbie friendly.
Posted: 24 Jan 2017, 10:57
by Sythe
Thats fair enough.
I think 1 button is OK then. 2 isn't necessary.
Since its USB powered, just unplug the cable for reset.
Edit:
For the reset though, just leave the pads as is(and don't load) or change to through hole to allow anyone to add a button or w/e if they wish to.
Posted: 24 Jan 2017, 11:13
by matt3o
Sythe wrote: I think 1 button is OK then. 2 isn't necessary.
Since its USB powered, just unplug the cable for reset.

agreed!
Posted: 24 Jan 2017, 17:57
by MrBishop
yeah one button to throw it into bootloader mode is probably plenty.
Posted: 25 Jan 2017, 23:48
by tentator
sorry guyz for the delay but I was out of town so far..
now I tried to apply the last patch mentioned up there since the rest should be already there, right?
anyway it seems not to change anything to me:
Code: Select all
10t8or@tentx MINGW64 /c/10t8or/Keyb/tmk_keyboard/keyboard/kl27z_onekey (master)
$ make
Compiler Options
arm-none-eabi-gcc -c -mcpu=cortex-m0plus -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -std=gnu99 -DPROTOCOL_CHIBIOS -ffunction-sections -fdata-sections -fno-common -include config.h -Wall -Wextra -Wundef -Wstrict-prototypes -Wno-missing-field-initializers -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DCONSOLE_ENABLE -DVERSION=4a9c27f-dirty -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -I../../tmk_core/tool/chibios/ChibiOS/os/license -I../../tmk_core/tool/chibios/ChibiOS/os/common/startup/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/common/startup/ARMCMx/devices/KL2x -I../../tmk_core/tool/chibios/ChibiOS/os/common/ext/CMSIS/include -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/common/ext/CMSIS/KINETIS -I../../tmk_core/tool/chibios/ChibiOS/os/rt/include -I../../tmk_core/tool/chibios/ChibiOS/os/common/oslib/include -I../../tmk_core/tool/chibios/ChibiOS/os/common/ports/ARMCMx -I../../tmk_core/tool/chibios/ChibiOS/os/common/ports/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/ChibiOS/os/hal/osal/rt -I../../tmk_core/tool/chibios/ChibiOS/os/hal/include -I../../tmk_core/tool/chibios/ChibiOS/os/hal/ports/common/ARMCMx -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/hal/ports/KINETIS/KL2x -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/hal/ports/KINETIS/LLD -I./boards/ELF -I../../tmk_core/tool/chibios/ChibiOS/os/hal/lib/streams -I../../tmk_core/tool/chibios/ChibiOS/os/various -I../../tmk_core -I../../tmk_core/common -I../../tmk_core/protocol/chibios -I../../tmk_core/protocol -I. main.c -o main.o
Compiling crt0_v6m.S
Compiling chcoreasm_v6m.S
Compiling crt1.c
Compiling vectors.c
Compiling chsys.c
Compiling chdebug.c
Compiling chtrace.c
Compiling chvt.c
Compiling chschd.c
Compiling chthreads.c
Compiling chregistry.c
Compiling chsem.c
Compiling chmtx.c
Compiling chcond.c
Compiling chevents.c
Compiling chmsg.c
Compiling chdynamic.c
Compiling chmboxes.c
Compiling chmemcore.c
Compiling chheap.c
Compiling chmempools.c
Compiling chcore.c
Compiling chcore_v6m.c
Compiling osal.c
Compiling hal.c
Compiling hal_st.c
Compiling hal_buffers.c
Compiling hal_queues.c
Compiling hal_mmcsd.c
Compiling hal_pal.c
Compiling hal_usb.c
Compiling nvic.c
Compiling hal_lld.c
../../tmk_core/tool/chibios/ChibiOS-Contrib/os/hal/ports/KINETIS/KL2x/hal_lld.c:59:4: warning: #warning Please triple check your FSEC setting: KEYEN!=b10, MEEN==b10, SEC!=b10 leads to an unmodifiable chip. [-Wcpp]
#warning Please triple check your FSEC setting: KEYEN!=b10, MEEN==b10, SEC!=b10 leads to an unmodifiable chip.
^~~~~~~
Compiling hal_pal_lld.c
Compiling hal_serial_lld.c
Compiling hal_i2c_lld.c
Compiling hal_ext_lld.c
Compiling hal_adc_lld.c
Compiling hal_gpt_lld.c
Compiling hal_pwm_lld.c
Compiling hal_st_lld.c
Compiling hal_usb_lld.c
Compiling board.c
Compiling chprintf.c
Compiling memstreams.c
Compiling nullstreams.c
Compiling usb_main.c
../../tmk_core/protocol/chibios/usb_main.c: In function 'usb_event_cb':
../../tmk_core/protocol/chibios/usb_main.c:787:3: warning: enumeration value 'USB_EVENT_UNCONFIGURED' not handled in switch [-Wswitch]
switch(event) {
^~~~~~
../../tmk_core/protocol/chibios/usb_main.c: In function 'init_usb_driver':
../../tmk_core/protocol/chibios/usb_main.c:1036:3: warning: the address of 'console_queue_buffer' will always evaluate as 'true' [-Waddress]
obqObjectInit(&console_buf_queue, console_queue_buffer, CONSOLE_EPSIZE, CONSOLE_QUEUE_CAPACITY, console_queue_onotify, (void*)usbp);
^~~~~~~~~~~~~
In file included from ../../tmk_core/protocol/chibios/usb_main.c:21:0:
../../tmk_core/protocol/chibios/usb_main.h:119:32: warning: passing argument 3 of 'obqObjectInit' makes pointer from integer without a cast [-Wint-conversion]
#define CONSOLE_EPSIZE 16
^
../../tmk_core/protocol/chibios/usb_main.c:1036:59: note: in expansion of macro 'CONSOLE_EPSIZE'
obqObjectInit(&console_buf_queue, console_queue_buffer, CONSOLE_EPSIZE, CONSOLE_QUEUE_CAPACITY, console_queue_onotify, (void*)usbp);
^~~~~~~~~~~~~~
In file included from ../../tmk_core/tool/chibios/ChibiOS/os/hal/include/hal.h:120:0,
from ../../tmk_core/protocol/chibios/usb_main.c:19:
../../tmk_core/tool/chibios/ChibiOS/os/hal/include/hal_buffers.h:295:8: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'int'
void obqObjectInit(output_buffers_queue_t *obqp, bool suspended, uint8_t *bp,
^~~~~~~~~~~~~
../../tmk_core/protocol/chibios/usb_main.c:1036:99: warning: passing argument 5 of 'obqObjectInit' makes integer from pointer without a cast [-Wint-conversion]
obqObjectInit(&console_buf_queue, console_queue_buffer, CONSOLE_EPSIZE, CONSOLE_QUEUE_CAPACITY, console_queue_onotify, (void*)usbp);
^~~~~~~~~~~~~~~~~~~~~
In file included from ../../tmk_core/tool/chibios/ChibiOS/os/hal/include/hal.h:120:0,
from ../../tmk_core/protocol/chibios/usb_main.c:19:
../../tmk_core/tool/chibios/ChibiOS/os/hal/include/hal_buffers.h:295:8: note: expected 'size_t {aka unsigned int}' but argument is of type 'void (*)(io_buffers_queue_t *) {aka void (*)(struct io_buffers_queue *)}'
void obqObjectInit(output_buffers_queue_t *obqp, bool suspended, uint8_t *bp,
^~~~~~~~~~~~~
../../tmk_core/protocol/chibios/usb_main.c:1036:3: error: too few arguments to function 'obqObjectInit'
obqObjectInit(&console_buf_queue, console_queue_buffer, CONSOLE_EPSIZE, CONSOLE_QUEUE_CAPACITY, console_queue_onotify, (void*)usbp);
^~~~~~~~~~~~~
In file included from ../../tmk_core/tool/chibios/ChibiOS/os/hal/include/hal.h:120:0,
from ../../tmk_core/protocol/chibios/usb_main.c:19:
../../tmk_core/tool/chibios/ChibiOS/os/hal/include/hal_buffers.h:295:8: note: declared here
void obqObjectInit(output_buffers_queue_t *obqp, bool suspended, uint8_t *bp,
^~~~~~~~~~~~~
make: *** [build/obj/usb_main.o] Error 1
about the button I would also agree on putting just one of the two and using a cheaper panasonic one..
about physical dimentions it looks quite good to me also with "exotic" 60%-cases:

- photo5764614605891545151.jpg (179.45 KiB) Viewed 7558 times

- photo5775987039341225998.jpg (96.61 KiB) Viewed 7558 times
tent:wq
Posted: 25 Jan 2017, 23:53
by matt3o
tentator, did you patch both chibios and tmk?
Posted: 26 Jan 2017, 00:08
by tlt
I want to try one of these when they are done. Looks promising!
Posted: 26 Jan 2017, 00:19
by tentator
matt3o wrote: tentator, did you patch both chibios and tmk?
I only did what he mentioned in the last post when he says: "Still this pathc is needed to compile tmk."...
reason is that for instance the other file seems to me already patched:
in a/os/hal/src/hal_usb_hid.c I read:
Code: Select all
obqObjectInit(&uhdp->obqueue, true, uhdp->ob,
USB_HID_BUFFERS_SIZE, USB_HID_BUFFERS_NUMBER,
obnotify, uhdp);
Posted: 26 Jan 2017, 00:25
by tentator
edit: oh fukc you are right the other one in tmk for some reason was not patched?! so I manually added the additional true argument.. now it works.. sorry.. will let you know how it works..

well just a couple of warnings.. hope they are harmless.. ahaha:
Code: Select all
$ make
Compiler Options
arm-none-eabi-gcc -c -mcpu=cortex-m0plus -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -std=gnu99 -DPROTOCOL_CHIBIOS -ffunction-sections -fdata-sections -fno-common -include config.h -Wall -Wextra -Wundef -Wstrict-prototypes -Wno-missing-field-initializers -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DCONSOLE_ENABLE -DVERSION=4a9c27f-dirty -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -I../../tmk_core/tool/chibios/ChibiOS/os/license -I../../tmk_core/tool/chibios/ChibiOS/os/common/startup/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/common/startup/ARMCMx/devices/KL2x -I../../tmk_core/tool/chibios/ChibiOS/os/common/ext/CMSIS/include -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/common/ext/CMSIS/KINETIS -I../../tmk_core/tool/chibios/ChibiOS/os/rt/include -I../../tmk_core/tool/chibios/ChibiOS/os/common/oslib/include -I../../tmk_core/tool/chibios/ChibiOS/os/common/ports/ARMCMx -I../../tmk_core/tool/chibios/ChibiOS/os/common/ports/ARMCMx/compilers/GCC -I../../tmk_core/tool/chibios/ChibiOS/os/hal/osal/rt -I../../tmk_core/tool/chibios/ChibiOS/os/hal/include -I../../tmk_core/tool/chibios/ChibiOS/os/hal/ports/common/ARMCMx -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/hal/ports/KINETIS/KL2x -I../../tmk_core/tool/chibios/ChibiOS-Contrib/os/hal/ports/KINETIS/LLD -I./boards/ELF -I../../tmk_core/tool/chibios/ChibiOS/os/hal/lib/streams -I../../tmk_core/tool/chibios/ChibiOS/os/various -I../../tmk_core -I../../tmk_core/common -I../../tmk_core/protocol/chibios -I../../tmk_core/protocol -I. main.c -o main.o
Compiling crt0_v6m.S
Compiling chcoreasm_v6m.S
Compiling crt1.c
Compiling vectors.c
Compiling chsys.c
Compiling chdebug.c
Compiling chtrace.c
Compiling chvt.c
Compiling chschd.c
Compiling chthreads.c
Compiling chregistry.c
Compiling chsem.c
Compiling chmtx.c
Compiling chcond.c
Compiling chevents.c
Compiling chmsg.c
Compiling chdynamic.c
Compiling chmboxes.c
Compiling chmemcore.c
Compiling chheap.c
Compiling chmempools.c
Compiling chcore.c
Compiling chcore_v6m.c
Compiling osal.c
Compiling hal.c
Compiling hal_st.c
Compiling hal_buffers.c
Compiling hal_queues.c
Compiling hal_mmcsd.c
Compiling hal_pal.c
Compiling hal_usb.c
Compiling nvic.c
Compiling hal_lld.c
../../tmk_core/tool/chibios/ChibiOS-Contrib/os/hal/ports/KINETIS/KL2x/hal_lld.c:59:4: warning: #warning Please triple check your FSEC setting: KEYEN!=b10, MEEN==b10, SEC!=b10 leads to an unmodifiable chip. [-Wcpp]
#warning Please triple check your FSEC setting: KEYEN!=b10, MEEN==b10, SEC!=b10 leads to an unmodifiable chip.
^~~~~~~
Compiling hal_pal_lld.c
Compiling hal_serial_lld.c
Compiling hal_i2c_lld.c
Compiling hal_ext_lld.c
Compiling hal_adc_lld.c
Compiling hal_gpt_lld.c
Compiling hal_pwm_lld.c
Compiling hal_st_lld.c
Compiling hal_usb_lld.c
Compiling board.c
Compiling chprintf.c
Compiling memstreams.c
Compiling nullstreams.c
Compiling usb_main.c
../../tmk_core/protocol/chibios/usb_main.c: In function 'usb_event_cb':
../../tmk_core/protocol/chibios/usb_main.c:787:3: warning: enumeration value 'USB_EVENT_UNCONFIGURED' not handled in switch [-Wswitch]
switch(event) {
^~~~~~
Compiling main.c
Compiling kl27z_onekey.c
kl27z_onekey.c: In function 'matrix_is_on':
kl27z_onekey.c:67:27: warning: unused parameter 'row' [-Wunused-parameter]
bool matrix_is_on(uint8_t row, uint8_t col)
^~~
kl27z_onekey.c:67:40: warning: unused parameter 'col' [-Wunused-parameter]
bool matrix_is_on(uint8_t row, uint8_t col)
^~~
kl27z_onekey.c: In function 'matrix_get_row':
kl27z_onekey.c:73:37: warning: unused parameter 'row' [-Wunused-parameter]
matrix_row_t matrix_get_row(uint8_t row)
^~~
Compiling host.c
Compiling keyboard.c
Compiling action.c
../../tmk_core/common/action.c: In function 'debug_event':
../../tmk_core/common/action.c:555:29: warning: unused parameter 'event' [-Wunused-parameter]
void debug_event(keyevent_t event)
^~~~~
Compiling action_tapping.c
Compiling action_macro.c
Compiling action_layer.c
Compiling action_util.c
Compiling keymap.c
Compiling print.c
Compiling debug.c
Compiling util.c
Compiling hook.c
Compiling suspend.c
Compiling printf.c
Compiling timer.c
Compiling bootloader.c
Linking build/kl27z_onekey.elf
Creating build/kl27z_onekey.hex
Creating build/kl27z_onekey.bin
Creating build/kl27z_onekey.dmp
build/kl27z_onekey.elf :
section size addr
.cfmprotect 16 1024
.mstack 1024 536862720
.pstack 512 536863744
.vectors 192 0
.text 19748 1040
.rodata 2636 20788
.data 52 536864256
.bss 3160 536864768
.ram0_init 0 536867928
.ram0 0 536867928
.ram1_init 0 0
.ram1 0 0
.ram2_init 0 0
.ram2 0 0
.ram3_init 0 0
.ram3 0 0
.ram4_init 0 0
.ram4 0 0
.ram5_init 0 0
.ram5 0 0
.ram6_init 0 0
.ram6 0 0
.ram7_init 0 0
.ram7 0 0
.heap 27560 536867928
.ARM.attributes 45 0
.comment 110 0
.debug_info 169275 0
.debug_abbrev 27295 0
.debug_loc 35989 0
.debug_aranges 3360 0
.debug_ranges 5488 0
.debug_line 45973 0
.debug_str 18788 0
.debug_frame 9492 0
Total 370715
Creating build/kl27z_onekey.list
Done
tent:wq
Posted: 26 Jan 2017, 00:32
by tentator
yes I confirm, it shows "a" when I press the key

and bytheway no problems in flashing from my lenovo laptop running on powered dockingstation here.. instead if I try to do it when connecting it to a usbhub (really cheap chinese one) then it won't.. but I should really throw that hub away actually..
Code: Select all
10t8or@tentx MINGW64 /c/10t8or/Keyb/tmk_keyboard/keyboard/kl27z_onekey (master)
$ ./blhost.exe -u -V -- flash-image build/kl27z_onekey.hex
Inject command 'flash-image'
Wrote 192 bytes to address 0
Successful generic response to command 'write-memory'
(1/2)100% Completed!
Successful generic response to command 'write-memory'
Wrote 22452 bytes to address 0x400
Successful generic response to command 'write-memory'
(2/2)100% Completed!
Successful generic response to command 'write-memory'
- took 5.687 seconds
Response status = 0 (0x0) Success.
10t8or@tentx MINGW64 /c/10t8or/Keyb/tmk_keyboard/keyboard/kl27z_onekey (master)
$
10t8or@tentx MINGW64 /c/10t8or/Keyb/tmk_keyboard/keyboard/kl27z_onekey (master)
$ aaaaa
Posted: 26 Jan 2017, 07:42
by matt3o
yay! success!
I'll post a full tutorial soon! Also, the new boards won't have issues with any usb.
Posted: 26 Jan 2017, 08:52
by tentator
I'll test ps2 today trying to connect a trackpoint etc.
Posted: 26 Jan 2017, 11:26
by Dan
Why not the new USB-C connector? Is it more expensive to implement?
Posted: 26 Jan 2017, 11:32
by matt3o
excluded that because it is slightly bigger and wouldn't fit within the specifics
Posted: 26 Jan 2017, 12:49
by pomk
It's a lot more expensive part and we would have to use 4mil traces on the PCB as well making even that slightly more expensive
Posted: 26 Jan 2017, 21:33
by MrBishop
do all the pins on the USB side of the board do things? i see this as something that may cause issues or have the potential to make wiring those harder but not imposable. pinout please?
Posted: 26 Jan 2017, 23:34
by tentator
I do not see them as problematic to wire at all here from what I can see and test, these pins are anyway recessed compared to the usb that protrudes instead.
here the nice ascii pinout from hasu
Code: Select all
+ 39 ..... 44 \ conn / 1 ..... 6
+ 38 |______| LED 7
+ : Rst :
+ : :
+ 32 Bl 13
+ 31 .........24 23............ 14
Code: Select all
+ 1 PTD6 12 PTC3 23 GND 34 PTE20
+ 2 PTD5 13 PTC2 24 PTA18 35 PTA20 Reset
+ 3 PTD4 14 PTC1 25 3.3V 36 PTA3 SWD_DIO
+ 4 PTD3 15 PTC0 26 NMI 37 PTA0 SWD_CLK
+ 5 PTD2 16 PTB17 27 PTA2 38 3.3V
+ 6 PTD1 17 PTB16 28 PTA1 39 GND
+ 7 PTD0 18 PTB3 29 PTE25 40 VBUS VREGIN
+ 8 PTC7 19 PTB2 30 PTE24 41 USB D-
+ 9 PTC6 20 PTB1 31 PTE30 42 USB D+
+ 10 PTC5 21 PTB0 32 PTE29 43 GND
+ 11 PTC4 22 PTA19 33 PTE21 44 USB Shield
Posted: 26 Jan 2017, 23:40
by tentator
also consider that I now always do hand-wired keyboards using only insulated copper wire which I would suggest to anybody doing them since you really dramatically reduce and avoid shorts, maybe you can get different colored enameled copper wire if it would confuse too much if all wires are the same color then
like this down here:

- 2013-08-16+02_TrackPoint_annotated.png (176.93 KiB) Viewed 7384 times
Posted: 27 Jan 2017, 01:24
by pomk
Drew a graphical pinout diagram for the board.

Just need to swap the 3d model with a photo of the final production board.

- PINOUT.jpg (349.88 KiB) Viewed 7358 times
Posted: 27 Jan 2017, 02:54
by hasu
tentator wrote: I'll test ps2 today trying to connect a trackpoint etc.
How does it work?
IIRC, the controller has no 5V tolerant pin unfortunately and not useful for TrackPoint and keyboard converters. I was thinking about STM32F0 whose pins are 5V tolerant but it requires voltate regulator to get 3.3V

No perfect MCU meets all of our need
pomk, the diagram looks really nice and very useful.
matt3o, merged kl27z_onekey project into master branch and you can find here now.
https://github.com/tmk/tmk_keyboard/tre ... 27z_onekey
Posted: 27 Jan 2017, 08:02
by tentator
hasu wrote: tentator wrote: I'll test ps2 today trying to connect a trackpoint etc.
How does it work?
IIRC, the controller has no 5V tolerant pin unfortunately and not useful for TrackPoint and keyboard converters. I was thinking about STM32F0 whose pins are 5V tolerant but it requires voltate regulator to get 3.3V

No perfect MCU meets all of our need
pomk, the diagram looks really nice and very useful.
matt3o, merged kl27z_onekey project into master branch and you can find here now.
https://github.com/tmk/tmk_keyboard/tre ... 27z_onekey
Hi hasu yes I'm having difficulties so far but still trying.. do you think I could add some component in between the ps2 and the board to improve my chances?
Also about your merge to master are also the above patches for the additional parameter in chibios in there now? Would be great. Anyway wanted to tell you that I was able to compile and flash under Windows without other issues and official arm toolchain/compiler.
Kr
Tent:wq
Posted: 27 Jan 2017, 08:08
by tentator
pomk wrote: Drew a graphical pinout diagram for the board.

Just need to swap the 3d model with a photo of the final production board.
PINOUT.jpg
Nice!!
The pin 41 is USB- instead of + I think.. also I'd prefer a font that makes the number 1 character evidently different from a capital I or so what do you think?
Posted: 27 Jan 2017, 09:20
by matt3o
Excellent! Thanks!
@tentator, sorry, what is that you want to do with the PS2 again?
Posted: 27 Jan 2017, 10:26
by tentator
To connect a ps2 based trackpoint device for example.. one of those with pointing stocks like on lenovo or other laptops that would be in a keyboard project showing up between keys g h and B

Posted: 27 Jan 2017, 10:40
by matt3o
okay so is the problem that you don't have 5v? Can't you get it directly from the USB?
Posted: 27 Jan 2017, 10:48
by tentator
No I think the 5v pin number 40 should be fine to give good power to the trackpoint.. the problem is more about the clock and the data pins that any ps2 has and that the level of them is also 5v range so it might be that it is not coĆectly interpreted by the kl27z or even worse I might damage it.. so wondering if I could put some components in between data and clock i/o Pins before connecting them to the board.. but maybe I'll be lucky and the board is more tolerant than we think.. I'm still work in progress.. trying to first of all correctly reset the trackpoint board after power up now.. then let's see.. but any suggestion on components for level adjustments are welcome
Posted: 27 Jan 2017, 10:50
by tentator
This might also apply for those that might want to use this board as a converter like soars or similar but honestly that would be a waste because of the so many i/o and nice layout this board has..
Posted: 27 Jan 2017, 10:53
by tentator
I'd probably need something like this:
https://www.sparkfun.com/products/12009
But maybe there's something simpler?
Posted: 27 Jan 2017, 11:04
by matt3o
I was going to suggest something like that but wouldn't be easier to find a 3.3v stick?