This is a cool thread.I'm still to scared to try it. I always solder each pin individually.
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.
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(http://i.imgur.com/5pk68Jt.jpg)
MK22FN1M0VLH12 (QFP-64)Show Image(http://i.imgur.com/TK5HMUj.jpg)
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(http://i.imgur.com/N72fhSq.jpg)
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.
I thought one main reason we use the atmega 32u4 for is that it has hardware USB support or something?
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
>
don't tell me you have even built LED support on that one!
you bought it from wonderco on ebay right?
LPC11U35 is that cheap? Can you refer to source of the price?
I cannot find any supplier with that good price on the net.
(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.
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.
(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
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)
But when I look at firmware like TMK, I wonder if it is really worth it?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.
I mean, that would be a lot of work to just match the features of that firmware...
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?
Chip_Clock_EnablePeriphClock(SYSCTL_CLOCK_GPIO);
is actually doing this:LPC_SYSCTL->SYSAHBCLKCTRL |= (1 << clk);
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);
is providing an alias for: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.twiddle: is your code anywhere public yet?
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.
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.
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.
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);
};
};
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. 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
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;
};
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'.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 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. 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
};
ALIGNED(4) static constexpr auto MyDescriptors =
USB_String_Descriptor_Collection().Append(StringDescriptor("WCS"))
.Append(StringDescriptor("KEYBOARD"))
.Append(StringDescriptor("0001"));
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!
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?
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.