deskthority

Hi all,

I've been lurking here for quite a while, and actually followed resources from this forum to bolt-mod one of my Ms ; but this is not about that. It is, however, a good time to say 'thanks' to the community.

I'm kind of a fan of Sun hardware ; incidentally I've grown to like the Sun keyboard layout. Coming from buckling springs, the actual typing experience is... different. The Type 6 is (widely known as) pure crap. The Type 5 is actually rather decent for a rubber dome. Finally, I got my hands on a Type 4, which I found suprisingly good (enough to quickly switch between the Type 4 and the Model M without any trouble or annoyance). The Type 4 is also rare as it is an ISO-Enter US/Unix layout.

So came the project to actually use the Type 4 as a daily driver and convert it to USB. I bought an Arduino Micro, delved into their libs and came up with a converter of my own. Very simple stuff : USB HID over the main 'Serial' port via the Keyboard lib, SoftwareSerial over 'Serial1' aka RX/TX aka pins 0 and 1, through a 7404 inverter on to the mini-din8 port. Read an input from the keyboard, transpose to the appropriate HID key code, pass on to a lightly-hacked arduino 'Keyboard' library, as to allow sending raw keycode (without ASCII translation).

It works like a charm (I'm using the sun keyboard to type part of this message), but it has the same limitation as the arduino's Keyboard library : no support for boot mode, and I don't know/understand enough of the lib to implement it.

That's when I discovered the LUFA library, which does support boot mode, and from there the TMK firmware, which already includes a Sun converter ; so let's try it. It compiles without errors (both on Debian, and on FreeBSD with gmake), loads with avrdude (original arduino bootloader) and... obviously, nothing ; the Arduino does not even come up as an USB device, at all.

The solution, of course, lies within config.h : and since I'm using a hardware logical inverter,
(comment out) Now I do get the arduino recognized as an USB device with TMK' VID/PID ; however, hid_listen only reports 'Reset: 0xFF' on each keypress (and sometimes on its own). In the other direction, none of the magic key sequences (eg, turn LEDs on) seem to work.

So, obviously, something isn't right with the serial communication between keyboard and arduino, but that's as far as I'm able to figure out. I'd welcome any pointers.

Gonna point something a little obvious out, because I had a little trouble with it. Did you install the drivers?

You need to just get arduino and install the whole driver pack. I am not the best when it comes to stuff like this, but I can confidently flash hex. files to pro micros on windows with some help from dorkvader.

Pics of the board would be great. The only sun keyboards I have ever seen are very cheap and flimsy.


Oh, and welcome to DT! It is always great when we get people to unlurk. Good to know the community is growing here and not shrinking.

Drivers ? Shouldn't the board with the TMK firmware be automatically recognized as a keyboard, the way it is with my own arduino-libs-based converter ? Also, as it might have been lost in my original wall of text, I'm not using Windows.

Note that flashing is not the problem, I can flash the tmk-based an my own code back and forth without any trouble. It's just that the tmk-based converter doesn't seem to properly talk to the (physical) keyboard.

I'll put up a thread in the photos forum with a few pics.

I don't know that much really, just a little experience while converting my wyse.

A different forum member would explain or help you better.

I think Redmaus misunderstood a bit. Sparky has already flashed the board (the part that requires drivers on Windows), but the flashed code doesn't work.

Unfortunately I don't have any advice to offer... I'm not hardcore enough to write my own firmware!

Arduino pin name/number is different from AVR name scheme and TMK uses AVR pin names. Check its schematic.
http://www.arduino.cc/en/uploads/Main/a ... ematic.pdf

but it has the same limitation as the arduino's Keyboard library : no support for boot mode

I'm just curious, what is the problem?

hasu wrote: ↑Arduino pin name/number is different from AVR name scheme and TMK uses AVR pin names. Check its schematic.
http://www.arduino.cc/en/uploads/Main/a ... ematic.pdf

OK, re-checking this, the Micro's RX/TX pins are mapped to the AVR's PD2 and 3, as were initially defined in config.h.
I changed them back. I must have missed something before, since I get new (to me) symptoms.

Note, SERIAL_SOFT_LOGIC_NEGATIVE is still commented out since there's an inverter between the keyboard and the RX/TX pins.

So, with SERIAL_SOFT_RXD_BIT set to 2 and TXD set to 3 (original values),

• the arduino shows up in lsusb with the TMK PID/VID, good
• it's properly detected by hid_listen, still good
• left alone, it reports "reset: 0xFF FF" at random interval. Or maybe that was a glitch.
• most keys don't respond at all
• Sun Open, F3, F7, 3, F, Numpad-1, left diamond consistently report (via hid_listen) a "reset: 0xFF"
• E responds with ^[[6~ followed by "reset: 0xFF"
• opening square bracket gives "layout: 0xFE EF" followed by "reset: 0xFF"
• Numpad-+ and right diamond give "layout: 0xFE BF", no reset after
• B gives "reset fail: 0x7E FF"
• The keyboard shows no response to magic keys (tried with both right- and left-shift, and right- and left-diamond)
• and strangely enough there's a 'reset: 0xFF FF / reset: 0xFF' pair reported when I toggle CapsLock on the Model M !

but it has the same limitation as the arduino's Keyboard library : no support for boot mode

I'm just curious, what is the problem?

If you mean, with my own code based on the arduino's Keyboard lib, I can't use it before the OS comes up (eg navigating BIOS options).
If it's regarding the TMK firmware (that would make more sense), it doesn't work out of the box with my setup, as described in this post, and I can't figure where the problem is.

Thanks for your support.

I didn't test the code with SERIAL_SOFT_LOGIC_NEGATIVE commented out. It smells like a bug.


Hmm, not sure but this interrupt should be triggered on 'falling edge'?

https://github.com/tmk/tmk_keyboard/blo ... .h#L63-L64 Try changing the line like this.

hasu wrote: ↑ Try changing the line like this.
(in config.h, line 65)

Code: Select all

    EICRA |= ((1<<ISC21)|(0<<ISC20)); \

Wow, that was quick. It works.

Now hid_listen only prints the actual keystroke, and xev sees codes as expected (I've only got to re-adjust the keymap). It works on a booting machine as well (e.g. boot device selection).

The keyboard still doesn't seem to respond to magic keys (toggling key click, for instance) but I'll search a bit more before I ask about that In a similar vein, my original project called for a DIP-switch bank to toggle certain options in addition/as a default value to soft switches, I'll try and find where to integrate that by myself first.

Thank you hasu, that was amazing.

It wasn't relevant to mention before, but although I don't (yet) quite understand all the actual code of your firmware, I do get a feel for the overall architecture and find it quite elegant. Thanks and congratulations for a great work.

Great

Thanks for the confirmation. I'll fix this bug later.

Some more reporting... I mostly haven't dug deeper yet to find out how to fix what I found.

Most of the Sun keys don't work when compiled with NKRO_ENABLE = yes enabled ; hid_listen reports "add_key_bit: can't add:" and "del_key_bit: can't del:" with the (proper) scancode. Compiling the firmware with that option commented out solves the issue.

The Magic keys mostly work. The Sun-specific ones don't, somewhat obviously since they toggle on navigation cluster keys that the Type 4 doesn't have. The attached diff adds the key codes to use the right/numeric keypad. (Oh, crap. "The extension diff dis not allowed". Inline code below).

I have very quickly tested the Sun-specific options and they mostly work, with a few glitches it would seem. For instance, magic-left does report keyclick enabled, but the keys don't start clicking until it's toggled again. Similarly for the other options (all LEDs toggle, beep). Sometimes the whole thing gets confused and starts beeping until un/replugged from USB. I haven't looked into it further yet, nor did I check where to set the initial value for those options (the only interesting one being key click, of course).

It would seem that the LED support is weird, but I'm not sure the problem lies with the TMK firmware (it might be deeper within the HID support in Linux...). As a reminder, I have a PS/2-attached M connected at the same time as the USB-via-arduino Sun board.

Toggling NumLock or CapsLock on either keyboard activates the corresponding mode on both inputs. The LEDs on the Sun and the M are not always in synch however; sometimes one turns on while the other turns off or the other way around. The actual mode seems to be that when either or both LED (Sun or M) is on, the mode is active, and inactive when both LEDs are off.

That's a bit annoying but it is also an edge case (who normally uses multipe keyboards at the same time ?). Also note that I didn't test with two USB keyboards instead of USB+PS/2.

Below is the quick diff to toggle the Sun-specific magic from the Type 4's numpad cluster. It there's any interest I could also publish my own arduino-libs based converter code.
That's all I have for now. I'll keep using the keyboard with the now-working TMK firmware, debug what I can and keep you posted.

Thanks again

On my side NKRO works with my converter which uses ATmega32u2. With NKRO keycodes out of range(0x78-) cannot be sent but normal keycodes should not have problem.

My Sun keyboard has no speaker and I can't confirm Bell and Click commands but it seems like LED, Layout and Reset commands works at least. These command implementation is experimental and wasn't tested thoroughly, to be honest I don't use them. You might want to check spec to debug Sun keyboard commands.
http://kentie.net/article/sunkbd/KBD.pdf

I found the converter misses the first LED update from host when it starts. Seems like we have to wait for the keyboard coming up before throwing LED command to the keyboard. This patch is too adhoc but cures this problem. Otherwise looks to me like LED works well, I don't have PS/2 keyboard at the time but LEDs are in sync between three USB keyboards on Linux box.

Nice to see some Sun love. What are the chances of an SGI converter? (Yes, I'll be *that* guy… my SGI Granite's mint but useless, halp!)

If you happen to own a Indigo2, Indy or newer keyboard - well they utilize a PS/2 interface.

Nope, I've got the original Granite:



Cleaned it up since this picture. Nice thick caps, sweet switches, and even the insides are too pretty to tear out for a Dell transplant. I'd much prefer to use a converter than have to hack it up.

It seems I can't get consistent behavior from the keyboard with regards to the LEDs and magic keys/options. Sometimes it works right off the bat, sometimes not at all.

As I understand it, the code itself to toggle click, beep and LEDs is correct (matches both the specs from Kentie and my own firmware)

Attached is a quick report, I'll try to come up with a better test sequence ; I'll also try again with a reverted matrix_init.

Note that the 'Resetting... Done' from matrix_init never appears, whether from initial connection, unplugging/replugging or manually resetting with magic+del. There also seem to be a lot of spurious resets.

... "The extension txt is not allowed". What exactly _can_ you attach ?!

I thought back of an initialization bug/glitch I got when developing my own adapter and looked it up ; I got the glitches fixed by simply adding a delay at the beginning of the arduino setup() function.

So I tried it here, with a right before entering the 'Resetting...' loop in matrix_init().
The 750 ms value was found by trial and error. That seems to be the time needed for the keyboard's own hardware to settle.

Now I do get the text 'Resetting... Done' on hid_listen, the click/beep/LED behavior seems more consistent (so far) and there are a lot less Reset events from the keyboard.

I'll run with it for a while and report if I find otherwise.

I pushed some commits to github repsitory, those should solve followings. I don't think the commits solve your current problem, but try when you have time.

- the SERIAL_SOFT_LOGIC_NEGATIVE bug
- LED sync problem when converter startups(pluging keyboard into converter before connecting USB)
- LED sync problem when hot plug keyboard(pluging keyboard into converter connected to USB)


Following output is expected on hid_listen when you connect converter to USB. Seems like your converter has some glitch on initialize USB, maybe Arduino bootloader? But I don't think this is cause of your problem. Very weird, 'a lot of spurious resets' indicates that it sitll has bug on signal handling of serial_soft.c when signal is inverted. Probably you should debug there.

Can you remove 7404 inverter from your converter and try firmware build with original configuration?

hasu wrote: ↑I pushed some commits to github repsitory, those should solve followings. I don't think the commits solve your current problem, but try when you have time.

- the SERIAL_SOFT_LOGIC_NEGATIVE bug
- LED sync problem when converter startups(pluging keyboard into converter before connecting USB)
- LED sync problem when hot plug keyboard(pluging keyboard into converter connected to USB)

Note that I keep the keyboard connected to the converter at all times, I only unplug/plug the USB on the host PC side.

Following output is expected on hid_listen when you connect converter to USB. Seems like your converter has some glitch on initialize USB, maybe Arduino bootloader? But I don't think this is cause of your problem.

(snip)

Very weird, 'a lot of spurious resets' indicates that it sitll has bug on signal handling of serial_soft.c when signal is inverted. Probably you should debug there.

Tried a bit more this morning and no luck. Again, multiple board resets as per the all-leds blinking, resets everywhere under hid_listen (I just saw the board reset while I'm typing this on the M...), LEDs unsynched, no keyclick and multiple attempts carry the risk of driving the board crazy.

I hope it's not related the the arduino bootloader which I'd like to keep ; but I did notice that the 'Reseting... Done' only shows when coming out of the bootloader (just tried resetting the arduino, without reflashing, and I did get the message). Not when plugging the board into USB or resetting through magic keys.

Can you remove 7404 inverter from your converter and try firmware build with original configuration?

Fortunately I'm still on the prototype board, so I can try and bypass it. I'll try it with the latest code and keep you posted.

I uploaded firmware to Leonardo and Pro micro and confirmed they display message properly. Arduino bootloader is not culprit.

Ah, I looked into your log again and I found resets occur exactly when converter send signals to keyboard.
serial_send() of serial_soft.c must be culprit.

Quick update : with the SERIAL_SOFT_LOGIC_NEGATIVE flag enabled and the 7404 bypassed, the board doesn't respond at all. No reaction to keypresses, magic keys etc.

Putting the 7404 back in, commenting out the negative logic flag : with a variable number of "all-LEDs" blink at the start (at some point I counted up to 7), and back to square one with more or less (usually less...) consistent behavior WRT resets, LEDs, clicks etc.

After multiple unplug/plug (from USB host) it seems we *never* get the 'Reseting...', only the 'Done' message.
etc

Similarly key click *seems* to be enabled at first press of the magic key when it works at all (although at this point I'm inclined to say it's blind luck...), otherwise it's doing nothing or going into continuous beep mode. The strange thing being that the logical reports ('Click on' etc) are always correct, so you'd expect the right code to be run.

I'm getting seriously stumped.

hasu wrote: ↑I uploaded firmware to Leonardo and Pro micro and confirmed they display message properly. Arduino bootloader is not culprit.

My board is a genuine arduino Micro (not Pro), which AFAIK is logically equivalent to the Leonardo.

Ah, I looked into your log again and I found resets occur exactly when converter send signals to keyboard.
serial_send() of serial_soft.c must be culprit.

I should have mentioned it before, but I'm coming from higher-level language and application development ; I'm rather new to C and embedded dev. I checked serial_send() and it's a bit too advanced for me at this point

sparky wrote: ↑Quick update : with the SERIAL_SOFT_LOGIC_NEGATIVE flag enabled and the 7404 bypassed, the board doesn't respond at all.

Code: Select all

Waiting for device:.....
Listening:
.........................................................................................................

No reaction to keypresses, magic keys etc.

Something is wrong. I think it must display messages.
Removing 7404 is easier way unless you are willing to debug my software serial cocde.

Putting the 7404 back in, commenting out the negative logic flag :

Code: Select all

Device disconnected.
Waiting for new device:......
Listening:
.............. Done
Keyboard start.

with a variable number of "all-LEDs" blink at the start (at some point I counted up to 7), and back to square one with more or less (usually less...) consistent behavior WRT resets, LEDs, clicks etc.

After multiple unplug/plug (from USB host) it seems we *never* get the 'Reseting...', only the 'Done' message.

Code: Select all

Device disconnected.
Waiting for new device:......
Listening:
.. Done (<- one single all-LED flash here)
Keyboard start.

Device disconnected.
Waiting for new device:......
Listening:
 Done
Keyboard start.
LED: 02 (<- first press on CapsLock, only the LED on the M lights up)
reset: F7
LED: 00 (<- second press, all off)
LED: 02 (<- third press, both on)

etc

Similarly key click *seems* to be enabled at first press of the magic key when it works at all (although at this point I'm inclined to say it's blind luck...), otherwise it's doing nothing or going into continuous beep mode. The strange thing being that the logical reports ('Click on' etc) are always correct, so you'd expect the right code to be run.

I'm getting seriously stumped.

I think signal logic of the code are inverted somewhere. I didn't find a bug in send_serial() but I believe something is wrong there.

I'd like to see your board and code. EDIT: TMK code your are using and Arduino project you wrote if possible
Could you post pics of your board? And if you setup your repository in github it would be great.

Side note : I'll confirm your earlier estimation that something is wrong with sending commands to the keyboard, since I got resets while activating num or caps lock from the other keyboard as well.

hasu wrote: ↑

sparky wrote: ↑Quick update : with the SERIAL_SOFT_LOGIC_NEGATIVE flag enabled and the 7404 bypassed, the board doesn't respond at all.

Code: Select all

Waiting for device:.....
Listening:
.........................................................................................................

No reaction to keypresses, magic keys etc.

Something is wrong. I think it must display messages.
Removing 7404 is easier way unless you are willing to debug my software serial cocde.

The above is without the 7404.

(snip)

I'd like to see your board and code. EDIT: TMK code your are using and Arduino project you wrote if possible
Could you post pics of your board? And if you setup your repository in github it would be great.

At this point the TMK code is your latest (git cloned this morning after you mentioned the update), with the only changes being disabling the negative logic flag in config.h and adding the keycodes for the numpad keys in command_extra.c.

By pics of the board do you mean the prototype board ? (It's a bit messy but it otherwise works).

No problem publishing my arduino project (that was the goal all along), I'll look into setting up a repository (I'm not that familiar with git, either).

I just came back from a longish errand and strangely enough the keyboard seems to have stabilized on its own. No more spurious resets, normal and immediate reaction to num/caps locks and keyclick magic. « Weirderer and weirderer », as the saying goes.

The code to my arduino project : https://gitlab.com/sparky2002/sunusb

Includes an svg of the schema the board (will) follow.
At this time the condensers, resistors and DIP-switch are not present.

sparky wrote: ↑Side note : I'll confirm your earlier estimation that something is wrong with sending commands to the keyboard, since I got resets while activating num or caps lock from the other keyboard as well.

hasu wrote: ↑

sparky wrote: ↑Quick update : with the SERIAL_SOFT_LOGIC_NEGATIVE flag enabled and the 7404 bypassed, the board doesn't respond at all.

Code: Select all

Waiting for device:.....
Listening:
.........................................................................................................

No reaction to keypresses, magic keys etc.

Something is wrong. I think it must display messages.
Removing 7404 is easier way unless you are willing to debug my software serial cocde.

The above is without the 7404.

Yep, I know. My converter works fine without inverter so I believe your converter should work withouth 7404.
I'm curious why it didn't work.

I'd like to see your board and code. EDIT: TMK code your are using and Arduino project you wrote if possible
Could you post pics of your board? And if you setup your repository in github it would be great.

At this point the TMK code is your latest (git cloned this morning after you mentioned the update), with the only changes being disabling the negative logic flag in config.h and adding the keycodes for the numpad keys in command_extra.c.

Did you notice my coverter uses ATMega32u2, not ATMega32u4. I think you have to change MCU value in Makefile.

By pics of the board do you mean the prototype board ? (It's a bit messy but it otherwise works).

No problem publishing my arduino project (that was the goal all along), I'll look into setting up a repository (I'm not that familiar with git, either).

I just came back from a longish errand and strangely enough the keyboard seems to have stabilized on its own. No more spurious resets, normal and immediate reaction to num/caps locks and keyclick magic. « Weirderer and weirderer », as the saying goes.

Yep, pics are usually very useful to understand how hardware goes.

You mean It works fine now? Confused.

Hello,

[Did you notice my coverter uses ATMega32u2, not ATMega32u4. I think you have to change MCU value in Makefile.

Yes I did, you're right. I forgot that. The arduino won't get flashed with the wrong value. I also added the proper PROGRAM_CMD entry to the makefile.

Yep, pics are usually very useful to understand how hardware goes.

Photo attached. As I said, messy, but it's been enough to get it working so far.

Quick overview : from the "south" end, the Arduino's GND and +5V feed their respective rail on the protoboard.
Arduino's TX goes to 7404's pin 9 (port 4A), through the inverter, out pin 8 (port 4Y), on to pin 5 of the mini-din.
Arduino's RX to 7404's pin 2 (1Y), through pin 1 (1A), to pin 6 of the mini-din.
7404's pins 7 and 14 to 5V and GND respectively.
Mini-din pins 1 and 3 to GND and 5V respectively.

Bypassing the 7404 was done by putting the jumper wires off 1A/1Y and 4A/4Y on the same rail respectively, off the chip.

I just came back from a longish errand and strangely enough the keyboard seems to have stabilized on its own. No more spurious resets, normal and immediate reaction to num/caps locks and keyclick magic. « Weirderer and weirderer », as the saying goes.

You mean It works fine now? Confused.

Indeed, after that last message I used it on and off along with the M, and with hid_listen visible in the background, I got maybe two or three resets in the whole afternoon ; most notably, no resets after toggling LEDs. This one confuses me as much as it does you. (I just tried that again. Went to do something else for half an hour, and now the keyboard behaves)

Still fighting with the keyboard initialization (however when you wait long enough things seem to settle down).

I changed the 'Reseting' loop to make it more verbose : ... and I get variable results, sometimes it just won't complete its reset (mostly at first USB connection or sometimes after reflashing) Sometimes it will just work right away : Along another line, I'm trying to use pin readings to set keyclick automatically at startup depending on whether the pin is jumpered (final board, almost ready, has a DIP switch bank instead).

I need to set Port B's pins (I'll be using arduino pins 9-12) as input and force them high to enable the internal pull-up. As I understand from the arduino docs and the IIgs keyboard code, I'm trying this (among other attempts) : I can't read any consistent report and I don't understand why. Probably something silly that I'm overlooking but I just don't see it.

Thanks.

So, after reading more of the existing code (the thread here about the 60% SGI granite mod and the original gh60 tmk code helped a lot) and re-reading the pdf with the pins assignment (arduino <-> AVR) I believe I got the pin reading right. I still don't understand how it works but it does.
I write this down for further reference and for the next guy who'll go googling around

Instead of declaring / trying to access the whole byte-wide pin reports I added an indirect declaration with my own, adapter-meaningful names pointing to the relevant DDR/PORT/PIN/BIT declaration (however those work):

in config.h: ... and so on for the other switches. The switches are on arduino pins 12 to 9, which map to port D bit 6, and port B bits 7, 6, 5 respectively.

in matrix.c under matrix_init(), setting the pins up as input with internal pull-up is done with: The first line sets the proper bit in the DDR to 0 for input (note the logical NOT), the second one forces the bit high to enable the pull-up.

Finally reading is done with: with the result being non-zero if the switch is open/the pin not grounded.

As for the keyboard initialization issues, I pulled a Type 5 out of storage and after more than a dozen inits (between reflashing and unplug/plug for tests) it always comes up after, at worst, 3 or 4 reset loops, never getting lost, and always responding to commands and LEDs properly. This points to some hardware issue with the Type 3 ; whether it's the Type 3 in general or my board in particular will be determined later, as a friend of mine just got a Type 3 himself and will use the same adapter. More to come when that's done, and that will likely be the final report on this conversion.