Blue White Red Direct
4/ 9 - 5/12 5/20 - 5/27 17/12 - 17/24 6/28 - 6/29
4/10 - 5/13 6/24 - 6/28 18/10 - 18/23 6/29 - 6/30
4/11 - 5/14 9/15 - 9/29 17/11 - 17/12
4/12 - 5/15 9/17 - 9/30 (9/27 - 9/28)
4/13 - 5/16 9/27 - 9/28 [2]
4/14 - 5/17 13/23 - 13/37
4/15 - 5/18 14/ 2 - 14/13 [3]
4/16 - 5/19 14/ 4 - 14/12 [3]
10/18 - 10/39 [1]
10/19 - 11/38 [1]
10/20 - 11/36 [1]
[1] End points are not connected in these pictures yet. See below.
[2] Can be replaced by a "green" direct connection, but I didn't think of this at the time...
[3] Bend wires, do not make a straight connection. See below.10/1 - 4/23 10/5 - 4/27
10/2 - 4/24 10/6 - 4/28
10/3 - 4/25 10/7 - 4/29
10/4 - 4/26 10/8 - 4/30Resistors Capacitors
4/36 - 9/36 (470 Ohm) 13/11 - 13/12 (22 pF)
4/38 - 9/38 (470 Ohm) 16/10 - 16/11 (100 nF)
4/39 - 9/39 (470 Ohm) 16/12 - 16/13 (22 pF)
10/22 - 10/24 (4.7 kOhm)
11/22 - 11/23 (2.2 kOhm)
13/14 - 13/22 (68 Ohm)
14/16 - 14/21 (68 Ohm)
16/ 9 - 16/23 (10 kOhm)Z-diodes Crystal
12/21 - 12/24 16/2 - 16/4
15/22 - 14/24
16-pin connector : 2/ 1 - 2/16
8-pin connector : 3/23 - 3/30
4-pin connector : 3/36 - 3/39
6-pin jumper header: 14/ 6 - 14/11Blue Red White Direct
16/10 (D+) 16/8 (+5V) 16/7 (GND) 3/7 - 3/ 8
16/ 9 (D-) 3/9 - 3/10
Grounding wire: 10/7
USB connector: pins at 4/8, 4/9, 5/8, and 5/9Blue Red White
19/21 (D+) 19/10 (+5V) 19/11 (GND)
19/22 (D-) 6-pin at | header pin on 10-pin at | header pin on
programmer | controller programmer | controller
------------+--------------- ------------+---------------
1 (MISO) | 2 1 (MOSI) | 1
2 (+5V) | 5 2 (+5V) | 5
3 (SCK) | 3 3 (NC) | -
4 (MOSI) | 1 4 (GND) | 6
5 (nRESET) | 4 5 (nRESET) | 4
6 (GND) | 6 6 (GND) | 6
7 (SCK) | 3
8 (GND) | 6
9 (MISO) | 2
10 (GND) | 6@-moz-document url-prefix("http://geekhack.org/showwiki.php?") {
img {
max-width: 1160px;
}
}:Cry:
Hm... I thought the forum's automatic image resizer would take care of the wide pictures, but apparently it does not in this case. ;(
I could reduce the image sizes, but I'm afraid that some important details will become invisible then. Suggestions?
Leave it the way it is. Bigger pics are more important that minor scrolling issues. There is a light background option too at Geekhack. Of course if his monitor was CALIBRATED it wouldn't even have that issue.
Content is King.
How come Stupid Americans haven't built this before???
Anything missing?
How come Stupid Americans haven't built this before???
I wonder if you could use this to build controllers for other keyboards, say, f*cked up Fukkas.
How about my programming the controller question. Do you need special HW or can this be done somehow with a simple USB to PC connecton to load the bootloader?
How about my programming the controller question. Do you need special HW or can this be done somehow with a simple USB to PC connecton to load the bootloader?
Would this work?
this is why i got a teensy... it has usb, and can program *itself*. uses the arduino software.
This looks fantastic...I wonder how adaptable this would be to 122-key terminal keyboards?
Would just need to compensate for the larger and different matrix (easier said than done I'm sure).
As long as we are not talking about capacitive switches (Model F), it should not be too hard.
Figuring out the matrix can be a bit tedious, but that's pretty much all that needs to be done to get the firmware working. Then you'll need to design the controller board, which is most likely a matter of figuring out the controller board dimensions and placing the connectors onto it.
If you know the keyboard matrix already, I can add it to the firmware sources and make firmware images for it.
looks like a huge waste of time, you couldn't just slap a small heatsink on the old controller?
Edit:
Unless of course I can just go at it with a multimeter without fully disassembling the membrane assembly...in which case I'll get on that for you but I'm not sure how.
If you can find the time to do it, that would be great. Is there a picture of the original controller somewhere on the net? Are the connectors similar to those on the M controller?
Here's the matrix.
And here's the 1386887 controller.
A concern: the connectors will be routed somewhat differently from the Boscom. This probably wouldn't involve any changes to the actual matrix except routing, right?
That's a 20x8 matrix then. And it's a good thing that the keyboard doesn't have LEDs, because there are not enough I/O pins for the matrix AND the LEDs. Otherwise we would need an additional shift register and 8 diodes to free up some I/O pins--cheap, but somewhat annoying.
Are there variations of the 1386887 with LEDs?
The pictures of the Boscom matrix are helpful for tracing the matrix with the multimeter quickly. Perhaps they are even good enough for tracing it visually.
Wow, what are all those jumpers on the controller for? Configuring the terminal type? (Maybe I should read your thread...)
You mean the matrix sheets have their connectors in other locations? That's not a problem if the matrices are the same, from a software point of view. The controller boards for IBM and Boscom keyboards would be based on the same circuit diagram, but the physical layouts would have to be designed separately to fit into the keyboard.
That photo of the 122-key controller, the second-largest IC is a 4-16 line MUX, and so there are actually spare unused I/O lines, based on a schematic I have seen for this item, courtesy of Keyboard Babel.
And I have mapped out the matrix of my IBM 1390702 122-key terminal keyboards.
Anyway, I have attached to this posting a photo of the keyboard matrix row/columns assignments.
Maybe of use to someone here.
Hopefully my image and notes are clear enough.
Enjoy
Spec57
KEY_U KEY_L
KEY_I KEY_U
KEY_L KEY_IKEY_E KEY_smcol
KEY_Y KEY_J
KEY_U KEY_L
KEY_I KEY_U
KEY_O KEY_Y
KEY_J KEY_N
KEY_K KEY_E
KEY_L KEY_I
KEY_smcol KEY_O
KEY_N KEY_KKEY_Euro KEY_Z
KEY_Z KEY_X
KEY_X KEY_C
KEY_C KEY_V
KEY_V KEY_B
KEY_B KEY_Euro
Yeah, no LEDs. Would be nice to implement though, it's one of my hopes in having a new controller (which is why the AIKON looks so tasty I think).
I am concerned that for whatever reason the matrix may be different. I don't see why it would be but it's a concern we need to be prepared to address.
That photo of the 122-key controller, the second-largest IC is a 4-16 line MUX, and so there are actually spare unused I/O lines, based on a schematic I have seen for this item, courtesy of Keyboard Babel.
And I have mapped out the matrix of my IBM 1390702 122-key terminal keyboards.
Wow, this is some awesome work! It might be the thing for getting a Colemak board on my PS3, even. Then it'd have to support some cheap sacrificeable keyboard that I have lying around...
Just downloaded and started browsing your code. One thing: It's 'Tarmak', not 'Tarpak' and its full name is 'Tarmak (transitional Colemak)'... I think. The idea is that like a tarmac it's paving the way! :) I'm quite proud of it, to be honest, and honored if you'll want to implement it.
What's the VK_102 key called, by the way; is that the 'KEY_Euro'? I'd like to do theZXCVB< ergonomic shift while I'm at it. Would be wonderful if that could be done independently from the QWERTY/Colemak/Tarmak remaps since it can be used in any of those layouts (albeit not in Dvorak obviously... that I've heard of at least; some Dvorak users might want to do it there too maybe?).
Yes, it's called KEY_Euro for some weird reason. Maybe I should check the USB HID specs in order to find a better name based on the name it has been given there.
Is that mapping complete? I can add it to the source tree then.
The shift mapping can be applied independently already since the script that processes the matrix definitions and key mappings can handle multiple map files. At least with Colemak it will work because the affected keys are not part of the Colemak mapping.
It doesn't work for Dvorak at the moment because the script simply assumes that all mappings are independent (otherwise the order in which the map files are passed to the script would become important). I'll think about a good solution.
There are only a few keys that I couldn't find USB equivalents for: "PA1/Dup", "Attn", "ErEOF", and the two blank keys on the far left in the bottom row. What is the purpose of these keys?
- I think I saw it called KEY_Euro2 in a USB spec? Even worse name, haha.
- Yes, the ZXCVB shift mapping is complete; it's a small but nice trick that 'anyone can use'.
Much wants more as they say: Could there be an on-the-fly-remapping/extending possibility like the HHKB2's Fn key ('Extend' mode in PKL)? E.g., I press CapsLock and now the UNEI keys become bona fide arrow keys (and much more! - hopefully including making some keys into modifier keys!). Or, I press Ctrl+CapsLock and now the UNEI keys will send 5 arrow key presses per click until I release CapsLock again. Or, I press Alt+CapsLock and now the LUYNEIKM,. keys become the NumPad... etc etc.
Plus, it supports AVRdude - which I saw as a sign of good karma for me since I have no idea what I am doing.
Thanks for the suggestion Mnemonix. This one also appears to have excellent documentation. PDF users manual link (http://www.protostack.com/download/Users%20Guide%20%28AC-PG-USBASP-UG-V1.1%29.pdf).
PA1 is an interrupt key
Dup copies the character from the previous line to the current line
Attn is an interrupt key
ErEOF erases from the cursor positon to the end of the current unprotected area
Pay close attention to how I numbered the illustrations of the cct connectors, ie number 1-end on the top, and 0-end on the bottom.
I see microcontroller circuits listing '0' as the first numeral, and on the cct board itself, '1' as the first numeral. That is why I labelled them as I did..
looks like all inputs and outputs could be handled with three lines...not to say that other problems could arise if that was done...
...and several other possibilites come to mind as well.
And since there is talk of Colmak and DVorak here...look at 'XPert Keyboard': http://www.xpertkeyboard.com/index.htm
I cannot find USB key codes matching any of those. There are codes for other funny keys like "Help", "Menu", "Select", "Oper", and some more, but no interrupt keys. We could make them media keys, though... I wonder which codes a USB converter would send when seeing the scan codes for these keys.
Well, the rough equivalent to PA1 would probably be Ctrl-Break, and Attn would probably be SysReq. ErEOF equates to the key sequence '+ + , ', and there is nothing like the Dup key (also known as 'CopyUp').
And since there is talk of Col[e]mak and DVorak here...look at 'XPert Keyboard': http://www.xpertkeyboard.com/index.htm
And in a previous post, where I was talking about shift-register I/O expansion, and I mentioned there are more possibilities...
Basically I was thinking of various combinations of master/slave controllers to take care of pin shortages...but that (for me anyway) assumes DIP devices at 2.54mm (0.1") centers, not surface mount.
Being old-school, I use those devices on perf-board, and sometimes wire-wrap.
If SMD and other packages are acceptable, then simply get a device with the appropriate number of I/O pins and be done with it...no fooling around.
(and a couple of times corrugated cardboard)
But a circuit board is to be preferred, one that can be made at home that is...using these DIP devices.
I do believe that ATMega devices can be connected to each other via I2C bus...?
Acid + Base => Salt + Water.
That schematic reminds me - what do the jumpers do? I thought at first they were LED headers but they're not.
While I am just sourcing parts at the moment, could you by any chance do a map for a 1391406? I'm not sure I understand just how to map it myself.
When I'm done I'll publish a Mouser parts list with parts for US Geekhackers.
BTW - the Molex USB connectors are great - better than the cheap ones.
The '406 should be the same as a '403, except for key caps, no?
The two "ISO keys" are recognized by the '401 firmware, and I have tested the controller with the '401 firmware inside a '403 and two US Minis. I think it would work with a '406, too.
WRT the membrane connectors.
I suspect that using Card Edge connectors, and pushing the pins further out than normal should grip it nicely. If not, and the connections are only connected on one side, then maybe something to pad it out?
Whoa, this thread totally took me by surprise.
(I did the RUMP board/firmware.)
0022023083 (eight pins)
0022023123 (twelve pins)
0022023163 (sixteen pins)
Sounds feasible to me, but spacing may be off. I think an 8-bit ISA slot would be the closest match.
Just thinking...if you were to do that for the 8 row lines using the proper shift register and leaving the column lines direct connected...would that not have been maybe easier programming-wise as well as...well...conceptually, a "neater" design?
also, i know your preference is usb for the interface...but would it be feasible to have this controller operate in ps/2?, perhaps mode-selectable by jumper?
A terrific project, and many thanks for sharing your information with us so freely.
Ok, I've been following this discussion for a little while now, and I have a question about the idea of the SD card.. Will the said controller with SD card be recognized by any computer in ANY way as being a form of portable media or other data storage device?
...so I don't get the old "security escort to your exit interview" routine for hooking up the new controller at work.
And...an amusing thought of taking the shift register thing to it"s silly extreme...ha ha...use a 74HC165 chained to three 74HC595, all of them 8-bit shift registers...the first one for the rows...and the 74HC595s for columns....for an 8x20 grid setup...you"d have four SR outputs free after taking all matrix I/O into account...and these four lines could be used for the three lock LEDs...and the last to perhaps drive an audio beeper...and all for the cost of two or three I/O lines on the MCU !!
I'm a lazy bastard, and so I've moved on to MCUs with more GPIO pins and USB in hardware (I reimplemented the RUMP design on the PIC18F4450, and I'm seriously considering reimplementing everything AGAIN on a Cortex M3 because those have up to 51 GPIO pins).
Too bad bluetooth isn't more readily hackable and available. I'd love to have a Model M with native bluetooth built in.
And the last I"ll mention on shift registers...are you familiar with "Johnson Counters"?
The shift register numbers I quoted are from another reference on I/O expansion I have. (Attached below). Different and more extensive than the one I linked to several postings back.
What Crystal Oscillators am I looking for? Any particular part numbers you recommend?
Hm, that PIC18F4450 looks nice, and they come in DIL-package, too. Maybe a little short on RAM, and no EEPROM. But an external serial EEPROM is not that expensive... Too bad that Atmel doesn't offer their USB MCUs in DIP.
Do you have a web site for that project, or is it all private for now?
And an ARM Cortex would rock for sure. :)
AvnetExpress does have them, but difficult to find.on the Avnet site....
No web site yet; I still haven't been able to come to an agreement with Microchip about code licensing. I want to release all the firmware code open source—I don't particularly care about GPL vs LGPL vs BSD; I just want other people to be able to build off it like they can with the AVR-based code, but Microchip seems to be allergic to open source. Of course, you need Windows to build the code anyway, because their tools are Windows-only and kind of hostile to Mac and Linux environments.
It was super-frustrating to get the PIC18 working properly, but it does a great job now, and it does have actual USB in hardware instead of the (fantastic) emulation that AVR-USB does. It seems like the Cortex chips might be as easy to work with as the AVRs, while still providing the same cheap prices and in-hardware USB features as the PIC18s.
Ah yes, licensing problems. You've told me about those problems; sorry to hear they are still acting like a child. :(
I didn't know the Cortex chips were that cheap. Wow. This makes the PIC18s look even less attractive, despite their native USB support. Unfortunately SMD only.
I suppose that the problems with licensing and devtools are less severe or even non-existent with the Cortex chips, right?
I was slightly exaggerating; they're in between the prices of the PIC18s and the AVRs, slightly closer to the AVR prices once you get into large enough orders.
Licensing-wise, I hear that things are much better on the M3, and devtools-wise, I can build the code using gcc (so pretty much anywhere) and in theory flash it to the MCU without a programmer. I'm pretty excited about that!
(On the LPC1343, the Cortex-M3 instance I'm currently looking into: if you wire it up right, it shows up as a USB Mass Storage device with a single file in the root folder named 'firmware.bin'; you can read the existing firmware simply by copying this file somewhere else, and you can overwrite it by copying something else over it.)
Ill buy one :) (or 4)
You can bet I'll do this (for a 122), maybe even twice (as I've got two of the boards) if I get all the parts together.
That's great! :) And you have the hardest-to-obtain parts already: the connectors. The rest should be easy.
Did you get the connectors as samples from Molex?
Hint: for the 8 pull-up resistors (R9--R16) in the LED version you could use something like Mouser 71-CSC09A01-22K instead of 8 separate resistors (it doesn't really matter if it's 20k or 22k; I've also tried 10k and it worked). Compact and cheap enough.
I'll have to review the whole article/thread, but everything has a part number provided right?
Oh, and yes, since I've not the money to dedicate to a programmer, I'll be asking someone to please write the bootloader and write-protect it then ship the chip to me.
I'm afraid that Mouser is not so popular here in Germany, and our Reichelt is probably totally unknown outside of Germany. That's why I didn't write part numbers anywhere.
Ripster was going to make a Mouser parts list for the 1391401 controller, he said. The 122-key part list would be the same, plus a 74HC165 and the pull-up resistors. And with a 20-pin connector instead of 16-pin.
Well, I could certainly do that, but it would probably be cheaper to have it shipped from your continent.
Can't be more than maybe 5 Euros (for an envelope with two uCs), could it? Assuming the microcontroller is cheap (I haven't priced it out yet) this is something I could certainly accommodate (via PayPal).
Shift register 74HC165:
Digi-Key has two different ones, only difference seems to be operating temperature, and the better one seems to be cheaper.
Mouser's site is a bit of a mess...I can't narrow it down by package so here's the search result for what's in stock only.
http://ca.mouser.com/Semiconductors/_/N-5gcbZscv7?Keyword=74HC165&FS=True
And there's always this:
http://cgi.ebay.ca/ws/eBayISAPI.dll?ViewItem&item=260513509531
Someone let me know if this is suitable...I'll buy it if so. 'Lot of 3' being the key words.
Edit again:
Out of the following, which is most suitable (if any):
http://focus.ti.com/docs/prod/folders/print/cd74hc165.html
http://focus.ti.com/docs/prod/folders/print/sn74hc165.html
http://focus.ti.com/docs/prod/folders/print/sn74hc165-q1.html
http://focus.ti.com/docs/prod/folders/print/sn74hc165-ep.html
Which ATMega32 should I be looking at?
http://www.rapidonline.com/sku/Electronic-Components/Integrated-Circuits/Atmel-Microcontrollers/ATmega-8-bit-AVR-Microcontrollers/77086/73-4282
I'm making this simple 1 key circuit (http://blog.flipwork.nl/?x=entry:entry081009-142605:) first. I'm no programmer so I figure if I start slow I can learn as I go.
Now, I'm a relative n00b with low-level circuit design, so I'll ask a dumb question:
What's the wattage for the resistors?
Also, are there any more missing figures of questionable obviousness that are important when buying these supplies?
I imagine since this is USB that the voltage for everything is 5V...correct if wrong please.
What's the wattage for the resistors?
Also, are there any more missing figures of questionable obviousness that are important when buying these supplies?
I imagine since this is USB that the voltage for everything is 5V...correct if wrong please.
Edit:
Bought some things and ordered some free samples of some things. Here is what I've already got or will be receiving soon:
-Programmer, one of the ones recommended in this thread (small red one)
-6x1 pin header (2)
-The 3.6V diodes (1N4729 in my case, hopefully they'll be suitable)
So that would mean what I still need, as I understand it, is:
-Stripboards
-Resistors
-Capacitors
-1N4148 Diodes
-Crystals
Edit: something just occurred to me...anyone building one for an old-style 122 is not actually going to need a USB jack, unless you mod the case quite a bit. You can directly solder the wires in place from a USB cable, or if you use a USB plug you can put it inside the case without the ability to unplug it.
Would 22 kilo ohm resistors work instead of 20?
If not, will the design still function properly using diodes as originally shown?
Check out Tyco P/N 7-520355-0. It's the 20-pin as seen in a 122-key.
So there is no big enough hole for a full-size USB jack? Bummer. Maybe a mini USB connector would be small enough.
You could also make a USB rat tail instead of a long fixed cable, i.e., a very short cable looking out of the case with some USB connector at its end. I wouldn't solder that cable directly to the controller, but connect it to 4 jumper pins (otherwise you couldn't remove the controller from the keyboard anymore).
As Specter_57 mentioned already, it doesn't really matter whether they are 20k or 22k. I'll change them to 22k in the schematic because those are in the E12 series, thus more common. A compact part such as Mouser's 71-CSC09A01-22K would save you quite some space.
Please forget the old design with diodes and 74HC164 register. It requires a different firmware, which I have removed from the source tree already. I guess no one has ever built this circuit anyway, so there's no point to support it any longer.
Kishy.
Your 122key terminal board...turn it over, look at the back.
On the right-hand side, toward the top of the board, you will see a small rectangular opening with (in my three boards) a plastic tab, which can easily be removed...or left in place and used to mount the connector.
You can mount your socket inside at this point...maybe have to do some small amount of mechanical work inside, but that is a possible location.
When the boards feet are up, should be no problem with angling issues.
Consider using "Shapelock" or "Friendly Plastic" for the mechanical mounting work if not using that plug I mentioned above.
Just a thought.
.............
Spec 57
.end
Show Image(http://geekhack.org/attachment.php?attachmentid=7739&stc=1&d=1265484773)
With regards to the Mouser part you suggested, I don't actually know how to use one, nor can I visualize how to fit it into the circuit.
1 --------+
|
2 ---R1---+
|
3 ---R2---+
|
4 ---R3---+
|
5 ---R4---+
|
6 ---R5---+
|
7 ---R6---+
|
8 ---R7---+
|
9 ---R8---+
Alrighty...everything except the stripboard is either here or on its way. Stripboard is difficult...can't seem to find reasonable pricing or acceptable products online and I'm having no luck finding a local supplier for such a thing. Rather frustrating.
Edit: something just occurred to me...anyone building one for an old-style 122 is not actually going to need a USB jack, unless you mod the case quite a bit. You can directly solder the wires in place from a USB cable, or if you use a USB plug you can put it inside the case without the ability to unplug it.
Quote from: microsoft windows;148962How does the cable attach to the keyboard controller?
Soldered ribbon cable, or a more rigid version that was available in the 80s. As soon as I saw that, I was not going to open it up any further.
There's more to it than that, in fact...because the F design relies on a capacitive switch the controller is quite different if I'm to understand this stuff correctly. It's been mentioned here that this should only be expected to work for Model M type boards.
Anyone here want to make these and sell in the classifieds section?
Im sure if we got a few out there, we would start seeing USB Model Ms on ebay ;)
But as I take it, the Model M ones are fine? Interesting if that's the case.
The only downside is that you still have to either remap the layout or deal with the source code. The question is then, can one do a multiple key-to-one map with it?
Regarding running out of space, could we move up to a larger capacity 16MHz Atmel AVR (for example ATmega128)?
If it's the same except for the nonvolatile storage then we're looking at an easy upgrade path without additional hardware added or significant code changes (I think).
The shift mapping can be applied independently already since the script that processes the matrix definitions and key mappings can handle multiple map files. At least with Colemak it will work because the affected keys are not part of the Colemak mapping.
It doesn't work for Dvorak at the moment because the script simply assumes that all mappings are independent (otherwise the order in which the map files are passed to the script would become important). I'll think about a good solution.
I have some contacts in the PCB design/manufacture industry in the UK. One in particular is a specialist in low-volume runs. No promises whatsoever (Cost is likely to be prohibitive, even at "mates rates"), but I'll certainly ask around. I assume someone can supply Gerber files if it looks feasible?
Hope you come up with one!
How many typical LEDs could be driven by this controller?
1] The sum of all IOL, for all ports, should not exceed 200 mA.
2] The sum of all IOL, for port A0 - A7, should not exceed 100 mA.
3] The sum of all IOL, for ports B0 - B7,C0 - C7, D0 - D7 and XTAL2, should not exceed 100 mA.
Look for super-high efficiency LEDs...
KiCad can produce Gerber files, but we need a PCB layout first. At the moment there's only the schematic, and maybe the Dulcimer PCB design as a starting point.
Are you thinking of just the PCB or fully assembled boards? I mean, if one of the manufacturers could fit the components for us, then it would make sense to design an SMD version, which is probably cheaper (smaller, fewer drill holes, cheaper components).
Ok, having had a word, it's a "suck it and see".
I am owed a favour or two from the Low Volume specialist (Built his servers at a low cost), and he's agreed to do a small (10pcs) run to see how things pan out. He can do SMD component placement and from having a look at the schematic, says's it's not a problem apart from cost. It get's much more acceptable at >100 pcs. I have no firm figures yet, but when we get something sorted out I will yell. I suspect we would need to coordinate a "Group Buy" to get some decent prices.
In the meantime, my order is in at RS for a Crystal's and ATMega32's. I have four boards sitting here just gagging for this mod.
Shipping from there to here is not much more than between US-Canada depending on packaging and service used. The cost of the part itself would be substantially higher...probably approximately $35+ each on an order of 100? Obviously that's a guess, you'd be best to wait for a quote from the guy who'd be doing it.
He would be marketing these himself, and to GH member's only, at a cost price until the first run is used up. He will get an idea if this is a marketable, if niche, product. I suspect that the initial run (~100) will be the bulk of the orders.
It's not going to happen for a while, as he is Flat-out with work at the moment (considering the economy sucks balls, that is a rarity, and his paid work will naturally take priority). He will give me a heads-up and contact details. He will confirm pricing at the same time.
He's going to have a look at my finished product, along with an original controller board. He's not sure if SMD or Manual placement will work out cheaper (Doint things the SMD route will interrupt his line, and require programming of the line for this board, he doesn't do too much with MicroProcessors despite having the capability to handle even heavy duty stuff). I've said as long as it fits and works, it's all good, though a drop-in replacement for the original would be great. Given the above, and the fact that they will need manual finishing even if done SMD (Berg and Membrane connector, LED's), the Manual route looks likely at the moment.
WRT import/export to other countries, that's fine. All the parts and processes used are ROHS compliant, and he's happy to ship overseas at cost. This would be done in batches though, he doesn't want to have to package up stuff every 5 minutes or so.
Oh that's right, the 122s need a slightly different design. I keep forgetting the controller is by default for 'normal' Model Ms...for me they only apply to the 122s so that's all I focus on when I talk about them.
So yeah, sethstorm, you'd be building your own for a 122 regardless of what insancen can arrange.
Hmm. So much for a properly done board. While I be able to put the parts together, the programmer bits are what would be the stumbling block.
What page had the parts list for it? I figure they're slightly different, just enough that the parts for the 122 board are different than the Model M ones are.
He would be marketing these himself, and to GH member's only, at a cost price until the first run is used up. He will get an idea if this is a marketable, if niche, product. I suspect that the initial run (~100) will be the bulk of the orders.
He's not sure if SMD or Manual placement will work out cheaper (Doint things the SMD route will interrupt his line, and require programming of the line for this board, he doesn't do too much with MicroProcessors despite having the capability to handle even heavy duty stuff). I've said as long as it fits and works, it's all good, though a drop-in replacement for the original would be great. Given the above, and the fact that they will need manual finishing even if done SMD (Berg and Membrane connector, LED's), the Manual route looks likely at the moment.
insancen, fancy asking your connection about throwing together AIKONs too? That's another open source project as I understand it so all needed docs are floating around online.
What page had the parts list for it? I figure they're slightly different, just enough that the parts for the 122 board are different than the Model M ones are.
100% of my needed parts are here now.
I'll be playing with laying out parts on the board (the stripboard I have has the copper strips going the 'wrong' direction) and perhaps coming up with photos showing a decent layout for a 122.
Keep in mind that, at least with the original 122-key terminal M design, the controller doesn't mount into a spot on the case...it's screwed onto the metal backplate, so there's some flexibility afforded by that.
It's just a matter of component placement. The "wires" still go the same way, the schematic hasn't changed. My controller will be significantly smaller than the Prototype (That is why we have prototype's, make it, see it works, improve it. Without the initial prrof-of-soncept, there isn't a 2nd or 3rd revision etc).
Indeed. I just dont like splitting up an already-fragile stripboard just for the alignment.
Now if there was something a bit more reliable than compressed paper-board to solder onto, I'd be less likely to just skip to the finished boards.
Fibreglass board.
If Kishy would be so kind as to post a picture...
It's much more substantial than the normal Veroboard. It also doesn't smell.
I'm fine with standard stuff. I built an Amp about 10 years ago on it, and it's still going strong. Hell, my Glass-density analyser for my A Level project (A looooong time ago) is still working perfectly on veroboard (The Final on PCB is still used in a factory today surprisingly enough!)
Yes, what he sent me is awesome stuff...it's almost like plastic in the sense that it's got no smell, texture is smooth, thickness uniform, all that stuff.
I'd be happy to post a photo but I've hacked it apart into two pieces for my two controllers. Had been hoping to clean up the rough edge before showing it off...and ideally also finish the board...but oh well, I will anyway, you can all lawl at my bad construction techniques. Decided to go with 'simple' design for the first, LED design for the second.
I gradually realized more and more that I'd have to run a little wire lead for ALL of the FFC connector pins regardless of what I did, so I just threw em on there with no regard for pin alignment with the AVR socket. I highly recommend nobody do it the same way I have, it's going to be very messy with 28 little jump wires in the finished item.Show Image(http://geekhack.org/attachment.php?attachmentid=8202&stc=1&d=1267829735)
Need insight from mnemonix...
When altering the firmware for 122-keys, did you take into account the fact that the ribbon connectors are backwards, with regards to physical connection?
(comparing the beginnings of mine to your finished product, the connectors are in backwards order and it seems to me that means the pins go "20 to 1" instead of "1 to 20" and "8 to 1" instead of "1 to 8")
The only possible fix would have to be in the firmware as it's not physically possible to arrange it any other way. Please investigate. I could be wrong here but before I go much further I want to make sure that's not going to be an issue.
Looking good. Is there a way to position things so that you can use ribbon cables to wire up the 'cardedge connector' to the ATMEGA? It would seem a bit easier that way to keep things together.
I took the picture of your controller from #37 (http://geekhack.org/showpost.php?p=149857&postcount=37) and the matrix info posted by Specter_57 as a reference. I've seen that, like on the Model M, the connectors are mounted in opposite directions, but the pins are numbered 20...1, 8...1 from left to right (both, on the controller and on the matrix info). So I used the numbering scheme suggested by the numbers on the controller to write down the matrix definition file.
You can check whether or not I messed this bit up by making sure that Left Control is attached to the right-most contacts on the two connectors (corresponding to column 1, row 1) when plugging the matrix sheets to the controller. Similarly, the left-most contacts (column 8, row 20) should go to the Enter key on the numpad. If not, there is some problem...
By the way, I took a closer look a Ripster's Boscom matrix images, and it seems like the Boscom matrix is a bit different from the 1390702 one... (or I got confused by all those labyrinthine lines on the pictures)
I've chosen the chip-pin-to-connector assignment so that eight contacts of the 20-pin connector can be attached directly to the pins on the MCU (either rows 20...13 to MCU pins 40...33, or rows 12...5 to MCU pins 29...22). This may or may not be of any help, but at least there are no crossing wires this way.
In case the connections are wrong and need to be rearranged, it is easy to juggle rows and columns around in the firmware. The boot loader may need to be fixed separately then, though; but you have a programmer, so that's not a problem.
C:\Documents and Settings\Kevin\Desktop\avrdude-5.4-win>avrdude.exe
Usage: avrdude.exe [options]
Options:
-p <partno> Required. Specify AVR device.
-b <baudrate> Override RS-232 baud rate.
-B <bitclock> Specify JTAG/STK500v2 bit clock period
-C <config-file> Specify location of configuration file
-c <programmer> Specify programmer type.
-D Disable auto erase for flash memory
-i <delay> ISP Clock Delay [in microseconds]
-P <port> Specify connection port.
-F Override invalid signature check.
-e Perform a chip erase.
-O Perform RC oscillator calibration (see
-U <memtype>:r|w|v:<filename>[:format]
Memory operation specification.
Multiple -U options are allowed, each
is performed in the order specified.
-n Do not write anything to the device.
-V Do not verify.
-u Disable safemode, default when running
t.
-s Silent safemode operation, will not as
fuses should be changed back.
-t Enter terminal mode.
-E <exitspec>[,<exitspec>] List programmer exit specifications.
-y Count # erase cycles in EEPROM.
-Y <number> Initialize erase cycle # in EEPROM.
-v Verbose output. -v -v for more.
-q Quell progress output. -q -q for less.
-? Display this usage.
avrdude project: <URL:http://savannah.nongnu.org/projects/avrdude>
Alright, so it's in a state I can program it in, but then I hit a roadblock. AVRDude isn't GUI?!?!
$ avrdude -p atmega32 -c usbasp -U lfuse:w:0x1f:m -U hfuse:w:0xd2:m
$ avrdude -p atmega32 -c usbasp -U flash:w:boot.hex
$ avrdude -p atmega32 -c usbasp -U flash:w:main.hex
$ avrdude -p atmega32 -c usbasp -U lock:w:0x2f:m$ avrdude -p atmega32 -c usbasp -U lfuse:r:-:h -U hfuse:r:-:h -U lock:r:-:hReference to GUI was because I thought I had seen, somewhere in the vast expanses of the internet, a screenshot of a GUI program and a reference to AVRdude together, suggesting the screenshot was of AVRdude. Apparently not.
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9500
avrdude: Expected signature for ATMEGA32 is 1E 95 02
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: reading input file "boot.hex"
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: writing flash (32632 bytes):
Writing | ################################################## | 100% 11.38s
avrdude: 32632 bytes of flash written
avrdude: verifying flash memory against boot.hex:
avrdude: load data flash data from input file boot.hex:
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: input file boot.hex contains 32632 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 9.69s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xff != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK
avrdude done. Thank you.
First command worked like a charm. Second gave me an issue.Code: [Select]avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Code: [Select]avrdude: Device signature = 0x1e9500
avrdude: Expected signature for ATMEGA32 is 1E 95 02
Code: [Select]Writing | ################################################## | 100% 11.38s
Edit: oh yeah, no longer using the version of avrdude I indicated earlier. It said no libusb or something like that so I went looking for a more functional version. WinAVR (as a suite) is what I downloaded, newest version, in it you can find the version of avrdude i'm using now
When does mass production start? I'd like to pre-order a couple :)
BTW this thread is blatant discrimination against those of us who are neither hardware nor software savvy.
Let's see what InSanCen can arrange. Seems like there is indeed a market for these controllers.
Is this a request for better documentation? :)
When does mass production start? I'd like to pre-order a couple :)
BTW this thread is blatant discrimination against those of us who are neither hardware nor software savvy.
I am working on a PCB layout.
As an aside, he's loving the loaner M i let him have to evaluate the physical space we are working with. All we need is for him to make an account here... ;-P
Cool, thanks for spending your time on this project! :) Can't wait to see the result.
Would you care taking the dimensions of the smaller Model M Mini into account, too? There's less space in vertical direction in a Mini, so you'd need to be careful placing big parts not too far from the back of the case. I could take pictures and measure the available space for you.
OOOOooooo. Model M Mini PCB - sign me up!
Here's the dimensions.
...Good Pictures and Metric Numbers...
USB Mini Layout would be great for me! Let me know if you need any other measurements or bigger pics.
OOOOooooo. Model M Mini PCB - sign me up!
Here's the dimensions.
If it can, the finished product will be the size of the Mini's board. This is assuming that the controller is identical, and will just not use the rows and columns for the Numpad. If these can be left floating, then no additional work is needed. If they need to be tied low, than I think a switch could toggle between M and Mini modes.
I also had a quick chat with the guy who will be making these. Having looked into it, he think's it would be more feasable to do a PCB only run for .1 components. Just sounding out for interest, as he will have spare capacity on that line before he does on lines handling components.
We also chatted about timescale. Bad news. Assuming no order cancellations, he's flat-out busy for at least 3 months (PCB only) and 5 months (Full board, assuming he finds a suitable connector for the Membrane to PCB).
.1 components means 0.1 mm pitch? As long as the 2.54 mm pitch membrane connectors fit in there somehow, why not?
Hm, better late than never. How many units would he want to produce?
.1", or 2.54mm
He is producing, regardless. this is me calling in favours. If viable, he will produce more afterwards. The initial run will be ~100 units.
I hate FPC/FFC connectors.
Once you guys get this working, would it be a big step to wireless bluetooth? I would guess that an internal AA battery or two could supply the current, and some kind of USB to Bluetooth keyboard adapter could also be built in? Those might not exist though, I really have no clue.
InSanCen, could you include four empty soldering pads to the USB lines on your design? This way one could connect the controller directly to some Bluetooth hub/converter without using USB plugs.
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.This is VERY frustrating.
I checked my wiring, everything seems correct following the 'simple' schematic. I've retraced it 3 different times and find nothing different from the schematic. However I still get these weird errors.
Now I'm getting this on any command:
Considering that voltage supply may have been the issues, I tried without using the programmer jumper that supplies power. For voltage I tried using a powered USB hub, with no USB connection to computer, plugged into wall. Nothing changed at all regarding errors.
Tried with my second AVR, same crap.
Do we suspect faulty programmer, or what? I told eBay seller I suspected one or both chips may be faulty (to make sure they are aware of it before any deadlines come up) so they're waiting to hear from me if I think it's the chip(s) or not. I would like to know myself...
Did you check for bad solder joints? Sometimes they look good, but make only a bad connection.
On any command, even when trying to program or read out the fuses? If you've successfully programmed the fuses to the values I've posted here before, then you'll have to make sure that the crystal is hooked up correctly, even for programming. This is because the fuse settings instruct the AVR to use an external oscillator for its clock. The "target doesn't answer" error seems reasonable if there's no clock.
So probably not a power problem, but if you have other USB ports, you could give them a try, too.
Is the second AVR pristine, i.e., with the fuses still in factory settings? If so, it should respond even with no external oscillator attached. We could rule out a bad crystal then.
Hard to say what's the real problem. Could still be a pure software problem. Did you upgrade to a new version of avrdude already? Also try running avrdude more verbosely (like -vvvvv) to see what's going on. The example in the manual for the programmer sets option "-P usb"; I've never needed that one, but it could be a Windows thing (OTOH, it seemed to work for you w/o -P before).
Did you try Linux instead of Windows? A live CD like the Ubuntu installer should be enough for testing. Avrdude can be installed while running the live Ubuntu system, without touching your harddisks.
No, I don't trust Windows. ;)
If you have a breadboard, try setting up a minimal circuit just consisting of the AVR, the crystal oscillator, the three capacitors, and the 10k resistor. Leave out all the USB-related stuff. Then hook up your programmer and try again. If the minimal circuit works, then your bigger circuit must be wrong. Without a breadboard, you could still try this with wires, even if it's crude.
Crystal is hooked up in correct position. Dumb question: there is NO type of "polarity" on a crystal, correct?
At the advice of the seller of the programmer, I've started using -B # switch on the commands to slow it down. The device signature problems went away when I tried 0.1, and it appeared to successfully write the bootloader, but then the content didn't match when it was done. It took around 7-8 seconds to do it so it wasn't an "insta-fail".
I can't upgrade to a newer version of avrdude because a newer version doesn't exist compiled and working and including USB support...for Windows.
Regarding -P, apparently "atmega32" is incorrect, BTW. It's "m32". I started making some progress after making that change, but it's back to how it was before. Will try -P usb (you're the second to mention it) on next attempt.
Verbose...if next attempt gives problems, I'll re-do it verbosely and throw the output here.
Linux...do not want, but will try as a last resort. I don't believe the type of issues showing up here CAN result from an OS incompatibility...the inconsistent nature of the failures and the fact that they change somewhat from attempt to attempt tells me this. A pure OS incompatibility would hang up in the exact same way every time because the OS isn't allowing something to happen...
There's a reason I dislike open source software such as avrdude. This is the reason.
Not that it doesn't work...that there's no phone number to call and give them a piece of my mind.
C:\WinAVR-20100110\bin>avrdude -B 0.1 -p m32 -P usb -c usbasp -e
avrdude: set SCK frequency to 1500000 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
C:\WinAVR-20100110\bin>avrdude -B 0.1 -p m32 -P usb -c usbasp -e -vvvv
avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"
Using Port : usb
Using Programmer : usbasp
Setting bit clk period : 0.1
avrdude: seen device from vendor ->www.fischl.de<-
avrdude: seen product ->USBasp<-
AVR Part : ATMEGA32
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page
Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW Max
W ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
eeprom 4 10 64 0 no 1024 4 0 9000 90
00 0xff 0xff
Block Poll Page
Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW Max
W ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
flash 33 6 64 0 yes 32768 128 256 4500 45
00 0xff 0xff
Block Poll Page
Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW Max
W ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
lfuse 0 0 0 0 no 1 0 0 2000 20
00 0x00 0x00
Block Poll Page
Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW Max
W ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
hfuse 0 0 0 0 no 1 0 0 2000 20
00 0x00 0x00
Block Poll Page
Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW Max
W ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
lock 0 0 0 0 no 1 0 0 2000 20
00 0x00 0x00
Block Poll Page
Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW Max
W ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
signature 0 0 0 0 no 3 0 0 0
0 0x00 0x00
Block Poll Page
Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW Max
W ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
calibration 0 0 0 0 no 4 0 0 0
0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: try to set SCK period to 1e-007 s (= 10000000 Hz)
avrdude: set SCK frequency to 1500000 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
I decided to try an erase, since I've read that it's generally needed if you're going to be re-writing the contents of the flash (which didn't seem right, since the entire flash contents seem to be erased before a transfer if avrdude is to be believed, but whatever)
First, we see the non-verbose output:
-avrdude: try to set SCK period to 1e-007 s (= 10000000 Hz)
-avrdude: set SCK frequency to 1500000 Hz
-avrdude: warning: cannot set sck period. please check for usbasp firmware update
-.
-avrdude: error: programm enable: target doesn't answer. 1
-avrdude: initialization failed, rc=-1
- Double check connections and try again, or use -F to override
- this check.
-
+avrdude: try to set SCK period to 1e-07 s (= 10000 kHz)
+avrdude: set SCK frequency to 1500 kHz
+avrdude: warning: cannot set sck period. please check for usbasp firmware update.
+avrdude: AVR device initialized and ready to accept instructionsavrdude: seen device from vendor ->www.fischl.de<-
avrdude: seen product ->USBasp<-
...and why is the SCK period going to 1500000 Hz if I'm REDUCING the number?!?! Shouldn't it be...you know...going down?
I can't sell them because the USB part of the firmware is only for free if not used commercially. As soon as I start selling them, I'd have to pay a license fee.
I also had a quick chat with the guy who will be making these. Having looked into it, he think's it would be more feasable to do a PCB only run for .1 components. Just sounding out for interest, as he will have spare capacity on that line before he does on lines handling components. We also chatted about timescale. Bad news. Assuming no order cancellations, he's flat-out busy for at least 3 months (PCB only) and 5 months (Full board, assuming he finds a suitable connector for the Membrane to PCB). As I have said previously, the first run will be done at cost to GH members (and only "real" GH members, not someone registering just to get hold of it). Because of this, I will *not* let him break production, he is after all, a friend of mine.
EDIT: Argh, sorry, hadn't read far enough through the gargantuan thread to find your own follow up to this! (http://geekhack.org/showwiki.php?title=Island:8406&do=comments&page=10)
I don't think I necessarily qualify as a "real" GH member as I only just registered to take part in this thread (though not specifically to try to buy a PCB!). But if there were one or two boards available too me at a reasonable price I'd be interested. Just the PCB would be cool, an assembled board would also be of interest since I could concentrate on programming it. If it had the bootloader so it could be flashed without a programmer that would be just fine by me!
It will be a while before this materialises. In the meantime, Read, Participate and yeah, sure no problem. You will then be a "Real" GH member... lol.
That comment was meant to deter someone looking to post, get a board, then dissapear for ever more. If you make a contribution to this forum (and if you can program AVR's, to this thread), then you are just as valid as any other GH member.
If I could get one built I think it would be cool to look at getting the controller to emulate other USB devices - most obviously an in-keyboard implementation of using the cursor keys to control the mouse pointer.
From what I've read in this thread it should be possible to convert most membrane keyboards right? As long as the membrane can be hooked up in some way ...
This has potential for me as I have piles of rubber dome membrane keyboards I never use. I'm in the process of getting to grips with understanding how a keyboard works on the electronic level at the moment. As I understand it, for a simple membrane keyboard, the microcontroller is basically multiplexing all the keys onto fewer inputs by scanning rapidly across them?
And all I need to worry about is hooking up the keyboard controller to the membrane, programming it with the row / column count and telling it where the keys are positioned within that grid? Sounds "easy" in principle but I know how "simple" things tend to go, especially in the realm of real electronics :-S
Hm, could be useful in some occasions.
I'd like to get my M4-1 trackpoint supported at some time, but didn't try a lot yet (no time). If mouse emulation over keyboard would be implemented, then some parts of the code could surely be reused for the trackpoint.
Yes.
Many keyboards are IMHO not worth the trouble, though, unless you are modding them for educational purposes. ;)
Yes. Instead of connecting each key switch directly to its own I/O pin on the MCU (so you'd need more than 100 I/O pins for a full-size keyboard), you're arranging them in an nxm matrix (requiring only n+m I/O pins, or fewer) and scan along one dimension. This saves I/O pins, but can introduce ghosting (http://www.dribin.org/dave/keyboard/one_html/) unless avoided in hardware (by adding diodes to the switches).
Yes, where extension of the firmware is the easy part. Tracing the matrix is not very hard, but can be time-consuming. Big matrices (like the 122-key IBM keyboards) require additional hardware.
Connecting your circuit to the membrane can be troublesome if the connection requires some nasty, hard to obtain connector or if there's no real connector at all (glued to the board).
It may also be hard to fit your circuit board into the keyboard case if it's a slim case.
All in all, it depends on the keyboard whether or not it's hard to mod. IBM keyboards are very mod-friendly as it seems. :)
I also got to thinking that a cool concept, if mouse support were available, would be to flip thing on their head - an open source mouse controller with optional keyboard emulation ;-) I imagine that'd be easy for anything mechanical and tricky for anything optical, though.
Does the current code support all of a full-size kb - numpad etc? I'm not looking to look up crazy / cool IBM terminal keyboards just yet ;-)
and as to getting your trackpoint working...if my understanding of the trackpoint is correct...it uses a controller separate from the keyboard...and so it may not be feasible to incorporate it into the ATmega device...and likely unnecessary...but I may be wrong here.
Leotronics looks promising but I don't know what quantities they sell in, I'll send an e-mail: http://www.leotronics.co.uk/template2.asp?id=19
These in particular look about right:
http://www.leotronics.co.uk/196_2604_SERIES..asp?id=19
I will be finding out on Tuesday.
I've now dumped considerable time and money into this and nothing is working.
Changes since last time:
...
-Programmed fuses like instructed. Appeared to work, but went extremely fast. No errors given.
If my new AVR (have two new ones, only touched one) is bricked somehow, I'm going to be extremely annoyed...
Sorry for the tone, I'm just frustrated (hopefully understandably so).
progress bar for reading, 100% in 0.01s
signature 0x1e9502
erases, reads file, detects as intel hex
writes flash (32632 bytes), 100% in 29.75s
verifies entirely properly.
now, when i switch the filename out for main.hex, I get something much less fun.
it detects the file as intel hex, but of 4198 bytes...I thought this file was supposed to contain substantially more stuff?
it writes it "100% in 3.00s", attempts to verify, finds an error. first mismatch at 0x0000. "0x0c != 0x00"
then i get warnings about the fuse values changing, apparently.
lfuse supposedly went from e1 to 0
hfuse supposedly went from 99 to 0
I answer no to these because nothing but grief came from answering yes to equivalent questions with the earlier AVRs...it just hangs if you say yes, and I'm playing it safe with this one.
Same results using value of 1600 for -B, but it did take longer (though it still claims 3.00s).
Same stuff about changing back the fuses. Still saying no to these.
Retrying with boot.hex, same results, but it took longer. Claimed 29.79s...
Why is it telling me it's taking the same time when it clearly isn't?
Without meaning to suggest any incompetence on your part mnemonix can you please 100% verify that the fuse values you provided are correct? I get that initialization failed, rc=-1 thing with the chips that I attempted to set the fuses on. I'm thinking either bad fuse settings or bad crystals or good crystals that don't correspond to the needs the fuse settings create.
$ avrdude -p atmega32 -c usbasp -U lfuse:w:0x1f:m -U hfuse:w:0xd2:m
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9502
avrdude: reading input file "0x1f"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x1f:
avrdude: load data lfuse data from input file 0x1f:
avrdude: input file 0x1f contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.01s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xd2"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd2:
avrdude: load data hfuse data from input file 0xd2:
avrdude: input file 0xd2 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.01s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.$ avrdude -p atmega32 -c usbasp -U lfuse:r:-:h -U hfuse:r:-:h -U lock:r:-:h 2>/dev/nulllfuse 0x1f
hfuse 0xd2
lock 0x3f
lfuse 0x1f
hfuse 0xd2
lock 0x2f
$ avrdude -p atmega32 -c usbasp -U flash:w:boot.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "boot.hex"
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: writing flash (32632 bytes):
Writing | ################################################## | 100% 249.62s
avrdude: 32632 bytes of flash written
avrdude: verifying flash memory against boot.hex:
avrdude: load data flash data from input file boot.hex:
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: input file boot.hex contains 32632 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 194.91s
avrdude: verifying ...
avrdude: 32632 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.$ avrdude -p atmega32 -c usbasp -U flash:w:main.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (5196 bytes):
Writing | ################################################## | 100% 39.72s
avrdude: 5196 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 5196 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 31.07s
avrdude: verifying ...
avrdude: 5196 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.$ avrdude -p atmega16 -c usbasp -U lfuse:r:-:h -U hfuse:r:-:h -U lock:r:-:h
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9403
avrdude: reading lfuse memory:
Reading | ################################################## | 100% 0.01s
avrdude: writing output file ""
0xe1
avrdude: reading hfuse memory:
Reading | ################################################## | 100% 0.01s
avrdude: writing output file ""
0x99
avrdude: reading lock memory:
Reading | ################################################## | 100% 0.01s
avrdude: writing output file ""
0x3f
avrdude: safemode: Fuses OK
avrdude done. Thank you. lfuse 0xe1
hfuse 0x99
lock 0x3f$ avrdude -p atmega16 -c usbasp -U flash:w:boot.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9403
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "boot.hex"
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: writing flash (16248 bytes):
Writing | ################################################## | 100% 122.15s
avrdude: 16248 bytes of flash written
avrdude: verifying flash memory against boot.hex:
avrdude: load data flash data from input file boot.hex:
avrdude: input file boot.hex auto detected as Intel Hex
avrdude: input file boot.hex contains 16248 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 97.05s
avrdude: verifying ...
avrdude: 16248 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.$ avrdude -p atmega16 -c usbasp -U flash:w:main.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9403
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (5196 bytes):
Writing | ################################################## | 100% 39.18s
avrdude: 5196 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 5196 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 31.09s
avrdude: verifying ...
avrdude: 5196 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.Thought I'd add to this discussion as my introductory post.
The final and most irritating change was to the bootloadHID code in order to make it fit in the 162. For some reason the boot code compiles slightly larger on the 162 than the 16, just enough to tip it over the 2kB barrier and stop it from working.
When i get a chance I'll put these changes together and submit them back to the author so he/she can impliment them as they want.
And finally to whet some appetites, I'm working on a proper bluetooth model M, and am fairly confident I can make it work. This isnt a hack with usb -> bluetooth converters or anything (though hackish in other ways), and should be very low power, but it may take me a while as I'm quite busy at the moment.
I'm too much of a wimp to attempt SMT anything!
Wow, that's cool! Beautiful board.
If you like, I can also put the PCB design and changed schematic into the source tree so that they are in some "standard place" where people can find them. PDFs would be great. Or just post them here.
A Bluetooth Model M would be very cool indeed. I'm looking forward to see that one! Are you going to write the firmware from scratch or will you try to extend the Keyboard Upgrade sources?
And could you tell us which Bluetooth chip will you use? Just curious since I've been working on a Bluetooth project last month...
So, I'm new here, so here is a 'practice' post about something simple you folks have mentioned in this thread a few times. I've had good success with ISA slots, so I'm going to try to describe how I do so in the same way I'm going to describe other, hopefully more useful, topics. :)
Anyway, to introduce myself, I'm working on a gaming mod fer 101 and 122 key IBM Model M keyboards.
The first step is documenting modifying the things to be USB keyboards without dropping simultaneous keypresses. Towards this end I've been working on a ps2 signal->USB converter that can handle either 101 or 122 key M's without promulgating that BS 'max 6 keys plus modifiers' tripe. That only applies to keyboards in boot mode - neither linux nor macs, nor 'dose forces that fer HID devices, the HID USB spec even describes how keyboards are supposed to implement their descriptors once a USB aware OS is booted. /endgripe
The next part, however is dealing with the ghosting inherent to matrix keyboards... much pain here resides. Thus I am currently hacking around with replacing bottom matrices, trying to read resistances to better than 1% while retaining the original matrix, etc...
AEhr, as far as I understood the HID specs correctly the device has a "descriptor" of its data format available so the host knows what it can send and receive. The low-level protocol stays the same, it is then up to the host to make sense of the bytes which are sent over the wire. Hence programming a driver is mostly rewriting scan code to virtual key mapping, the only catch is that you have to do it for most OSs.Quote from: dfj;190019Anyway, to introduce myself, I'm working on a gaming mod fer 101 and 122 key IBM Model M keyboards.
The first step is documenting modifying the things to be USB keyboards without dropping simultaneous keypresses. Towards this end I've been working on a ps2 signal->USB converter that can handle either 101 or 122 key M's without promulgating that BS 'max 6 keys plus modifiers' tripe. That only applies to keyboards in boot mode - neither linux nor macs, nor 'dose forces that fer HID devices, the HID USB spec even describes how keyboards are supposed to implement their descriptors once a USB aware OS is booted. /endgripe
True, no one forces you to use the HID specs, only the regular PC BIOSes do.
You'd need to design a new protocol to support more keys being sent at once and write OS drivers for this protocol, but you'd still need to implement the HID specs to get the keyboard to work when the driver is not available (in BIOS, during OS installation, rescue CDs). Since the 6-key limit is not a true limitation for most people, the simple protocol is sufficient in most cases, plus it's implemented already everywhere, so that's most probably the reason why none of the keyboard manufacturers are trying to make anything better.
Maybe one day when PS/2 is really, really finally dead, and if there's demand for NKRO ("demand" as in "worth serious amounts of money"), someone might devise a new protocol and declare it the new "standard" HID protocol for keyboards. Today it's cheaper to just build and sell PS/2 keyboards with NKRO and not putting effort into developing something new for USB.
You know all of this already, I guess. :) Just my two cents here.
Ehr, as far as I understood the HID specs correctly the device has a "descriptor" of its data format available so the host knows what it can send and receive. The low-level protocol stays the same, it is then up to the host to make sense of the bytes which are sent over the wire. Hence programming a driver is mostly rewriting scan code to virtual key mapping, the only catch is that you have to do it for most OSs.
If you want to support the BIOS, you can still allow the keyboard to be put in legacy mode, it just makes the firmware more complex.
Yes, that's what my many words tried to say. :)
Support for more than six keys at a time is possible, but comes at a cost.
Bah, says the bloke what wrote them krazed makefiles. :)
Not that it matters until folks start using the kbupgrade for nkro hardware, but the 8 byte limit applies to each interrupt - you can spec a response bigger than 8 bytes, but it will need to span two ints, with a delay of at least 1m per int, if I remember.
The HID spec is pretty readable, particularly if you skip past the discriptor protocol higher levels to the keyboard samples. They even have a cute mouse+keyboard combined protocol example.
Oh wait, folks _have_ requested that for kbupgrade, no? They want to poke the mouse cursor about using some cursor-ish thang?
char UsbKeyboardDevice::fct_read_remaining = 0;
uchar usbFunctionRead(uchar *data, uchar len) {
if(len > UsbKeyboardDevice::fct_read_remaining) {
len = UsbKeyboardDevice::fct_read_remaining;
}
uchar * buffer = UsbKeyboardDevice::reportBuffer;
buffer += (BUFFER_SIZE - UsbKeyboardDevice::fct_read_remaining);
for(uchar i=0; i<len; i++) {
data[i] = buffer[i];
}
//currentAddress += len;
UsbKeyboardDevice::fct_read_remaining -= len;
return len;
}
if (UsbKeyboard.ready()) {
if (dirty) {
left = UsbKeyboard.sendPartialBuffer();
if (left == 0) {
dirty = false;
}
}
if (usb_queue_count && !dirty) {
unsigned char key = usb_queue[usb_queue_first];
if(usb_queue_breaks & (1 << usb_queue_first) ) {
UsbKeyboard.releaseKey(key);
} else {
UsbKeyboard.pressKey(key);
}
// race laden queue :(
usb_queue_first++;
usb_queue_first &= USB_QUEUE_MASK;
usb_queue_count--;
dirty = true;
}
}
int sendPartialBuffer() {
if(spb_remainder == 0) {
spb_remainder = BUFFER_SIZE;
spb_data = reportBuffer;
}
if (usbInterruptIsReady()) {
if(spb_remainder > 8) {
usbSetInterrupt(spb_data, 8);
spb_data += 8;
spb_remainder -= 8;
} else {
usbSetInterrupt(spb_data, spb_remainder);
spb_data = reportBuffer;
spb_remainder = 0;
}
}
return spb_remainder;
}
.
Here is an interesting read I stumbled across, a design reference manual from Freescale Semiconductor,...."USB and PS/2 Multimedia Keyboard Interface" with a reference design schematic included, and firmware discussion.
The controller design in this thread is electrically and physically simpler than the one presented in the reference document due to the use of the ATmega device, and is to be preferred.....but the document is worth a read nonetheless, in my opinion.
Take a look here at this PDF:
http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM014.pdf
Enjoy
............
Spec_57