TS65 - The Split 65% Keyboard

phosphorglow · 22 Mar 2016, 12:10

A somewhat simple idea just came to mind.

In my setup, I have a slide switch. The center pin goes to the 3.3V regulator input. One pole goes to the battery, and the other pole goes to USB 5V. USB 5V also runs through a 10K resistor to bring it to a safe voltage for the IO port (there's also a 40.2k pull-down resistor so it's not floating).

In TMK you can read the current host stack in use, i.e., bluefruit/rn42/USB. You can also read if USB has been configured (handshake?) even if it's not the active stack. So, I'm thinking something like this:

Spoiler:

There's probably an easier way of doing this, but it's an idea.

EDIT:
It's entirely possible I over complicated that, and it's probably not as feature rich as another solution...

EDIT AGAIN:
Nevermind. I'm back to the issue of the usb_init function freezing the keyboard input if bluetooth is active and you plug into a USB adapter. Forgot about that. The above could have been simplified to an 'if USB NOT configured, fast charge.' Nope.

phosphorglow · 22 Mar 2016, 13:09

Also, I forgot about this tidbit, but I believe USB spec is to limit the current draw to an HID device to 100ma, at least for USB 1.1. I think it got higher with later versions. *checks...*

Yup. Limited unless they're granted high power on request. Which I seem to remember reading that the USB specs aren't always adhered to. Ok. Time to walk away again.

mohitgarg · 22 Mar 2016, 14:12

Why do you have the slide switch? I'm still lost to it's purpose.

Here is what my current plan for the USB Charging looks like. By default, the device will charge the battery at 300mA (slow), and when on fast charge at 1A, like the example you provided, this would simply be done using a transistor to "enable" another resistor in parallel to increase the charge rate. I'm using MCP73833. No need for the complicated voltage reference and logic level shifting IMO.

: ChargeFlow.png (8 KiB) Viewed 6686 times

Slightly related, here is the flowchart for automatically turning on the backlight and RGB LEDs once the charging is done and to toggle them when on battery. USBDT, LEDBATDIS, BATSTAT are all interrupts to the AT90USB1286, so a change in USB state, switch toggle and battery status will automatically trigger the MCU to check whether to enable the LEDs or not. LEDs disable means 0% duty on PWM for backlight and black color on RGB LEDs.

: LEDFlow.png (17.77 KiB) Viewed 6686 times

phosphorglow · 23 Mar 2016, 23:01

Fantastic. That looks and sounds brilliant. I'll be implementing the first option... ;P

The switch was actually a remnant from the first design, which did not have the load sharing. It works since the controller and bluetooth module draw an average of 20ma, but I've learned it's not healthy for the battery. Considering when I first started using it I something like 90 hours of use, compared to 50 now.

I now see I can just have the switch between the battery and the mosfet.

Forgive me if you've already said so, but what size battery were you planning on using? 500ma will be the "safest" charge setting for my 1200mah battery.

phosphorglow · 23 Mar 2016, 23:11

Also, curious about your MOSFET choice. I keep coming back to the IRLML6401TRPBF since the RDS is so low but want to know if you've settled on anything better?

mohitgarg · 24 Mar 2016, 08:35

Regarding the switch, I'm assuming it's toggle Bluetooth? Have a look at my design (Will update it in a while) where I've used a pair of dipswitches to control the power and Bluetooth. One dipswitch toggles auto-disable-Bluetooth-on-USB. The second dipswitch, turns off the power to the system entirely by disabling the 3.3V regulator which is powering the whole system.

The system should ideally be powered by 1200mAh or higher, which means a safe charge rate of 840mA (0.7C is considered safe enough). I have my system right now to charge at 300mA and 800mA.

For the p-channel MOSFET, I'm using, PMV48XP, pretty low RDS(ON), should be around 50mohms or lower based on the spec sheet at the required voltage and current.

mohitgarg · 24 Mar 2016, 14:53

Hah, finally was able to wrap my head around the wireless, charging, and other aspects that had to be looked into. I think at this point, I can start to move into PCB design. The whole system is now running at 3.3V, only the trackpoint would require logic level shifting as most PS/2 trackpoints run at 5V logic.

I tested the WS2812B LEDs and they work fine at 3.3V, I got 32 of them running at full brightness with peak current of 160mA. I now have Teensy++ running at 8Mhz@3.3V with no problem, I am able to load EasyAVR assembled firmware and use it successfully as well as program the Teensy using Arduino IDE to run a string of RGB LEDs. Now to move onto implementing the various features in firmware.

I'll also be adapting this project to a 10-key pad to reduce prototyping costs and hopefully have something usable from the prototyping. Project will be name SAM Pad after the Sundstrand Adding Machine.

Here are the latest schematics (Please ask me lots of questions, so I can pickup as many corrections as possible):

phosphorglow · 26 Mar 2016, 01:48

All of the optional goodies sound so cool. I love modularity. ^_^

The only thing I can comment on is the ALE/HWB:
I *think* when you're pulling HWB to ground you need to run it through a resistor. At least every example I've seen, including the Teensy, does it that way.

(Also, I love the "SAM Pad" name.)

phosphorglow · 26 Mar 2016, 04:42

Oh! UVcc needs to be disconnected as well when running on 3.3V. Same page I previously mentioned in the datasheet. I don't remember exactly what issue I ran into with it connected off the top of my head, but it was enough to warrant desoldering my 1286 and cutting the trace to UVcc... I'll reconnect it later and let you know...

phosphorglow · 26 Mar 2016, 05:23

Yep. I knew there was a reason.

Things stop working when you leave VBus and UVcc connected while running on 3.3V. Definitely take the datasheet's advice on that one. I can verify that USB still works on 3.3V with it disconnected.

EDIT:
(If you're skimming through the posts, don't take my advice on this. It works fine as I explain later...)

phosphorglow · 26 Mar 2016, 05:30

However, to complicate matters, the schematic for the Teensy has UVcc and VBus connected, even when you're running it on 3V. This could be a matter of fuse settings with the Teensy vs. stock Atmel.

mohitgarg · 26 Mar 2016, 10:17

Regarding the HWBE, I think since in the Teensy, the HWBE ping is always grounded, it is connected via a resistor, in our case, it would be ground momentarily, thus a resistor is not needed. Still I'll throw in a 1k just to be safe.

About, the UVCC, I'm also confused by it, reason I went with it connected to VBUS is that on my Teensy++ it works fine. I am still using a 16Mhz crystal though, not sure if that would make a difference (Although I doubt it). One thing to be noted is, in my LUFA bootloader makefile, I have F_CPU set to 8Mhz, and F_USB set to 16Mhz. I've also changed the fuses on my Teensy to pretty much the stock fuses, although looking at the fuse bits, I don't really see a setting that would make a difference whether UVCC is connected to 5V.

phosphorglow, do you have a AVR programmer? Would you be so kind as to share your schematics via PM, so we can trouble shoot this, and map out the differences and what might be causing the variance

Phenix · 27 Mar 2016, 16:54

This is an really interesting project. Please keep on posting, hopefully there will be an groupbuy!

phosphorglow · 29 Mar 2016, 22:10

Ahhhhhh... I've figured it out. Sorry for the late reply, been busy and then I started making a spreadsheet of what happens with various things connected/disconnected/8 vs 16MHz xtal... and then it dawned on me:

When running on 3.3V, UVcc gives out 3.25V which gets fed to the USB 5V pin. Which, in my scenario, is connected to a pull down on an IO pin so I can test for USB connection at startup. Which is convenient for my setup, since it's the simplest thing I can wrap my mind around at the moment.

Switch Off:
- USB plugged into computer/USB gets configured: works as USB keyboard and charges at 400ma.
- USB plugged into adapter, does not get configured and changes charge rate to 1A.

Switch On:
- BT enabled. Can plug USB into computer or adapter but will charge at 400ma only.
- (BT gets enabled if input pin stays low. Turns on transistor.)

Which is why I like the idea of keeping my switch. There are definitely more advanced ways of doing this, but I'm aiming for relative simplicity.

So! UVcc + VBus connected does indeed work. Just not for me in this scenario.

On another note though, is the ability to flash using a 16MHz xtal on 3.3V. It may work on the Teensy, but it certainly does not work for me.

phosphorglow · 29 Mar 2016, 22:21

To elaborate on the inability to flash on 3.3v using 16MHz XTAL, I tried a few different combinations:

Code: Select all

XTAL 	          Uvcc	Vbus	Ucap
		
	16Mhz	       x	 5v	3.3
	16Mhz	       5v	5v	cap to gnd
	16Mhz	       5v	5v	3.3
	16Mhz	       x	 5v	cap to gnd

All of which result in a failed flash. Perhaps it comes down to different properties of the xtal in the teensy vs. what I'm using?

phosphorglow · 29 Mar 2016, 22:40

And another curiosity:

What's with the move of the TrackPoint data/clock to C5 and C6? All of the PS/2 converter code I've seen uses interrupt or USART. I'm confused and intrigued.

phosphorglow · 30 Mar 2016, 03:12

And where did you get the USB-C connector footprint? I picked up that same hybrid connector my last Mouser order to see if it was remotely feasible to hand solder. It looks like it is and I want to try. (I finally started playing with KiCad, by the way...)

phosphorglow · 30 Mar 2016, 07:31

Back to the 3.3V/16MHz flashing issue. I remembered a tidbit from last year, and hasu was so kind as to run a test:

hasu wrote: ↑I tested with Atmel USBKEY board which has AT90USB1287 powered with 3.3V and 8MHz. I replaced the crystal with 16MHz and it doesn't work! against my expectation. Hmm, It looks like AT90USB128's bootloader doesn't work with 16MHz when it is powered with 3.3V unfortunately.

Meanwhile, ATMega32U4's bootloader works with 16MHz even under 3.3V power.

So! You've changed fuse settings, but are you still using the HalfKay bootloader?

flabbergast · 30 Mar 2016, 09:32

@phosphorglow: There should always be a 1uF cap on the VCAP line when you're using USB (datasheet says). It is the output from the internal 3.3V regulator and needs to be stabilised. {On these AVR chips that have USB, there is an internal regulator capable of doing 50mA. They need to have a source of 3.3V because that's what D+/D- lines run on.}

Also - I do not understand from your posts what does "flashing" mean - using a bootloader? AVR ISP? Which bootloader?
The bootloaders need to know in advance how fast is the crystal. It does not (well, should not) matter on which voltage the MCU runs, as long as the chip is not too overclocked to fail. It is possible for the MCU to figure out the voltage it's powered with (using the internal bandgap reference) and then adjust its crystal frequency expectation, but I highly doubt the ATMEL's DFU bootloader does this. Certainly LUFA bootloaders don't. Halfkay doesn't.
So, rule of thumb: if you replace the crystal, the bootloader stops working and needs to be reflashed.

BTW this guy (Justin Mattair) has a "correctly" (i.e. in accordance with 32u4 datasheet) wired atmega32u4 breakout: https://www.mattairtech.com/index.php/d ... tible.html
My point is in the manual to that board, page 12, he explains which pins are inputs and which are outputs in the respective power configurations: http://www.mattairtech.com/docs/MT-DB-U4_User_Guide.pdf

mohitgarg · 30 Mar 2016, 10:17

Thanks for the investigative work phosphorglow. I'm using the Teensy++ (AT90USB1286) with more or less default Atmel fuse bits, 16Mhz crystal, 3.3V. Tested LUFA DFU, LUFA Mass Storage, Atmel factory and all three work fine. I'm assuming HalfKay would work out of the box with a 3.3V regulator, as it's documented on the PJRC site to work. Firmware has been compiled for 8Mhz by setting F_CPU.

About detection of USB, why not connect your detection pin to 5V from USB via a resistor divider to get 3.3V for detection. Default state will be pull down. So if it's high, that means charging can be enabled, just choose at what rate based on if USB is configured or not.

Regarding the PS/2 connections, check this post by plainberry: https://geekhack.org/index.php?topic=55 ... msg1291412, he used pins PD5 and PD4, which worked. Although now that you have mentioned it, I think maybe the PD5 pin must be used for CLOCK, since I'm just using them for indicator LEDs, I'll change that just to be safe. His configuration works, so hopefully that won't be an issue.

I made the footprint for the USB Type C hybrid myself. You can download it from my TS65ARM repo.

Thanks flabberghast, I had a look at the schematic, looks like I'm on the right path, power management seems to be configured correctly.

phosphorglow · 30 Mar 2016, 10:30

@flabbergast

Yup, 1uF on UCap like the datasheet says, regardless of 3.3V or 5V operation. However, in 3.3V self-powered applications they say to also connect the externally regulated voltage to UCap. And to disconnect UVcc, but it works either way (for example the Teensy).

: 1286-self powered.jpeg (37.25 KiB) Viewed 6458 times

: 1286-bus powered.jpeg (41.53 KiB) Viewed 6458 times

As far as "flashing" I mean putting the controller into DFU mode and flashing a .hex to it.
I'm using stock Atmel DFU and fuse settings on a 1286.

At 3.3V operation as connected in the datasheet, I cannot flash a hex using a 16MHz XTAL. hasu tried the same thing on a USBKEY with a 1287 (also Atmel DFU) and got the same result. 8MHz XTAL at 3.3V flashes just fine though.

phosphorglow · 30 Mar 2016, 10:54

@mohitgarg

Well, there goes the DFU theory. If all three of those work for you at 16MHz and 3.3V then I'm rather confused. Still. And to further complicate things, the controller will run previously flashed code on a 16MHz XTAL... just not flash...

Anyways, at this point it's probably not important. I'll continue using my 8MHz XTAL, and hopefully everything stays functional for you! Perhaps the HC49 XTAL becomes unreliable at 3.3V and a lower frequency...? No clue.

As for the Trackpoint, I think the USART code in TMK is the recommended choice since the busywait and interrupt took too many cycles? They work, though.

And thanks for the hybrid footprint! I think it'll be fun to try by hand. Should be interesting!

mohitgarg · 30 Mar 2016, 11:02

I'll flash the Atmel DFU today and try to program a firmware on it later again today on my setup, maybe I missed something last time.

I still fail to understand (Much like how hasu was surprised) why on 3.3V an external 16Mhz crystal would not work with the Atmel DFU, whereas the LUFA bootloaders, HalfKay work fine.

phosphorglow · 30 Mar 2016, 11:14

Oh!

About detection of USB, why not connect your detection pin to 5V from USB via a resistor divider to get 3.3V for detection. Default state will be pull down. So if it's high, that means charging can be enabled, just choose at what rate based on if USB is configured or not.

That's precisely how it's connected if I'm reading that correctly. I may have yammered too much to have explained it coherently. ;P

: 2016-03-30 05.06.29.jpg (11.45 KiB) Viewed 6431 times

(Which, if UVcc is connected, tosses voltage right into the 5V pin, hence my issue.)

I'll flash the Atmel DFU today and try to program a firmware on it later again today on my setup, maybe I missed something last time.

I still fail to understand (Much like how hasu was surprised) why on 3.3V an external 16Mhz crystal would not work with the Atmel DFU, whereas the LUFA bootloaders, HalfKay work fine.

I just looked at the datasheet for the USBKEY board he tried it on, and the schematic says it's using a HC49 XTAL, and it's rather likely hasu used a similar replacement. That's the only theory I have left and I'm not sure if it's even a good one.

phosphorglow · 30 Mar 2016, 11:19

Wow. Or if I just take a second to glance at the first datasheet of an HC49-similar XTAL on google, I'd see that the minimum frequency is 3.57 MHz. I bet it's the same for the ones we use(d).

DIV8 would be expecting 2MHz.

*facepalm*

phosphorglow · 30 Mar 2016, 11:24

Hah! It sure is.

Boy do I feel silly.

phosphorglow · 30 Mar 2016, 11:42

Well, I feel less silly, but I'm back to being perplexed... Minimum frequency on the 8MHz is the same rating, but it works.

I think I'd prefer feeling silly and actually getting somewhere.

mohitgarg · 30 Mar 2016, 12:01

phosphorglow wrote: ↑Oh!
2016-03-30 05.06.29.jpg
(Which, if UVcc is connected, tosses voltage right into the 5V pin, hence my issue.)

That is what I mean, but I don't understand what you mean when you say, "if UVcc is connected, tosses voltage right into the 5V pin".

phosphorglow · 30 Mar 2016, 12:41

In the self powered example, UVCC is disconnected. It measures 3.25V.

When it's connected, it feeds that voltage to VBUS.

...which pulls my USB detection input high.

mohitgarg · 30 Mar 2016, 12:48

Still, don't understand

Probably have to see the complete schematic, looks like I'm missing something.