geekhack
geekhack Projects => Making Stuff Together! => Topic started by: VinnyCordeiro on Sat, 16 May 2015, 22:04:10
-
All custom keyboards I have ever seen being made (including mine!) uses an Atmel microcontroller, in special the ATmega32U4. I can say without doubt that Arduino is the major cause of that, making it easy to program AVR microcontrollers for the non-technical people and such.
Why am I asking about PIC?
- Because they were the de facto microcontroller choice before the arrival of Arduino. I know just the basic about them, I made a project for a class at university using a PIC almost 10 years ago. (It was supposed to be made in assembly language, but I got hold of a C compiler for PIC. Don't ask how.) Problem is: IIRC there is no reliable open source compiler for PIC. Apart from that, I don't know the state of bootloaders for PIC that would make it possible to upload firmware using an USB port;
- PIC microcontrollers that can handle USB natively can be cheaper than an ATmega. Of course you have to choose carefully, because in general PIC microcontrollers have less RAM and FLASH for programs than an ATmega, but there are also models with plenty of both.
What can you say? Because of Arduino I'm a AVR-man now, but it wouldn't hurt to know about the other options. (And I'm not even going to talk about ARM, because I'm pretty sure that in no time people are going to use them for custom keyboards when more processing-power is needed -- LED effects anyone?)
-
People are already using ARM chips. The infinity does, I'm working on something myself and I'm sure others have too.
I don't see any advantage when PICs aren't that much cheaper for small scale production.
-
Hmmm... too many disadvantages to using PIC vs AVR (combination of price, availability, hardware USB, easy bootloader, simple tools and a few compilers / IDE's to choose from + Teensy 2.0 platform). Even without Arduino, I think AVR would have eclipsed PIC pretty quickly. I for one don't use the Arduino libraries, but prefer to use native Atmel coding.
ARM will very soon start to overshadow AVR, even in basic keyboard projects, IMO. The MCHCK uses ARM, as does the new Infinity keyboard.
Cypress have released some really nice (and cheap) low power ARM microcontrollers, like the MKL26Z64VFT4 as used in the new TeensyLC which has integrated hardware USB, 48MHz, decent amounts of memory, 2 TWI/I2C lines and enough remaining IO lines for lots of interesting stuff. The only difficulty with the ARM chips is finding a decent small bootloader and uploading new firmwares via USB.
Seems like TeensyLC is using a separate Cypress chip to store the bootloader and push it into the main chip's RAM when needed. Interesting solution, but a bit tough for a homebrew developer like myself to try and copy. The ARM bootloaders take up a fair chunk of memory (about 40k for the MKL20/25 one).
-
The MKL series is Freescale (now a part of NXP), not Cypress.
MCHCK has a boot loader that fit in ~4Kb, that's used by the kiibohd firmware: https://github.com/kiibohd/controller/tree/master/Bootloader
I also have a unreleased (for the moment) DFU boot loader for MKL26z that, last time I checked, is ~5Kb.
-
The MKL series is Freescale (now a part of NXP), not Cypress.
MCHCK has a boot loader that fit in ~4Kb, that's used by the kiibohd firmware: https://github.com/kiibohd/controller/tree/master/Bootloader
I also have a unreleased (for the moment) DFU boot loader for MKL26z that, last time I checked, is ~5Kb.
DOH! My bad about the brand.
Very interesting... Thanks for the info. Would you be willing to share your DFU bootloader with the community at some point? I think the MKL26 range is great for keyboard projects.
-
Very interesting... Thanks for the info. Would you be willing to share your DFU bootloader with the community at some point? I think the MKL26 range is great for keyboard projects.
Yes, I will be open sourcing it at some point!
My current code is https://github.com/jgouly/frdm-mkl26z to get the Teensy code to work with the FRDM-MKL26Z dev board.
-
I don't think that there is any reason you cannot make with PIC and it is bad choice for keytoard.
I don't know what your question actually is, but you can find many keyboard related projects with Google.
Esrille uses PIC in their keyboard NISSE, for example.
http://www.esrille.com/keyboard/index.html
https://github.com/esrille/new-keyboard
-
I initially investigated PIC but settled on ARM for the variety of vendors leading to some good price competition, nice toolchain and some good ROM bootloaders. Mbed is great as a supplement to vendor documentation for interacting with peripherals now it is open source, and has support for half a dozen or so common vendors.
I just finished the hardware prototyping for a STM based dev board that I intend to use as a controller. I'll update my custom controller thread with photos later today, there's an onboard DFU bootloader in ROM on it so I still have plenty of program space.
Some freescale parts have crystal-less usb support too, NXP has drag and drop usb bootloaders on some parts - that's why I'm really liking all the different options within ARM, with CMSIS providing a common underlying system. Put that with the performance per dollar (hardly a concern for a keyboard, I know) and it feels like PIC doesn't really compete. It will still do the job but I don't regret my choice.
-
I don't think that there is any reason you cannot make with PIC and it is bad choice for keytoard.
I don't know what your question actually is, but you can find many keyboard related projects with Google.
Esrille uses PIC in their keyboard NISSE, for example.
http://www.esrille.com/keyboard/index.html
https://github.com/esrille/new-keyboard
The question is the title of the post, and you just answered it. The rest of the post was only explanation of why I asked. ;) But I should note that my Google-fu failed me this time. :-[
And thank you for showing me this keyboard. :)
-
I initially investigated PIC but settled on ARM for the variety of vendors leading to some good price competition, nice toolchain and some good ROM bootloaders. Mbed is great as a supplement to vendor documentation for interacting with peripherals now it is open source, and has support for half a dozen or so common vendors.
I just finished the hardware prototyping for a STM based dev board that I intend to use as a controller. I'll update my custom controller thread with photos later today, there's an onboard DFU bootloader in ROM on it so I still have plenty of program space.
Some freescale parts have crystal-less usb support too, NXP has drag and drop usb bootloaders on some parts - that's why I'm really liking all the different options within ARM, with CMSIS providing a common underlying system. Put that with the performance per dollar (hardly a concern for a keyboard, I know) and it feels like PIC doesn't really compete. It will still do the job but I don't regret my choice.
I can think about one thing that an ARM microcontroller would be useful: LED effects. AFAIK, AVR microcontrollers are not powerful enough for some fancy LED effects AND working as a keyboard controller at the same time. That's something I want to study in the near future.
-
AFAIK, AVR microcontrollers are not powerful enough for some fancy LED effects AND working as a keyboard controller at the same time. That's something I want to study in the near future.
The deficiency is not really about raw speed but that AVR does not prioritize its interrupts. You can't put a fast PWM update routine on a timer interrupt that could override a slow routine in another interrupt.
You would have to make sure that no interrupt code runs for too long, maybe move stuff from interrupts to user mode. Structure your code in user-mode so that it does not busy-wait on the keyboard all day but does different tasks in a main loop.