Question about writing firmware

[Melvang]

So when actually writing the code for a custom firmware from the ground up, is there any reason that would favor any language over another? Or is it just use what you know?

The reason I ask, I am considering digging into it and creating a new controller daughter board that will fit between rows.

[zlittell]

Normally I would suggest favoring C over anything.  Most chip manufacturers provide libraries based on C and it is the most efficient assembled language you can choose other than assembly itself.  Also most code examples will be in C.  This is of course as long as you are basing your board on specific chip architectures and not just buying something off the shelf like teensy that has its own ecosystem.

I tend to favor the offerings from Microchip, but Atmel's studio IDE does seem to be better than MPLABX.

My current favorite chips are in the 18FXXK50 range (18F25K50 and 18F45K50) from Microchip.  USB capable and they sync to the host USB clocks to do crystal-less high speed USB which can cut cost decently per unit.

[Melvang]

Thanks for the reply zlittell, I have never done any coding, so total newbie here in this area.  But, I do have an interest in it just so I can do as much of my own keyboard design as feasible.  Granted learning to code just for one project seems a bit overkill.  But I have high hopes for my plans.

So, what libraries would be needed for making a custom keyboard firmware, and what are my options for selecting a chip and programming language.  My only hesitation on C is I have heard from multiple people that learning C as a first programming language can be difficult at best. 

The biggest thing I want is to have a utility on the host PC, do up your layout, hit one button on screen, and that flashes the firmware on its own.  Nothing against metalliqaz's Easy AVR program, but I want to bypass a lot of that stuff, and bring it closer in execution to the xwhatsit controller.  Including the visual matrix so you can hit a button on the keyboard and see where it shows up.  With this, there is no need to worry about which rows are going to which pins.  The only pins that matter are which ones or on rows and which ones are on columns.

Suggestions?

[joey]

Any reason you don't want to look at extending EasyAVR, for example?

[Melvang]

Any reason you don't want to look at extending EasyAVR, for example?

I think, in my mind at least, is because xwhatsit utility is closer to how I want it to function. 

[joey]

Any reason you don't want to look at extending EasyAVR, for example?

I think, in my mind at least, is because xwhatsit utility is closer to how I want it to function.

But it might be easier to extend EasyAVR, rather than writing it from scratch?

[Melvang]

Any reason you don't want to look at extending EasyAVR, for example?

I think, in my mind at least, is because xwhatsit utility is closer to how I want it to function.

But it might be easier to extend EasyAVR, rather than writing it from scratch?

True, but I have source code for xwhatsit, was released under creative commons I believe.  So, I can tweak that to my hearts content.  Plus, I have the primary stuff from xwhatsit that needs to be changed to optimize for momentary switches.

[zlittell]

Not to be discouraging, but this is a HUGE undertaking.  Especially without knowing any languages or having any experience coding to build on.  There isn't going to be many options except C for you.  USB is a very time specific operation and using other languages tends to bring in many inefficiencies.

I don't want you to think this means this isn't possible though!

Also the hardest part of this project will be creating the way the user configures their customization.  Without exaggerating creating a working USB HID Keyboard would take me no more than an hour (maybe 20 minutes on a platform I am familiar with).  The communication between host and device is where it becomes difficult.  I would create a second USB HID interface to exchange data between the host and device.  This makes the PC side application more complicated if anything.  I would suggest playing with things first.  If you want to start easy and just get your feet wet get a teensy and play with that in the arduino IDE.  If you want to dive in head my best suggestion would probably be a Atmega32u4 board (pro micro clones will work fine) and look at using Lufa.

Topic for getting started with Atmel chips
http://www.avrfreaks.net/forum/newbie-start-here?name=PNphpBB2&file=viewtopic&t=70673

Link to Lufa libary
http://www.fourwalledcubicle.com/LUFA.php

Pauls website for his teensy is here:
https://www.pjrc.com/teensy/

Also self plug here but I did some work on a teensy not too long ago and needed to add my own USB device.  I put together an article that really dives into how the arduino compiler puts things together behind the scenes.  Something that can become frustrating as soon as you need to edit what is happening behind the scenes.
http://www.zlittell.com/2015/07/fightstick/

I have converted my project into a library addon for the teensyduino environment that allows users to create native xinput controllers for PC gaming:
https://github.com/zlittell/MSF-XINPUT

Its my experience with the above that really makes me want to push you towards a more native setup, but I do understand that it is very easy to get overwhelmed and that things like the teensy can make it much easier to get started and more importantly have fun.

Edit:
Going to go ahead and say just get the teensy and maybe even a atmega32u4 board now.  If you get a TeensyLC legit board and a chinese 32u4 you will probably end up under $20 maybe under $30 tops with shipping.  Start with the teensy, do the examples, read all you can read and get a simple keyboard example up and running. Graduate to the 32u4 in Atmel studio.  Do the same thing.  Blink an LED, read inputs coming in, build up to a USB serial port and then a USB keyboard. 

Another huge reason I push the atmega route is you can make viable products if you wanted to.  The teensy is really going to leave you buying $13-$20 Teensies.  You can take an Atmega32u4 and layout a PCB and send them to china to have them assembled and made if you ever needed to do so.

Edit Edit:
Looks like Atmel has what they call the ASF (Application Software Framework) which supports USB as well.  Here is one of their PDFs on using it with one of their dev boards
http://www.atmel.com/Images/doc8446.pdf

-Zack-

[joey]

Any reason you don't want to look at extending EasyAVR, for example?

I think, in my mind at least, is because xwhatsit utility is closer to how I want it to function.

But it might be easier to extend EasyAVR, rather than writing it from scratch?

True, but I have source code for xwhatsit, was released under creative commons I believe.  So, I can tweak that to my hearts content.  Plus, I have the primary stuff from xwhatsit that needs to be changed to optimize for momentary switches.

Just FYI, EasyAVR is also available under a GPL license: https://github.com/dhowland/EasyAVR

[zlittell]

Also to point out EasyAVR works on the 32u4.  Once you move to the 32u4 you could load up the EasyAVR project and just start reading how it works.  It is lacking a direct way to keymap and expanding that project to have a second communication pipe that allows keymapping would be a more definable goal.

I would still buy the stuff I mentioned above just for the fact that you are brand new and you are showing a great amount of interest in just wanting to learn.  The teensy is a great just go platform where you can blink some stuff, read some inputs, write to a serial port, etc very quickly.

Also EasyAVR is built in Atmel Studio so you can open the project and start learning.

But if you are just looking to support your own board so that you can put that last bit of self made goodness into your keyboards then starting from scratch isn't terrible.  Making a HID USB keyboard is really a single chapter project in a book when using one of the libraries supplied by your chip manufacturer.  I mean for the teensy you can literally go into the menu and change the USB type to keyboard lol.  You can then just focus on learning about reading a keyboard matrix and writing that functionality.

[Melvang]

Thank you everyone for all the input. I understand that these are newbie questions and appreciate the help.  I am just trying to understand some concepts right now about the environment before I start learning the code, mostly so I have a realistic expectation of what I can and can't do

Another question. The xwhatsit controller uses an ATmega32u2 and the teensy uses the same but in the same chip in the u4 flavor.  I was looking at Atmel's website and it looks like the only difference is the onboard memory size and pins for I/O stuffs.  Is the reason for having to save .Hex files andanually flash with Easy AVR then a result of  keeping the code much simpler, or is that a restriction of using the teensy which has its own bootloader that can't be bypassed?  Would it be possible to directly interface through that for a single button click to flash solution?

[joey]

Another question. The xwhatsit controller uses an ATmega32u2 and the teensy uses the same but in the same chip in the u4 flavor.  I was looking at Atmel's website and it looks like the only difference is the onboard memory size and pins for I/O stuffs.  Is the reason for having to save .Hex files andanually flash with Easy AVR then a result of  keeping the code much simpler, or is that a restriction of using the teensy which has its own bootloader that can't be bypassed?  Would it be possible to directly interface through that for a single button click to flash solution?

I guess EasyAVR just wanted to keep the code simpler. (Although in my current firmware, the way I'm structuring it, it should be possible to implement either way, while keep the code simple)

I'm not sure what you meant by the last sentence. With the teensy you should be able to press the teensy button, and then use the teensy-loader app, which is pretty simple.

[zlittell]

Just wanted to know you inspired me to get a board to use in Atmel Studio.  I spend 99% of my time in Microchip PIC land so figured it would be nice to step outside my comfort zone.