Author Topic: Alternative controller experiments  (Read 11066 times)

0 Members and 1 Guest are viewing this topic.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Alternative controller experiments
« on: Thu, 11 September 2014, 07:05:21 »
So, I'd like to start experimenting with completely custom controllers, primarily because stock on Atmega32u4s is quite low, and also because there's some nice possibilities with simple inter-chip communication on some of the other chips that might make for some interesting ergodox or modular keyboard implementations. Also, I'd like to think I have my head around AVRs well enough that branching out should be educational. At the moment, I'm going about this the hyper-minimal way, ie no spending money on standalone programmers or whatnot, until I have some idea of which chip I'd like to go with for a keyboard design I have been kicking around.

This will be a (somewhat slowly updated, I'm afraid) build log of sorts that documents my attempts to get up and running with Microchip's PIC and Freescale's Kinetis lines.
So far, I've successfully requested some samples from both companies, namely:
MK22DX256VLF5
MK22FN1M0VLH12
MKL26Z128VLH4
from Freescale (All Kinetis 32-bit ARM MCUs, 50-120Mhz)
and
PIC32MX220F032D
PIC32MX230F064D
from Microchip (40Mhz 32-bit)

Given that these are all SMT parts I've started to fit them to breakouts that can be hooked up with jumpers. This was my first two attempts at drag soldering and I have to say, it was pretty damn easy.


MK22FN1M0VLH12 (QFP-64)

PIC32MX220F032D (QFP-44)

I was originally under the impression that the K22FN1 pictured above actually had a one-time-use bootloader pre-programmed into it, so I put together the following little adapter board to use it over a serial transport which the documentation indicated was possible. Unfortunately it doesn't seem to respond when connected in this fashion, leading me to think that I probably misread the docs, especially seeing as when I went back into them I couldn't find anything claiming they were pre-loaded with a bootloader.


Fortunately Kinetis devices also support EzPort which is a subset of SPI that can be used to flash chips. I'm currently looking for some documentation showing a minimal circuit for this initial flashing, especially given that I can't be 100% sure I wasn't missing something from the minimal configuration on the test board above.

I've managed to locate a few minimal breadboard setups for the PIC and an app to use an AVR as a PIC programmer, (apparently I could probably also use my Raspberry Pi) so will give that a try and update when I have more to show for it.
Anybody else tried anything like this? I'd be curious to hear what people have done.

Offline margo baggins

  • Dungeon Dweller
  • * Maker
  • Posts: 305
  • Location: Brighton - United Kingdom
  • Get back to work!
Re: Alternative controller experiments
« Reply #1 on: Thu, 11 September 2014, 10:23:06 »
This is a cool thread.

Drag soldering is really easy isn't it - lots easier than you would think it to be. To be honest, I much prefer drag soldering IC's like you have done above to using hot air and paste on them. As normally for smt work I like to use air + paste.
I got boards.



Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #2 on: Thu, 11 September 2014, 14:57:05 »
Thanks Margo.
I don't want to jump for joy too much just yet until I actually see the MK22F doing something and can confirm I didn't botch the job somehow :P I've looked over it with a magnifying glass and can't see any visible bridging or anything like that, but until I get that minimal circuit up and running I won't be 100% confident yet. HaaTa posted on my DT thread about some work he's done with the Kinetis line, so I'm hoping he'll be able to help out, otherwise it might take some prodding of my local distributor to see if they can chase down the relevant information for me.

The PIC32MX was 0.8mm rather than 0.5mm pitch, so it is much easier to visually assess, so here's hoping I can get something working with it asap. PIC also make a 18F4550 chip which has USB in a through-hole package, something that I've rarely seen with enough pins to make a full 110% controller, so I may mess around with one of those too - a controller design that works with through-hole parts will be that much easier for novices to build and use.

Offline dorkvader

  • Posts: 6282
  • Location: Boston area
  • all about the "hack" in "geekhack"
Re: Alternative controller experiments
« Reply #3 on: Fri, 12 September 2014, 09:42:57 »
This is a cool thread.

Drag soldering is really easy isn't it - lots easier than you would think it to be. To be honest, I much prefer drag soldering IC's like you have done above to using hot air and paste on them. As normally for smt work I like to use air + paste.
I'm still to scared to try it. I always solder each pin individually.

--
I thought one main reason we use the atmega 32u4 for is that it has hardware USB support or something?

I do know bpiphany and the hid liberation devices for costar use a smaller chip and some expanders (atmega 32u2 I think?) so this is a well-known design.



Offline berserkfan

  • Posts: 2136
  • Location: Not CONUS Not CONUS Not CONUS Not CONUS
  • changing diapers is more fun than model f assembly
Re: Alternative controller experiments
« Reply #4 on: Fri, 12 September 2014, 11:39:27 »
So, I'd like to start experimenting with completely custom controllers, primarily because stock on Atmega32u4s is quite low, and also because there's some nice possibilities with simple inter-chip communication on some of the other chips that might make for some interesting ergodox or modular keyboard implementations. Also, I'd like to think I have my head around AVRs well enough that branching out should be educational. At the moment, I'm going about this the hyper-minimal way, ie no spending money on standalone programmers or whatnot, until I have some idea of which chip I'd like to go with for a keyboard design I have been kicking around.

This will be a (somewhat slowly updated, I'm afraid) build log of sorts that documents my attempts to get up and running with Microchip's PIC and Freescale's Kinetis lines.
So far, I've successfully requested some samples from both companies, namely:
MK22DX256VLF5
MK22FN1M0VLH12
MKL26Z128VLH4
from Freescale (All Kinetis 32-bit ARM MCUs, 50-120Mhz)
and
PIC32MX220F032D
PIC32MX230F064D
from Microchip (40Mhz 32-bit)

Given that these are all SMT parts I've started to fit them to breakouts that can be hooked up with jumpers. This was my first two attempts at drag soldering and I have to say, it was pretty damn easy.

Show Image

MK22FN1M0VLH12 (QFP-64)
Show Image

PIC32MX220F032D (QFP-44)

I was originally under the impression that the K22FN1 pictured above actually had a one-time-use bootloader pre-programmed into it, so I put together the following little adapter board to use it over a serial transport which the documentation indicated was possible. Unfortunately it doesn't seem to respond when connected in this fashion, leading me to think that I probably misread the docs, especially seeing as when I went back into them I couldn't find anything claiming they were pre-loaded with a bootloader.
Show Image


Fortunately Kinetis devices also support EzPort which is a subset of SPI that can be used to flash chips. I'm currently looking for some documentation showing a minimal circuit for this initial flashing, especially given that I can't be 100% sure I wasn't missing something from the minimal configuration on the test board above.

I've managed to locate a few minimal breadboard setups for the PIC and an app to use an AVR as a PIC programmer, (apparently I could probably also use my Raspberry Pi) so will give that a try and update when I have more to show for it.
Anybody else tried anything like this? I'd be curious to hear what people have done.

Twiddle, while you're at it, may I respectfully urge you to find a few chips with many pins that can handle really big keyboard matrices? The two photos of your square chips look as though they have many pins but of course as an ignorant untrained person I have no idea how many of their pins can actually be used for hooking up keyboard matrices.

One of the big problems with teensy and atmega is their limited number of pins.
Most of the modding can be done on your own once you break through the psychological barriers.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #5 on: Fri, 12 September 2014, 12:10:54 »
My original black widow has 6x22 keys including the macros, so 27-28 GPIO pins was the minimum I set when looking for parts.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #6 on: Fri, 12 September 2014, 12:14:39 »
I thought one main reason we use the atmega 32u4 for is that it has hardware USB support or something?

All the chips I received as samples also have hardware USB support. It was a primary prerequisite while I was searching for potential chips, I don't want to have to overcomplicate things by dealing with V-USB or something similar on top of everything else.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #7 on: Sun, 14 September 2014, 18:35:55 »
Good news:
Code: [Select]
init
Initializing EzPort
SPI/EZPort enabled
>verify
Sending rsdr command...
EzPort status flags = 0
enabling write
Sending rsdr command...
EzPort status flags = 10
disabling write
Sending rsdr command...
EzPort status flags = 0
>

Success with the K22F (the above snippet is me successfully enabling, then disabling, writing to the on-chip flash, i.e. enabling the chip's in-circuit programming functionality).

I built a little adapter board to break out the SPI/EzPort header and create a socket I could plug the breakout onto for the programming:


It's being driven by a Arduino Leonardo clone via a bit-banged connection.

The cause for the trouble I was having: SPI is a synchronous protocol, i.e. data is sent and received at the same time.
However, I was trying to read the response to my status register query within the same send/receive cycle.
If you think about it, what I was trying to do was expect the chip to know what I was asking it and start responding before I finished asking. Herp derp. Adding a second tx/rx cycle (send dummy data, keep the received data) after the first command worked.

Bonus shot of the custom switch tester I'll be using with the MCU when it's flashed:


Offline berserkfan

  • Posts: 2136
  • Location: Not CONUS Not CONUS Not CONUS Not CONUS
  • changing diapers is more fun than model f assembly
Re: Alternative controller experiments
« Reply #8 on: Mon, 15 September 2014, 06:17:45 »
don't tell me you have even built LED support on that one!

you bought it from wonderco on ebay right?
Most of the modding can be done on your own once you break through the psychological barriers.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #9 on: Mon, 15 September 2014, 06:41:04 »
don't tell me you have even built LED support on that one!

you bought it from wonderco on ebay right?

http://www.ebay.com/itm/1-pc-White-Keyboard-5x5-keys-5-keys-Metal-Panel-/130541363513?

Guessed right!

No LEDs, no, just using caps from my black widow as they're the only spares I have at the moment, until the 4 group buys I've got come in :)

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #10 on: Wed, 24 September 2014, 21:08:15 »
Just a small update - I grabbed one of the FRDM Development boards and started to wrap my head around the development tools.



Successfully got the keypad wired up to the board and ran some tests with it - I've got it working but need to figure out how best to handle repeat delay and so on.
The abstraction that I was using in Kinetis Design Studio is naive and doesn't really have support for keys being held down, so I'm going under that to use the raw USB HID API calls (which is good because I was eventually going to want to do that anyway).

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #11 on: Mon, 02 March 2015, 06:27:00 »
Just a short update:
I finally have a custom circuit working:


This is a 50MHz ARM micro  (LPC11U35) with onboard USB including USB-drag-and-drop programming.
First board had a few problems, but still works ok. Gonna redo a fixed prototype then send off to Dirtypcbs for a two-layer more compact revision.
Finally making some more substantial progress!

Offline CPTBadAss

  • Woke up like this
  • Posts: 14305
  • Location: CT, USA
  • Rich Homie Huang.
Re: Alternative controller experiments
« Reply #12 on: Mon, 02 March 2015, 06:54:26 »
Just wanted to drop in and say that even though I don't know a lot about EE and circuits, I'm glad you posted this. I'm learning a lot :).
Please check out TactileZine.com!

Offline hasu

  • Posts: 2993
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative controller experiments
« Reply #13 on: Mon, 02 March 2015, 11:21:40 »
Nice work!
I've been thinking about develop my recipe of home made PCB but I'm lazy and usually wait for Fusion PCB to get my boards back to me for nothing :D

I also worked on LPC11u35 and Kinetis MK20 to port my firmware using mbed.org CMSIS/HAL codes with (offline) GCC toolchain. I prefer those setup to leanring vendor's specific IDE for each chip. (I've not even try any IDE so I can't say about its usefulness, though.)

keep us updated!
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #14 on: Mon, 02 March 2015, 13:34:02 »
Funny you should mention CMSIS, hasu... Thats pretty much exactly what I was intending on doing. I want to see if I can get a common firmware that would work for Kinetis/Freescale, LPC, and STM parts, but I was intending to perhaps prototype with mbed and then actually create a simple HAL so that others would be able to implement a handful of functions in order to port it to other chips. mbed itself is simple and easy to use like the arduino libraries, but part of the reason for doing this is for me to actually learn the underlying registers and so on - not so much the vendor IDE, but at least the basics of each vendor's approach to low level code.
I hear you on Fusion or DirtyPCB etc - but they are so slow.. I don't want to pay $30 or so to get a bunch of PCBs and have to wait 2-3 weeks for them to arrive unless I *know* that the design works. The shipping times for any of those services to Australia kills any chance of doing rapid iteration unless I want to pay a fortune in shipping. Now that I know the fundamentals of my design work, I'll do a second prototype with the issues fixed, then I will send off to a fab. I don't mind waiting for them when I am certain that they'll work. :P

CPTBadAss - This project is really the first time I put serious effort into learning about either of those things, myself. I tend to learn better by picking a project and just doing stuff rather than doing a ton of reading up beforehand. Unfortunately tools costs have somewhat blown out the primary advantage of the ARM chips (I mean, to give you an idea, that 48Mhz ARM chip in the photo is under $2 when bought individually), all up I've probably spent $400 getting to the point where I am.. I eventually want to make everything freely available, but I am hoping to sell a few of the custom controllers when they are ready to recoup that cost.

Offline vvp

  • Posts: 803
Re: Alternative controller experiments
« Reply #15 on: Mon, 02 March 2015, 14:54:00 »
Nice. Looks like LPC11U35 is a good option. It is 3 cents cheaper than ATxmega128a4u I used. I'll probably try some ARM next time too :)
I went with atxmega because it is easy to port a LUFA firmware from ATmega32u4 to it. And I also have some use for DAC which is missing on your ARM.

Offline hasu

  • Posts: 2993
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative controller experiments
« Reply #16 on: Mon, 02 March 2015, 16:03:46 »
LPC11U35 is that cheap? Can you refer to source of the price?

I cannot find any supplier with that good price on the net.
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #17 on: Mon, 02 March 2015, 16:29:24 »
LPC11U35 is that cheap? Can you refer to source of the price?

I cannot find any supplier with that good price on the net.

Sorry, I just went back over my invoices - they were $2.25 AUD each at the time, now more like $2.50 due to the AUD->USD dropping.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #18 on: Mon, 02 March 2015, 16:35:08 »
Mind you, quantity of both that and the 33-QFN package looks to be very low. perhaps the price is dropping because they are trying to sell out of old packages - other distributors have prices more around the $4-6 range from what I can tell.


Also... Freescale and NXP just announced a merger, this is going to be interesting.

Offline hasu

  • Posts: 2993
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: Alternative controller experiments
« Reply #19 on: Tue, 24 March 2015, 12:15:43 »
I got Nuvoton NUC120(M0/8KB RAM/64KB flash/USB)chips at $0.5 from verical.com :D

FYI, I happened to find verical offers free international shipping now. It seems you can checkout with DHL for free regardless of amount.
TMK products:HHKB Alt  ⌨ConvertersAlps64FC660C AltFC980C Alt

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #20 on: Mon, 25 May 2015, 06:58:55 »
Right, so bit of an update after going dark a couple months.. First bit of news is I have my first fully custom hardware prototype ready for firmware development:



So this one is based on the STM32F373 mcu, for no real reason than it happened to be the first PCB I finished laying out and sending off to the fab (Smart Prototyping).





As it stands now it supports DFU for updating the firmware, meaning that I can use DFU-util 's code to make an update utility that is cross-platform, but I will probably implement some sort of HID-based system for reprogramming the keys if I can. I also realised that my custom SWD header was laid out wrong, so I'll probably do a v2 with that fixed so I can use my J-link to debug the firmware, as I expect that the in-app flash writing functionality will require some fiddling, and that is assuming I get the USB stuff working without any problems.
 
I'm in the process of writing the initial USB implementation, and putting the touches on some LPC and Freescale dev boards as well - eventually I'd like to be able to get the same USB codebase running across all three families of chip, so I can start to exploit the competition between the different manufacturers, and potentially also take advantage of things like the drag-and-drop functionality from LPC, the integrated USB vbus voltage regulator on Kinetis, etc.. Really hope to drive the cost of our keyboard controllers down even below things like the Teensy (without the JTAG/SWD header and the reset/bootloader buttons, estimated cost of parts for one of these is ~S10 AUD when buying parts individually, so a group buy would drop it below that).

More photos:
http://imgur.com/a/eZmPh
 (I tried to show off the soldering job a bit, given that its all done by hand and I hope to convince more people hand soldering SMT parts isn't nearly as difficult as they might think - the smaller capacitors there are 0603 - 1.6 mm ◊ 0.8 mm, and with tweezers they aren't too bad.)

Offline vvp

  • Posts: 803
Re: Alternative controller experiments
« Reply #21 on: Mon, 25 May 2015, 15:36:50 »
(I tried to show off the soldering job a bit, given that its all done by hand and I hope to convince more people hand soldering SMT parts isn't nearly as difficult as they might think - the smaller capacitors there are 0603 - 1.6 mm ◊ 0.8 mm, and with tweezers they aren't too bad.)
I second that. Here is another example of home made stuff. This time even the PCB is home made. You can still see flux around the TQFP-44 package. That is a bit bigger than twiddle's LQFP package (at least I think it is LQFP :) ). Lead free solder. The smaller capacittors and the resistor are 0603 too.
101693-0

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #22 on: Mon, 25 May 2015, 15:42:18 »
Thats a really nice home-made PCB vvp.
I would rather do the PCBs at home for testing purposes but my laser printer is a Brother with toner that has a rather high fusing temperature, which makes toner transfer extremely inconsistent.. Bit hard to justify the $100-150 for a mono laser *not* using similar toner at the moment, when that would get me 10-15 sets of 10 boards from the fab.
I'd like to do more home prototypes using UV exposure, but that looks like it would cost me just as much.

Offline berserkfan

  • Posts: 2136
  • Location: Not CONUS Not CONUS Not CONUS Not CONUS
  • changing diapers is more fun than model f assembly
Re: Alternative controller experiments
« Reply #23 on: Mon, 25 May 2015, 21:02:00 »
Would it be possible to make this smaller in future? The way I see it, this would probably be fine on the keyboards I use, such as Tipro, Model F, Deck Legend. There are enough pins, and there is enough space in the casings.

However, the vast majority of geeks like JD40, 60% boards and TKLs. There isnít enough space in their casings for a controller like yours. It looks much bigger than a teensy.

Or else you could do two iterations, one for the Battleship Lovers, GH144 and other big vintage keyboards, and one for the common geek, ie TKL and smaller.
Most of the modding can be done on your own once you break through the psychological barriers.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #24 on: Mon, 25 May 2015, 22:08:24 »
Would it be possible to make this smaller in future? The way I see it, this would probably be fine on the keyboards I use, such as Tipro, Model F, Deck Legend. There are enough pins, and there is enough space in the casings.

However, the vast majority of geeks like JD40, 60% boards and TKLs. There isn�t enough space in their casings for a controller like yours. It looks much bigger than a teensy.


If those are being hand-wired then I would think you'd have plenty of room  - are you talking about replacing the existing controllers on boards in the JD/60%? If so, then yes there'll definitely be ways to compress things. For one, there's a lot of IOs that I break out on this board-  about 30. This could be reduced (I dont see anybody using a 15x15 matrix, though i'm sure somebody will post a photo here to correct me lol). The JTAG header can be removed, the buttons replaced or removed, some components moved to the opposite side of the board and the I/O headers pulled in closer.
This was simply a test to verify the hardware design (this being the first time I did a design with STM32 )and give me something to develop the firmware with - I actually intend to eventually make full PCBs with the chip as an onboard controller.

Oh, and a quick edit to note that some MCUs don't need a crystal and some can also perform the 5v-> 3v3 regulation themselves (for example the KL26 series I think from Freescale, similar to what's used on the teensy) so that will drop the board size further.
« Last Edit: Mon, 25 May 2015, 22:19:20 by twiddle »

Offline vvp

  • Posts: 803
Re: Alternative controller experiments
« Reply #25 on: Tue, 26 May 2015, 04:02:45 »
I and kko made about 10 PCBs at home so far and all except the first one turned out well. The problem with the first one was that we left it in the etching solution for too long. And we also used an expensive, thick, glossy photo paper for laser printers. It was hard to rub it off and it was hard to heat the toner through the papaer when ironing. A cheap thin glossy papaer from an old electronic part catalog works much better. The toner does not always transfer perfectly over the whole area. Often we find small areas where id did not stick well. These can be corrected with a permanent marker. Before transfering, it is important there are no oils (fingerprints) on the printed cicuit on paper as well as on the PCB. The only printers we tried are HP LaserJet 1200 and Xerox Phaser 6280DN. Both work fine. Just setting them to the highest quality and the highest toner density does it.
I would like to use UV exposure too. Based on reporst from internet, the results should be more consistent and the feature size can be smaller. All the stuff except the transparent foils is already bought. I'll report the results when I'll make a PCB this way.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #26 on: Tue, 26 May 2015, 04:18:06 »
I have been using press and peel, as well as the thin glossy paper too.
My issue is that the brother toner requires much more heat than other sorts, meaning that I've had to at times use up to 20 minutes of heating to get the toner to transfer well. This works somewhat okay with press-and-peel, but for the glossy paper it tends to make the waxes in the paper bond to the toner, and the paper is then really hard to remove and interferes with the etching process. Using an iron still means that about half of my press-and-peel attempts aren't much good, though, because of the difficulty ensuring even heating.
A laminator that could take ~2mm thick items might help but its difficult to justify spending the money for one when *all* I would ever do is use it for PCBs and I have no guarantee it would be an improvement over what I have.

Another thing I always forget is that small vias are very difficult to do at home - the cost of low-runout drill spindles and bits seems prohibitive, one-sided boards and jumper wires will only get you so far with things like USB traces, where impedance matching is critical.

I'd love to be able to more rapidly iterate on hardware designs by doing more PCBs at home, though.

I did look into the TwinTeeth PCB fab - the only issue with it was the working area is rather small. Still pondering options, am curious about other options ala CNC or laser UV exposure, but seeing as CNC is very fiddly at such small sizes without spending a lot, and Smart-Proto guys have pricing that is so good and they'll let me panelize multiple designs on the cheap, I am likely to stick with them while I develop the hardware.
(might it be worth us taking this discussion over onto the PCB thread?)

Offline vvp

  • Posts: 803
Re: Alternative controller experiments
« Reply #27 on: Tue, 26 May 2015, 05:45:23 »
(might it be worth us taking this discussion over onto the PCB thread?)
I responded there: https://geekhack.org/index.php?topic=48851.msg1758827#msg1758827

Offline CRi

  • Posts: 2
  • Location: Belgium
Re: Alternative controller experiments
« Reply #28 on: Tue, 26 May 2015, 07:11:38 »
So, I'd like to start experimenting with completely custom controllers, primarily because stock on Atmega32u4s is quite low, and also because there's some nice possibilities with simple inter-chip communication on some of the other chips that might make for some interesting ergodox or modular keyboard implementations. Also, I'd like to think I have my head around AVRs well enough that branching out should be educational. At the moment, I'm going about this the hyper-minimal way, ie no spending money on standalone programmers or whatnot, until I have some idea of which chip I'd like to go with for a keyboard design I have been kicking around.

This will be a (somewhat slowly updated, I'm afraid) build log of sorts that documents my attempts to get up and running with Microchip's PIC and Freescale's Kinetis lines.
So far, I've successfully requested some samples from both companies, namely:
MK22DX256VLF5
MK22FN1M0VLH12
MKL26Z128VLH4
from Freescale (All Kinetis 32-bit ARM MCUs, 50-120Mhz)
and
PIC32MX220F032D
PIC32MX230F064D
from Microchip (40Mhz 32-bit)

This is really interesting, I've had that same goal in my mind for some times now.
I wanted to use Microchip micro-controllers because I already have an ICD programmer/debugger and some PIC32 micro-controllers and dev boards.
I also would like to implement an advanced backlight controller with per-key RGB lighting.

But when I look at firmware like TMK, I wonder if it is really worth it?
I mean, that would be a lot of work to just match the features of that firmware...
And everyone seems to be using AVR microcontrollers, would people be really interested by another controller?

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #29 on: Tue, 26 May 2015, 07:25:25 »
twiddle: is your code anywhere public yet?

Offline berserkfan

  • Posts: 2136
  • Location: Not CONUS Not CONUS Not CONUS Not CONUS
  • changing diapers is more fun than model f assembly
Re: Alternative controller experiments
« Reply #30 on: Tue, 26 May 2015, 10:14:38 »
I do hope you can make a much smaller version without sacrificing the number of pads. I believe LEDs are the way to go, and many of these geeks will want to control the leds on their boards. Even an old man like me has gotten interested in LED controls after realizing that they help me to use a keyboard in fairly low lighting.
Most of the modding can be done on your own once you break through the psychological barriers.

Offline vvp

  • Posts: 803
Re: Alternative controller experiments
« Reply #31 on: Tue, 26 May 2015, 12:02:49 »
But when I look at firmware like TMK, I wonder if it is really worth it?
I mean, that would be a lot of work to just match the features of that firmware...
You may not need to build it from scratch. Just port some existing firmware. It may turn out to be very easy. E.g. I was porting chrisandreae's firmware from atmega to atxmega (which has a different way to access IO) and it was no proglem at all. Just an LUFA update did it.
Notice that twiddle wants to base the firmware on mbed. It should be easy to port to any chip supported by mbed. That is rather cool.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #32 on: Tue, 26 May 2015, 13:16:43 »
This is really interesting, I've had that same goal in my mind for some times now.
I wanted to use Microchip micro-controllers because I already have an ICD programmer/debugger and some PIC32 micro-controllers and dev boards.
I also would like to implement an advanced backlight controller with per-key RGB lighting.

But when I look at firmware like TMK, I wonder if it is really worth it?
I mean, that would be a lot of work to just match the features of that firmware...
And everyone seems to be using AVR microcontrollers, would people be really interested by another controller?

Microchip's documentation and applications didn't really seem to do it for me. I picked up a Pic 18f development board with their usb bootloader preinstalled and found that their drivers and bootloader tools on the host side had a lot of problems with modern operating systems, and I didn't really enjoy  their 'official' MPLAB IDE. YMMV but I am finding ARM to be comparatively better documented and to have more examples to learn from, because even if peripheral register names differ from system to system, the underlying paradigm or philosophy is still the same because of CMSIS standardising the underlying core.
For example, ARM controllers conserve power by not enabling clock signal to specific systems on the chip unless you manually turn it on.
On an LPC controller:
Code: [Select]
Chip_Clock_EnablePeriphClock(SYSCTL_CLOCK_GPIO);is actually doing this:
Code: [Select]
LPC_SYSCTL->SYSAHBCLKCTRL |= (1 << clk);
On a STM32F3:
Code: [Select]
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);is providing an alias for:
Code: [Select]
RCC->AHBENR |= RCC_AHBPeriph;
Both calls are enabling the AHB clock for the relevant subsystem (GPIO in this instance). More specifically, both of them are doing so by writing a configuration bit in a register.
So when the time comes for me to investigate Freescale micros from a software side I will already understand that that is what I'm going to have to do, even if the names will be different.

On the topic of TMK:

  • Multi-layer Keymap - Multiple keyboard layouts with layer switching
Can be implemented by encapsulating the layer as an object and just simply switching which object is the 'current' one when performing lookups
  • Mouse key - Mouse control with keyboard
Composite device, define an additional USB interface and endpoints for a mouse
  • System Control Key - Power Down, Sleep, Wake Up and USB Remote Wake up
I think built into the USB keyboard spec - just send the right keycode?
  • Media Control Key - Volume Down/Up, Mute, Next/Prev track, Play, Stop and etc
As per system control
  • USB NKRO - 120 keys(+ 8 modifiers) simultaneously
Not sure whats involved with this, I'll admit
  • PS/2 mouse support - PS/2 mouse(TrackPoint) as composite device
I'd like to do this but would have to investigate the complexity of PS/2 which I know nothing about as yet.
  • Keyboard protocols - PS/2, ADB, M0110, Sun and other old keyboard protocols
  • User Function - Customizable function of key with writing code
I haven't used TMK yet so would need to see what it makes possible, to evaluate this feature.
  • Debug Console - Messages for debug and interaction with firmware
Composite device, implement a CDC interface and endpoints, talk to keyboard as a COM port
  • Virtual DIP Switch - Configurations stored EEPROM(Boot Magic)
I'd probably just use flash for this, most of my parts have 256k+ so should have room after I implement my actual firmware for it
  • Locking CapsLock - Mechanical switch support for CapsLock
Should be just a toggled variable.
  • Breathing Sleep LED - Sleep indicator with charm during USB suspend
Wouldn't be a problem, can detect USB suspend request and enable.
  • Backlight - Control backlight levels



These are the features listed on the github page.
The only really difficult features I can see there will be the support for alternative protocols and NKRO.
There's a lot of work involved, true, and I'm not necessarily trying to be a TMK killer anyway.
These controllers were started because I wanted to scratch-build my own boards - a while back I decided that by and large I was going to not buy any more predesigned boards and build everything myself from here on in - and to provide an opportunity for me to learn some electronics and microcontroller development.
As an added bonus I hope to give us some more purpose-built Teensy-alikes that might have some reduced cost, more like the MC HCK.

twiddle: is your code anywhere public yet?

No, there's no real point posting it until I actually have something that functions. Still working on the USB enumeration process.
I would like to release the full hardware design and source, but developing this, both from a hardware and software perspective hasn't been cheap, so I was considering keeping the design closed, or partially closed, at initial release, and doing a GB or a run of devices to sell so I could recoup that cost and then once I hit the break even point open source the lot.

I do hope you can make a much smaller version without sacrificing the number of pads. I believe LEDs are the way to go, and many of these geeks will want to control the leds on their boards. Even an old man like me has gotten interested in LED controls after realizing that they help me to use a keyboard in fairly low lighting.

That was just an example of an optimisation that *could* be made. Unless you want individually controlled lEDs though, it shouldn't use many IOs to simply have a backlit board with a pwm connection to dim the leds and allow global brightness control.
If we go down the RGB LED path I am assuming we'd go with something that functions like the WS2822 LEDs that uses an addressing protocol to keep the number of pins needed very low.

Notice that twiddle wants to base the firmware on mbed. It should be easy to port to any chip supported by mbed. That is rather cool.

I'm actually not using MBED itself simply because I won't learn anything about talking to the hardware myself if I do; rather I am looking at the source code for the hardware abstraction layer for MBED.
When you write code using mbed functions, under-the-hood there's a header file for each target platform that implements a abstracted interface that handles the actual calls for your current target. That's the HAL. For example it might have a function called Init_GPIO(). In the LPC1114 target file, this function would contain the code from my earlier example, whereas the STM32F373 target would have it's relevant code defined in its file instead. (I presume you probably know what a HAL is, vvp, but figured others might not).
So, to learn how to talk to the chip in question I simply look at what the relevant mbed function is, and trace its function calls to work out what HAL functions are being called and then examine those functions in the HAL implementation for my desired processor. USB is a little more tricky because mbed doesn't have USB device support for STM targets that I could see, so I have to rely on STM's own USB examples for that. But for I/O, PWM, interrupt handling, etc, mbed's a far better learning resource than it is a development environment (shudder at everything being 'in the cloud').

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #33 on: Tue, 26 May 2015, 13:24:27 »
twiddle: is your code anywhere public yet?

No, there's no real point posting it until I actually have something that functions. Still working on the USB enumeration process.
I would like to release the full hardware design and source, but developing this, both from a hardware and software perspective hasn't been cheap, so I was considering keeping the design closed, or partially closed, at initial release, and doing a GB or a run of devices to sell so I could recoup that cost and then once I hit the break even point open source the lot.

I'm doing the same thing. I'm just ironing out the kinks in my first PCB design. I haven't released my code yet either, quite a bit of work before it's in a good enough shape to release.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #34 on: Sat, 04 July 2015, 22:49:43 »
So, big updates, especially for any interested parties that haven't looked at the parallel thread I keep on DT while GH was lamentably down.
Firstly, I have had another couple of controller prototypes made:


These are the NXP and Freescale boards.

Layouts (top layer) for interested parties:

Freescale


NXP


Closeups of assembled boards (sorry for potato)




The astute among you might notice that the freescale board looks a bit, shall we say, greener, than the boards in the first image. This is because there was an electrical fault in main power trace on that design, which meant the chip wasn't receiving the right current. I also had made a mistake in how I routed the SWD header on those boards, because I had made a custom part for them I had the pin sequence running in the wrong direction (vertically rather than left to right). I took the chance to send off for more prototypes of the Freescale board, fixing the electrical issue while also addressing the swd header.
For the NXP board, there were no actual faults as such so I simply handwired a spaghetti of wires to the bare contacts on the board and socketed them onto my debugger, as you can see here:

Green light was set in the firmware to turn on when USB enumeration was complete. IT LIVES!
On the other hand the Freescale v2 with the fixed header has no LED, so is not quite so dramatic, but nevertheless it looks much neater with the Cortex debug cable properly attached:


So, now I have two dev boards that properly enumerate as USB keyboards, I'm moving forward with some firmware development. I grabbed my trusty 5x5 tester I showed earlier in this thread and attached it to the Freescale board, and I've now got a preliminary matrix scanning routine functioning on it.
Here's hoping progress will be substantially faster now.


Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #35 on: Sun, 05 July 2015, 03:17:18 »
Awesome progress!

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #36 on: Wed, 05 August 2015, 03:25:54 »
Little update for everybody:
VisualGDB now have Nordic support available, so I'll get on BT shortly. In the meantime I've been working on my HAL, so I figured I'd give people a little insight into how I'm building it (source will eventually be on Github when I'm at a point that it would be useful for people).

Emphasis will be on using "modern" features of C++ such as constexpr, auto, and templates to make defining things at compile-time both easy to do and easy to read (which I believe is where mbed somewhat falls down).
I'm leveraging these features to avoid dynamic memory allocation and to keep RAM usage down, and avoiding virtual functions/vtables while still maintaining polymorphism (static polymorphism that is).

Code: [Select]

class NXP_HAL_GPIO : public HAL_GPIO<NXP_HAL_GPIO>
{
void SetMode(GPIO_Data Data)
{
(Data.Mode == GPIO_Data::EPD_Input) ?
Chip_GPIO_SetPinDIRInput(LPC_GPIO,Data.Port,Data.Pin) :
Chip_GPIO_SetPinDIROutput(LPC_GPIO,Data.Port, Data.Pin);
};
void DigitalWritePin(GPIO_Data Data, uint8_t Value)
{
Chip_GPIO_SetPinState(LPC_GPIO, Data.Port, Data.Pin, (Value != GPIO_Data::EPS_Low));
};
bool DigitalReadPin(GPIO_Data Data)
{
return Chip_GPIO_GetPinState(LPC_GPIO, Data.Port, Data.Pin);
};
};

This sample implements the CRTP pattern in its template definition so that polymorphism can be used at compile-time. Methods will be inlined where necessary for performance (the underlying vendor calls in the above sample are already inlined).
Once the vendor specific implementation is exported into the HAL namespace you end up with an actual application that looks like the following (this is an approximation, but you get the idea):

Code: [Select]
int main()
{
HAL::Clock.InitializeSystemClocks();

HAL::USB.Initialize();
HAL::Matrix.Initialize();

for (;;)
{
HAL::Matrix.Scan();
}

return 0;
}
Application code doesnt know anything about vendor details, but performance is close to the same of using vendor libraries directly.
Application can optionally specify configuration information (for example, matrix row and column pins) on a per-platform basis at compile time using traits template specialization.

Curious to see what people think :)

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #37 on: Wed, 05 August 2015, 03:55:31 »
Yup, pretty much how I'd do it!
I'm going to have a very thin HAL, since I'm just aiming to support one chip for now, but will use similar techniques.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #38 on: Mon, 07 September 2015, 20:47:23 »
So, still plugging away at the firmware, and I'll shortly be at the point where I canvas interested people for feedback on the HAL design, etc.
Not quite yet looking for collaborators, I want to get the implementation to a certain 'critical mass' as it were before I throw open the gates to everybody, but anybody who is interested in reviewing some crazy constexpr hackery with a (hopefully) nice external API, and offering feedback, let me know via PM and I'll see about setting up something.

Offline mrflow3r

  • Posts: 158
  • Location: Vancouver
    • T
Re: Alternative controller experiments
« Reply #39 on: Sat, 12 September 2015, 20:09:59 »
Looks great and definitely a very interesting project. I have very little experience with C++ features. Can you write a post about your "carzy constexpr hackery"? I'd be interested. I am in no position to review the code. I think I will learn a lot with your firmware though.

Btw, is that ground pour on the top layer? May I ask the reason for it? I am also still learning PCB design.. :D
 

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #40 on: Mon, 14 September 2015, 04:20:16 »
Looks great and definitely a very interesting project. I have very little experience with C++ features. Can you write a post about your "carzy constexpr hackery"? I'd be interested. I am in no position to review the code. I think I will learn a lot with your firmware though.

Btw, is that ground pour on the top layer? May I ask the reason for it? I am also still learning PCB design.. :D


Ok, so 'crazy constexpr hackery'. You asked for it, wall of text incoming...

Basically, in the past, you could do quite a lot of compile-time calculations in C++ using templates, which essentially form their own Turing complete meta-programming language.
There's a bunch of libraries out there such as sprout and boost::mpl that allow you to create compile-time data structures, but templates in general, and template meta-programming in particular, can lead to some very complex and non-self-explanatory error messages, especially because everything revolves around types rather than actual data.

Since C++11/14, however, we now have a restricted, but rather functional, implementation of compile-time function evaluation (CTFE) referred to as constexpr functions. C++11 had many more restrictions on what could go into a constexpr function, but almost everything is fair game if your compiler is C++14 compliant (clang, gcc 5.2.0+, icc I think are the main ones claiming compliance).
constexpr doesn't just apply to functions, it can apply to data variables as well, and it basically tells the compiler that it can evaluate the function (in the case of a constexpr function) or evaluate the assignment statement (in a constexpr variable declaration) at compile-time rather than during the execution of the program.

The relevance for microcontrollers, and in turn keyboard controllers, is that data which doesn't change during the execution of the program or the results of functions that can be calculated using values known at compile time, can be stored in the flash memory rather than being dynamically allocated and stored in RAM, which we have much less of than we do flash, and it avoids potential memory fragmentation issues due to dynamic allocation which would otherwise require writing custom allocators/custom new operators, implementing memory pools, etc etc.
The reduced RAM requirements also help make the firmware portable to a wider variety of microcontrollers, because we only need a much more limited amount of RAM for the firmware.

Constexpr functions can be combined with other new features such as function parameter deduction. Here's a small excerpt:

Code: [Select]
template <class T, size_t N>
constexpr auto make_constexpr_array(T const(&Array)[N])
{
constexpr_array<T, N> TmpArray = constexpr_array<T, N>();
for (int i = 0; i < N; i++)
{
TmpArray.Data[i] = Array[i];
}
return TmpArray;
};


This function uses parameter deduction to determine the size of the array to allocate.
If I call the function like this:
Code: [Select]
constexpr const auto TestCharacterArray = make_constexpr_array("WCS");
then a few things happen. Firstly, because I'm providing a  string literal without prefixes, "WCS" is considered a char array. This means that, using the template parameter deduction rules, I don't need to specify values for <class T, size_t N> when I run the function because the compiler says 'You've given me an array of char with length 3, so I'll just fill in those template values for you'.
This means inside the function, where you can see me declaring the array TmpArray, I can simply pass those parameters through to my inner template. I can then copy the values from the array the user passed in, in the loop, into my new object, and then I can return it.
The actual 'constexpr_array' class conforms to the C++14 'concept' called 'literal type' which means that I am not returning a reference to TmpArray, I'm actually returning by value, so I don't need to worry about returning data allocated on the stack (inside the function).
By declaring the function as auto, and then my 'TestCharacterArray' as auto, the compiler can perform type deduction on the function. ie it looks at the type of TmpArray, and sets that as the return type of make_constexpr_array, and in turn deduces the type of TestCharacterArray, so I don't need to manually count the items in my array input and use that to create a variable to store the return value of the function in.
Likewise, if I call
Code: [Select]
constexpr auto TestCharacterArray = make_constexpr_array(u"WCS");
then the compiler interprets "WCS" as a two-byte/uint16_t-backed string, and so it deduces my invocation of the function to be
Code: [Select]
make_constexpr_array<uint16_t, 3>(u"WCS");
and in turn TestCharacterArray will actually be a constexpr_array storing 'uint16_t's instead of plain char.
More to the point, because TestCharacterArray is declared 'constexpr' the compiler *can* if it wants, run the function at compile-time and simply place the computed value into the constant data section so the whole array will go into flash memory.

Putting this all together with some helper functions that wrap the idea of a constexpr_array means I can create things with much nicer syntax.

For example, here's the traditional way to represent a collection of USB String Descriptors:

Code: [Select]
ALIGNED(4) uint8_t USB_StringDescriptors[] =
{
0x04,
USB_STRING_DESCRIPTOR_TYPE,
WBVAL(0x0409),

//Manufacturer
(3 * 2 + 2),
USB_STRING_DESCRIPTOR_TYPE,
'W', 0,
'C', 0,
'S', 0,

//Product
(8 * 2 + 2),
USB_STRING_DESCRIPTOR_TYPE,
'K', 0,
'E', 0,
'Y', 0,
'B', 0,
'O', 0,
'A', 0,
'R', 0,
'D', 0,
//Serial
(4 * 2 + 2),
USB_STRING_DESCRIPTOR_TYPE,
'0', 0,
'0', 0,
'0', 0,
'1', 0

};

And here's my much cleaner syntax for creating the exact same thing in memory (verified with a hex editor that it creates the same bytestream):

Code: [Select]
ALIGNED(4) static constexpr auto MyDescriptors =
USB_String_Descriptor_Collection().Append(StringDescriptor("WCS"))
.Append(StringDescriptor("KEYBOARD"))
.Append(StringDescriptor("0001"));


(I'll probably clean the syntax further, I should be able to do away with Append and simply use .StringDescriptor, but you get the idea).

So the firmware uses a bunch of that sort of stuff in the back-end but I can perform much nicer sanity-checking than a traditional compile-time implementation using templates could use.
As a result, most of the complexity that you see here should be hidden from people using the firmware, but if people want to get into modifying or extending it, constexpr functions have a far more natural syntax than template meta-programming, so it should still be relatively easy for people to extend.



As far as the copper pour goes, I find that having copper ground pours on top and bottom dramatically decrease the complexity of my routing.

Offline hanya

  • Posts: 104
  • Location: Japan
Re: Alternative controller experiments
« Reply #41 on: Wed, 23 September 2015, 05:01:55 »
Have anyone tried to use Silicon Labs EFM32HG series [1]?
EFM32HG321:
- ARM Cortex-M0+ up to 25MHz
- 64/32KB Flash, 8KB Ram, No EEPROM
- USB Full-speed without external crystal
- Internal 3.3 V regulator up to 50 mA
- Pre programmed USB CDC/UART bootloader
- Power supply 1.98-3.8 V
- TQFP48 package
- Unit price $2.4 @digikey
Their Simplicity Studio includes GNU tool-chain and Eclipse based IDE supports Windows, MacOSX and Linux.
Other packages having smaller number of pins are provided in QFN package.

[1] http://www.silabs.com/products/mcu/32-bit/efm32-happy-gecko/pages/efm32-happy-gecko.aspx

I've tried to design my breakout board in 32pins and 600mil width. If I have a chance, I would try.
PFU HHKB JP, Sanwa MA-TB38 trackball

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #42 on: Wed, 23 September 2015, 05:27:06 »
I considered the Happy Gecko series for a while, but then decided to stick with Kinetis for now. The MKL27Z has, off the top of my head, the same features as the HG, but available with 256 KB flash and 32 KB RAM. The advantage is there is already kinetis code easily available (from Teensy)
« Last Edit: Wed, 23 September 2015, 05:29:27 by joey »

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #43 on: Wed, 23 September 2015, 06:08:26 »
I have looked into them but haven't gotten around to either sampling or spinning up a test design. From memory their dev kits were substantially more expensive, too, but I'll admit that I can't really remember.

A little update for those who aren't on Deskthority:
I've not done much on the firmware the last little while because I've been drawing up this board.


Custom development board with a bunch of varied peripherals, for my students to meet their 'hardware integration' learning outcomes in the penultimate game project they are about to start in the game development degree that I teach.
I dont have 3d models for everything on the board, but there's a speaker, some buttons, dial, some various LEDs including a RGB LED, a seven-segment display, the thumbstick, and the ESP for wifi support, along with a gyroscope. The board will charge over USB, and uses a lipo battery hence the bare area in the top left. The lipo is particularly important as if it works for the students I'll probably be doing a KB PCB that uses the same circuitry at some point.

I would love to have OSHPark do the board, because I am always a fan of the look of their work, and I feel students will take the project more seriously if everything looks professionally developed. However they are just too expensive when time is a factor so I'll probably go with Smart Prototypes again, so it should still look pretty sweet even if I can't have purple+gold.

Microcontroller is the same LPC11u35 that you've seen earlier in the thread, mostly because I have about 10 or so of them and their API isnt too bad.

Once things settle down into the new teaching trimester I'll be doing more frequent firmware updates again.

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #44 on: Wed, 23 September 2015, 06:20:39 »
Smart Prototyping can do ENIG gold finish too. I think it's ~$15. You can't do purple.. but the red and blue look nice (and different from the standard green)

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #45 on: Wed, 23 September 2015, 06:53:26 »
I went with blue+ENIG. Totally because I should be using lead-free in things I give to my students, and not because I wanted to try their ENIG finish... >.> Ordered on Monday so hoping I'll get it in the middle of next week.

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #46 on: Wed, 23 September 2015, 06:55:34 »
I went with blue+ENIG. Totally because I should be using lead-free in things I give to my students, and not because I wanted to try their ENIG finish... >.> Ordered on Monday so hoping I'll get it in the middle of next week.
Look forward to the pics!

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #47 on: Wed, 30 September 2015, 20:14:04 »
So the boards arrived from Smart Prototyping:


Here it is fully assembled:



Now to just test that everything is working. Good news though, the USB/Battery portion of the circuit behaves as expected for sure so that is one big chunk of the BTLE design sorted.

Offline mrflow3r

  • Posts: 158
  • Location: Vancouver
    • T
Re: Alternative controller experiments
« Reply #48 on: Wed, 30 September 2015, 20:26:57 »
Love seeing the progress. I'm expecially excited for the BLE module.
Thanks for the tut on C++. I haven't absorbed everything yet. Have been busy.
 

Offline mrflow3r

  • Posts: 158
  • Location: Vancouver
    • T
Re: Alternative controller experiments
« Reply #49 on: Thu, 03 December 2015, 11:57:04 »
Any news with BLE?
 

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #50 on: Thu, 03 December 2015, 15:09:03 »
Putting the final touches on a prototype BLE PCB.
Will be sending off to the fab sometime soon once I do a few final sanity checks, its the end of the college trimester atm so things are crazy busy.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #51 on: Sun, 13 December 2015, 23:19:54 »
Teaser:

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #52 on: Mon, 14 December 2015, 02:28:32 »
Is U1 the antenna? I haven't looked at BLE/BT at all. Also it says nRF1, but I guess the 1 is here is just the reference. So is it a nRF 51/52?
What about FCC stuff, can you ignore all that for hobbyist stuff?

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #53 on: Mon, 14 December 2015, 06:20:57 »
Is U1 the antenna? I haven't looked at BLE/BT at all. Also it says nRF1, but I guess the 1 is here is just the reference. So is it a nRF 51/52?
What about FCC stuff, can you ignore all that for hobbyist stuff?

Yep, thats the antenna. Looking at the nRF51 at the moment, just trying to ascertain what options there are for user-flashing of new firmware (theres no bootloader by default). and as far as FCC certification goes, I'm not selling completed items so don't require it.

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #54 on: Mon, 14 December 2015, 06:33:56 »
Thanks!

No USB either, right?

I should be getting a BBC MicroBit, which has an nrf51 on it, which uses a Kinetis L from Freescale to do the USB parts.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #55 on: Mon, 14 December 2015, 06:48:16 »
Yeah. There's a DFU service which allows for over-the-air updates, but I want to do some tests with my development board before I go further with the prototype.

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #56 on: Mon, 14 December 2015, 08:07:26 »
Hm, I think I'd treat the nRF just as a "module" to send the data, and have the actual matrix driver on another MCU.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #57 on: Mon, 14 December 2015, 11:47:41 »
All comes down to cost really. The power circuitry for allowing either USB power or Li-po charging is not cheap, then you add the 'real' MCU on top of the inductors and whatnot needed for the BLE chip.. I'd really rather either use a USB-to-UART interface IC or just leverage over-the-air. Will do as you suggest if all else fails though.

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #58 on: Mon, 14 December 2015, 13:13:10 »
How are you going to charge the batteries?

I'm not really sure the cost is high enough that it's not worth it!

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #59 on: Mon, 14 December 2015, 13:41:24 »
Already prototyped a circuit that allows power direct from USB while simultaneously charging the li-po, then disconnecting to use wirelessly.
Uses a charger IC, a power multiplexer, and a buck-boost converter to regulate either output to steady 3.3v.

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #60 on: Wed, 03 February 2016, 05:54:57 »
I still aten't dead:

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #61 on: Wed, 03 February 2016, 05:56:31 »
Tell us more!

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #62 on: Wed, 03 February 2016, 05:59:27 »
Well, not much more to say until the rest of the passives and inductors arrive next week, but I've gone with the dual-mcu option to give the design reprogrammability. When I finish assembly I'll hook those header pins up to one of the PCBs that Ivan was selling that were pre-populated with MX Blacks, but had no controller, and use that to test.

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #63 on: Wed, 03 February 2016, 06:04:37 »
Is that the nrf51? What's the other chip?

I guess the top left header is JTAG for the main MCU.. how do you program the BT MCU?

Offline twiddle

  • Thread Starter
  • Posts: 165
    • Portfolio
Re: Alternative controller experiments
« Reply #64 on: Wed, 03 February 2016, 06:41:05 »
I happen to have a decent number of LPC11u35 parts on hand. The IBDAP firmware turns the LPC into an OpenOCD-compatible CMSIS-DAP debug device capable of programming other things over software SWD.
So, flash my fork of the IBDAP firmware to the LPC using the USB drag and drop bootloader, and you can then debug the nRF chip.
nRF chip listens on UART for keydata and simply transmits it when received, so you shouldn't need to debug it very much, and you can use the 10-pin header to enable debugging the LPC chip which is doing the heavy lifting.
I may set things up so a specific key sequence will make the IBDAP application run, and include it into the binary of the actual KB firmware, but it will come down to flash size.

Offline joey

  • Posts: 2294
  • Location: UK
Re: Alternative controller experiments
« Reply #65 on: Wed, 03 February 2016, 07:11:36 »
I happen to have a decent number of LPC11u35 parts on hand. The IBDAP firmware turns the LPC into an OpenOCD-compatible CMSIS-DAP debug device capable of programming other things over software SWD.
Ah, makes sense!

nRF chip listens on UART for keydata and simply transmits it when received, so you shouldn't need to debug it very much, and you can use the 10-pin header to enable debugging the LPC chip which is doing the heavy lifting.
Sounds good.

I may set things up so a specific key sequence will make the IBDAP application run, and include it into the binary of the actual KB firmware, but it will come down to flash size.

Like you said, it's probably very rare that you need to debug the BT module, so I hope it'd just be an optional thing!

You've made it look pretty easy to make a BT board, will have to pick your brains if I decide to do it!
« Last Edit: Thu, 04 February 2016, 10:17:03 by joey »

Offline iLLucionist

  • * Elevated Elder
  • Posts: 2715
  • Location: Netherlands
  • Topre is Love.
Re: Alternative controller experiments
« Reply #66 on: Thu, 04 February 2016, 10:07:43 »
This is very cool and detailed. Thought of starting such a project myself. Firmware coding I could do, but now I see this it scares me off a bit.. No experience with circuit design and soldering. Keep up the good work!
MJT2 Browns o-rings - HHKB White - ES-87 Smoke White Clears - 87UB 55g