Page 8 of 12

Posted: 27 Jun 2016, 20:35
by Wodan
Maybe the native USB support in the atmega32u4 allows solid USB communication at lower speeds but I think when building AIKON controller based on atmega32 uC with a firmware USB stack, a speed of 12MHz is required.
Maybe that's a restraint of the bootloaderHID used ... meh

Would be too awesome if we could Soarer or TMK on the 8MHz version

Posted: 28 Jun 2016, 20:22
by Arakula
If you're willing to experiment a little -

attached, find a version of Soarer's Converter that should work on an 8MHz Pro Micro.
If I found all places where the CPU frequency is relevant.
If that really works at all (I got no 8MHz device to experiment with).

(Attachment deleted, as it didn't work)

Posted: 29 Jun 2016, 08:39
by Wodan
Thanks for the contribution. Just flashed it onto a 8MHz ProMicro but unfortunately, no success.
The ProMicro fails to identify as a proper USB device after flashing. This also happens when flashing the 16MHz version. Might be a little more to it than that. Is Soarers source code available somewhere?

Posted: 30 Jun 2016, 21:09
by Arakula
Hmmm. Too bad. Well, back to staring at the code...

Plus, I've ordered an 8MHz 3.3V Pro Micro from China for experimentation. Unfortunately, it will take up to a month to arrive chez moi - the little drawback when you order with "Free intl shipping" from Shenzhen ...

Oh, and regarding the source code - see this topic.

Posted: 30 Jun 2016, 21:32
by Wodan
Oh wow such a shame, if you plan to work on a binary compatible own version of his controller, I'd love to help!
Not a C master but program for life.

I'll gladly send you one of my 3.3v promicro!

Just got 10 5v promicro from a Chinese vendor. Took less than a week! No shipping, 5€ each

Posted: 30 Jun 2016, 22:07
by Arakula
Wodan wrote: Oh wow such a shame, if you plan to work on a binary compatible own version of his controller, I'd love to help!
Not a C master but program for life.
Are you familiar with the AVR8 assembly language?
Wodan wrote: I'll gladly send you one of my 3.3v promicro!

Just got 10 5v promicro from a Chinese vendor. Took less than a week! No shipping, 5€ each
Cool! My one comes at ~4.5€ ... when it comes 8-)

I found another difference between 8 and 16 MHz external clock settings; this one's in the USB configuration, so it might well be the reason for the non-registering USB device. If you're feeling adventurous, have a go at it...
soarer_pro_micro8.zip
(14.78 KiB) Downloaded 210 times
... if this version still doesn't register properly, I'd like to take your offer; please contact me per PM for details.

Posted: 01 Jul 2016, 07:02
by Wodan
Absolutely no Assembler on my side. Always hoped I could avoid that ...

Will try that version later and give feedback.

Posted: 01 Jul 2016, 07:59
by Arakula
Since I just went through the previous page of this thread -
Wodan wrote: I think you need at least 12MHz for USB communication. So the 8MHz version can be flashed through USB when in bootloader mode but not establish proper firmware USB communication. Please correct me if I'm wrong here! After all I guess the firmware must be recompiled for the 8MHz version to get the timing for the USB communication right again if poissible at all.
Based on the documentation, it uses a 48MHz internally generated frequency and can lock that to an external crystal. For the atMega32U4 there are two configurable settings, for 8MHz and for 16MHz crystals (and that's what was still incorrectly configured to 16MHz in my previous version). So 8MHz should be good enough for the USB side. As for the PS/2 side ... we'll see.

Posted: 01 Jul 2016, 11:11
by Wodan
You're a god damn genius!!!

Just flashed my 8MHz ProMicro and it now identifies correctly as a Soarer Converter.
Haven't hooked it up to a keyboard yet but this looks promising.
Amazing job there, incredible potential here if Soarers work could really become a community project.

Posted: 02 Jul 2016, 08:15
by Arakula
Wodan wrote: Absolutely no Assembler on my side. Always hoped I could avoid that ...
In my opinion, you're deliberately depriving yourself of insight and knowledge if you avoid it. It may be more difficult to read and write at first, but gives you absolute control over the machine you're using; that's something even the most sophisticated higher-level language can't give you. Plus, it makes it possible to reverse-engineer code.
Wodan wrote: Just flashed my 8MHz ProMicro and it now identifies correctly as a Soarer Converter.
Haven't hooked it up to a keyboard yet but this looks promising.
Amazing job there, incredible potential here if Soarers work could really become a community project.
Well, the next step would be to look whether it works with a PS/2 or PC/XT keyboard. This might need a conversion to 5V, especially for older keyboards.

Posted: 06 Jul 2016, 01:29
by monkeyplusplus
Hi all, I've been trying to get a .hex flashed onto my pro micro using avrdude on OSX, using the directions at the beginning of this thread. I've done some reading through the entire thread, but I don't think I've seen any actual success stories coming from people on that platform. If you've *actually successfully flashed* a .hex on OSX, I'd love to hear about it, as I'm having zero luck so far :'/

Posted: 06 Jul 2016, 01:54
by scottc
I have. It works fine on Mac OS X. We can't help you unless you tell us what's wrong and give us steps to reproduce.

Common issues you might have:

- avrdude isn't installed
- you didn't prepend "sudo" to avrdude command (might be required if your user doesn't have access to write to the device; there are instructions to do this on Linux on the Teensy website that are quite straight-forward)

Posted: 06 Jul 2016, 02:05
by monkeyplusplus
Ah, thanks for your reply! Here's an output of what I'm getting when I try to flash after resetting the device twice quickly in succession - hopefully this helps:

(I've also attempted to prepend this command with sudo, with the same result)

Code: Select all

james (master) twobyfour $ ls -l /dev/cu.*
crw-rw-rw-  1 root  wheel   17,   1 Jun 30 19:07 /dev/cu.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel   17,  93 Jun 30 21:53 /dev/cu.usbmodem46
crw-rw-rw-  1 root  wheel   17,  17 Jun 30 21:01 /dev/cu.usbmodemFD131
james (master) twobyfour $ avrdude -p atmega32u4 -P /dev/tty.usbmodem46  -c avr109  -U flash:w:twobyfour.hex -v

avrdude: Version 6.0.1, compiled on Dec 16 2013 at 17:26:24
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/usr/local/CrossPack-AVR-20131216/etc/avrdude.conf"
         User configuration file is "/Users/james/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/tty.usbmodem46
         Using Programmer              : avr109
         AVR Part                      : ATmega32U4
         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  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : butterfly
         Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

Posted: 06 Jul 2016, 02:20
by scottc
From a quick look:

- The error is a pretty generic one saying it couldn't talk to the board.
- This isn't surprising, if you want to flash /dev/cu.usbmodem46 then your avrdude command should say /dev/cu.usbmodem64 not /dev/tty.usbmodem46
- cu.usbmodem46 is almost definitely not the Pro Micro, so your board probably isn't in bootloader mode. It's tricky. See the first post for more info about shorting pins.
- Definitely do put sudo in front of avrdude, or else you won't have permission to flash the device at all (once you DO get the right device name under /dev, you'd probably get an error about "Permission denied")

I'm about to go to sleep but if those tips don't sort you out, maybe someone else will be around to help in the morning.

Posted: 06 Jul 2016, 02:22
by monkeyplusplus
Cool, I'll give it some more effort. Thanks much :)

Posted: 06 Jul 2016, 21:59
by monkeyplusplus
Using scottc's comments above and also putting

Code: Select all

watch -n.5 ls -l /dev/cu.*
in another terminal window, I was able to squeeze in a sudo'd avrdude command to flash the pro micro. Now I'm working on being able to re-flash, which is its own ball of wax, but progress is at least being made! Thanks for your help!

Posted: 06 Jul 2016, 22:39
by scottc
Nice! Getting the board into bootloader mode is a bit of a pain. HzFaq had the ingenious idea of hooking the two pins on to a Matias switch to make it more accessible. Highly recommended!

Posted: 07 Jul 2016, 01:07
by monkeyplusplus
Yeah, I did solder in a tiny pushbutton switch. Way easier.

Posted: 31 Jul 2016, 14:56
by spindle
scottc wrote: Nice! Getting the board into bootloader mode is a bit of a pain. HzFaq had the ingenious idea of hooking the two pins on to a Matias switch to make it more accessible. Highly recommended!
You can get the promicro into bootloader mode through software using this function:

Code: Select all

void promicro_bootloader_jmp(bool program) {
    uint16_t *const bootKeyPtr = (uint16_t *)0x0800;

    // Value used by Caterina bootloader use to determine whether to run the
    // sketch or the bootloader programmer.
    uint16_t bootKey = program ? 0x7777 : 0;

    *bootKeyPtr = bootKey;

    // setup watchdog timeout
    wdt_enable(WDTO_60MS);

    while(1) {} // wait for watchdog timer to trigger
}
You can then map it to a key in your firmware. See here to see it in action

Posted: 16 Aug 2016, 20:05
by Arakula
Wodan wrote: I'll gladly send you one of my 3.3v promicro!
I think I might have to ask you for one.
You see, the chinese boat finally arrived and I got THAT:
001.jpg
001.jpg (341.73 KiB) Viewed 7695 times
... 3.3V it seems to be, but with a 16MHz quartz, although the article listing specifically said 8MHz.
Very funny, my Chinese friends.

So ... could you send me one? I could offer this 16MHz one as a replacement.
No hurry - I'll be on holiday from next week until Sep 10 anyway.

Posted: 16 Aug 2016, 20:08
by Wodan
Arakula wrote:
Wodan wrote: I'll gladly send you one of my 3.3v promicro!
I think I might have to ask you for one.
You see, the chinese boat finally arrived and I got THAT:
001.jpg
... 3.3V it seems to be, but with a 16MHz quartz, although the article listing specifically said 8MHz.
Very funny, my Chinese friends.

So ... could you send me one? I could offer this 16MHz one as a replacement.
No hurry - I'll be on holiday from next week until Sep 10 anyway.
Pm me with your address. No need to send anything back. Glad I can support your project. Very promising.

Posted: 23 Sep 2016, 20:13
by Arakula
Just a quick notice here, as my numerous PMs with Wodan are, well, private 8-) :

I received the 8MHz pro micro - thank you very much, Wodan! - and could experiment with it.

For my purposes, the Arduino boot loader is totally unusable, so I created a version of Grendel's BootHID for the 8MHz pro micro. See my "adventures into pro micro land" for further details. I've attached it here, in case somebody wants it:
BootHID.zip
(2.71 KiB) Downloaded 195 times
This .zip file contains both the 16MHz and 8MHz versions.
Works nicely.

What doesn't work nicely, unfortunately, is Soarer's Converter. Obviously, 8MHz is not enough. In principle, it works, but every now and then a glitch on the clock line occurs, leading to lost keys and the like. The problem isn't in the PC/AT code; rather, it's somewhere on the USB side. Soarer's Converter sends a lot of debug messages which you can view on the PC with hid_listen; if I disable that, everything works nicely. Obviously, the USB transfer of the debug messages takes up too much time with disabled interrupts, so a PC/AT clock transition isn't processed in time.

I've spent some days on this problem, but couldn't find an obvious cause. Maybe there's an underoptimized code part in USB processing that isn't working fast enough (but does so on a 16MHz device), or maybe 8MHz simply isn't good enough.

Well, I'd rather call it a partial success than an utter failure ... here's a version of Soarer's Converter for the 8MHz pro micro that works (at least with all PS/2 keyboards that I could throw at it - haven't got any PC or AT keyboard for testing), but doesn't provide USB diagnostics for the hid_listen program:
Soarer_at2usb_v1.12_promicro8.zip
(14.52 KiB) Downloaded 195 times
... maybe somebody finds it useful.

Note: this entire posting was created with Soarer's Converter on the 8MHz pro micro :-)

Posted: 26 Sep 2016, 08:36
by Wodan
I would call that a great success :) Someone actually being able to reverse engineer the Soarer coding is such a relief to me. Great work on those controllers. The lesson is simple: Make sure you buy the 16Mhz version. Putting additional effort into making the 8Mhz version work yields very little reward - it's not like they're much cheaper than their 16Mhz counterparts.

Will you be starting a community based development project on the basis of Soarers work? Would love to see a thread about that - maybe dive a little deeper into the C world.

Posted: 26 Sep 2016, 10:37
by alh84001
Very nice! It's always nice when you see that some previously unusable devices become usable. Thanks arakula.

Posted: 26 Sep 2016, 11:49
by Arakula
Wodan wrote: Will you be starting a community based development project on the basis of Soarers work? Would love to see a thread about that - maybe dive a little deeper into the C world.
I'm planning to; only the legal part is keeping me back from filling https://github.com/Arakula/SoarerConverter and https://github.com/Arakula/SoarerController with my current code base.

You see, there are some problematic areas:
  1. My code is essentially Soarer's code, reverse-engineered and slightly refined. I can't easily stick a GPL license onto that without permission from Soarer - who has gone missing two years ago. I might create a special "GPL-except-when-Soarer-says-no" license, but have no idea whether that would hold up in the (unlikely, but still possible) case of Soarer's return.
  2. In my country, reverse engineering for private purposes is allowed. This is not universal, however; I'm not sure whether making the code public couldn't attract "the wrong kind of fly", trying to make my life and my wallet miserable. I'm already a step on the unsafe side by posting various versions here...
  3. Soarer did disclose parts of his code - the source code to the computer-side tools is fully available. Unfortunately, he set no license for these, which, unfortunately, does not automatically mean a release into the public domain.
  4. The code contains parts that are obviously taken from PJRC sample code (i.e., partly identical to PRJC's "USB Keyboard with Debug Channel" project, partly obviously expanded upon, so there's absolutely no question where it came from). Paul Stoffregen put that pretty much under a "Do what the f*** you want with it" license, so I'd have to explicitly exclude these code parts from GPL. Is that even possible?
Bah. I hate talking legalese, but I'd hate it even more to get into trouble over this.

Any good idea on how to proceed?

Posted: 26 Sep 2016, 12:07
by Wodan
Make it a closed group of developers and only release binaries?

Posted: 13 Oct 2016, 12:55
by hypkx
I finally made it, after hours of trying I got one working (debian).
Btw is it possible that I have destroyed a pro micro board, after soldering it didn't recognized at the PC anymore and the led are dead?

Posted: 13 Oct 2016, 13:40
by hypkx
Thanks scottc for your great tutorial, now work booth. My model M122 also.
btw also an nice tutorial + pinout for a terminal model m (color of the cables): http://hasbeardplaysgames.co.uk/2014/10 ... -keyboard/

Posted: 17 Nov 2016, 21:35
by Norman_
Am i stupid or why isn't this working? :(

It hangs here completely, no change even after relatively significant time (20 ish minutes)
ssss.PNG
ssss.PNG (13.6 KiB) Viewed 7430 times
Edit: fixed the error by soldering in a switch to help reset and resetting, now i get this...ugh, something has gone wrong at every step...

sssss.PNG
sssss.PNG (26.5 KiB) Viewed 7414 times

Posted: 17 Nov 2016, 23:37
by Rimrul
You did verify COM5 is the correct port? IIRC it changes when switching to bootloader and I just tried them until I hit the right one, resetting again every few tested COM ports.