Author Topic: Beamspring USB  (Read 21321 times)

0 Members and 1 Guest are viewing this topic.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #50 on: Mon, 02 December 2013, 04:19:46 »
They're a bit too 8051-ish for me... they're not nice to program (I don't think there was a gcc port at the time I used them) and due to the CISC design the performance suffers—they're not 1-instruction-per-cycle like the AVRs.

What do you mean ISAs? Do you mean ISRs? Don't know why having lots of interrupts available would be an issue. Unless you mean instruction set architecture, but that's a moot point with a C compiler.

2.5us for ADC is certainly good but still not really touching the speed of a dedicated comparator.

Personally if I was to move away from the AVR8s I'd be moving towards the STM32s. Nice RISC ARM core, excellent performance per cycle and watt, heaps of IO (100 pins in QFP),  typically 12-bit ADCs, not too much more expensive than the AVR8s.

The reason people use AVR8s is not because of Teensy or Arduino libraries (it's pretty hard to vet that sort of code for industrial embedded development!) but because the performance is stellar, there is an excellent standards-compliant C compiler available, the pricing is very good and the feature set is usually pretty decent. Don't underestimate the effect of good toolchain and compiler support. Writing in half-arsed non-compliant C, writing your own linker scripts or having to code in assembler is not my idea of a good time.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #51 on: Mon, 02 December 2013, 12:25:47 »
i hesitate to call gcc excellent these days, but it's definitely a head above codewarrior, which they still use over at freescale for all the old motorola and power stuff. that said, they've been working on codewarrior nearly as long as the gcc team has been working on cc, and they only have one target, really (i think they've extended it to arm, but very recently). anyway, it's fully featured now. rs08's dev env is pretty plug and play. it might even be easier than getting gcc set up for an avr target these days.

CISC is actually generally an optimized choice for small bit-widths. the downside of risc is that everything has to be explicit everywhere, but the hardware is much simpler, and at the bleeding edge of litho nodes, you can scale to much higher clocks. that's not really an issue with either of these chips. in fact, we don't even really care about mips/watt, as absolutely everything is going to fit into our power envelope.

as for ISA, an actual single processor core that's shared across all the chips means there's a chance of being able to simulate for debugging. the avr simulators are complete garbage.. actually, one of the strengths of freescale's codewarrior-based toolchain is that they've done a really good job integrating their proprietary remote debugger arch into the IDE. you can do full simulation-style debug on a running device over USB. none of this jtag uggness.

i haven't looked at the stm chips at all.. iirc they sell mostly into eg sensor nets.. hmm, i wonder if they have a small cheap soc with a lot of acmps on it.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #52 on: Mon, 02 December 2013, 13:41:39 »
Gcc is still the best we have; none of the commercial offerings really amount to anything remotely standards-compliant and are often wedged into horrible IDEs. Clang/LLVM seems very promising but don't know how far they've got along in the embedded arena.

My CISC-vs-RISC point is mostly due to instruction set orthogonality—meaning for the chaps developing gcc, or if you have to drop into assembler yourself, you're not faced with a whole world of pain (c.f. PIC and the abysmal state of compilers for many years—not sure how it is now). You're perfectly right however that in the context of a USB keyboard it doesn't matter a whit :D

I must admit I've never tried any of the simulators, content to stick with JTAG or SWD (with the ARMs). What you say makes sense however; it'll be interesting to see if the clang/llvm approach bears any fruit (the whole point of it was to make static analysis and simulation very easy, the compiler itself was almost secondary).

The STM32s are just Cortex M3s, so not really full-blown ARM SoCs, but still very capable. Freescale have their own equivalents of course. I'm attracted to the STM32s in other fields due to the strong peripheral support (2xCAN, USB, Ethernet on one chip). They do have some interesting mixed-signal devices with some DSP stuff that could be attractive.

What's the advantage of trying to jam everything into one chip, other than board space? I say this as having only tackled the beamspring problem so far; the connector being so widely spaced it's almost easier to lay out the board with discrete shift registers driving the columns and comparator reading the rows than it would be to break everything out back to the µC. I haven't looked closely at the Model Fs, are they very limited in space?
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline mkawa

  •  No Marketplace Access
  • Posts: 6562
  • (ツ)@@@. crankypants
Re: Beamspring USB
« Reply #53 on: Mon, 02 December 2013, 20:38:38 »
no the model Fs were huge, and VLSI at the time was like two transistors in one dip package.

LLVM actually exists to make clang target agnostic, and it has actually completely replaced gcc already at google, apple, and some other large companies i can't think of right now. the llvm designers don't understand static analysis, and that's not a bad thing -- i did a phd in it, it's hopeless. MOVING ON yah the point is to aggregate things to make the tiny keyboards that are becoming most popular possible with capacitive buckling spring. but this is a long-term goal. in the meantime, your controller is very much laudable and something that wcass can use TODAY to make some actual keyboards, which is awesome.

we can iterate when the time comes.

to all the brilliant friends who have left us, and all the students who climb on their shoulders.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #54 on: Tue, 15 April 2014, 20:47:44 »
OK so the Rev4 board is up and running (has been in my 3727 for the past week):
61092-0
61094-1

It has 74AHC595 shift registers in the wee DHVQFN16 package; the AHC CMOS tech gives a better drive and I'm seeing a higher kick on each sense row.

Components are all now top-side for easier soldering (whether toaster oven or skillet—I'd still be happy to hand-solder one as well, the centre pad underneath the 74AHC595s is not connected).

It has a 6-pin connector on it for `expansion'.

The intention is to use said connector with this solenoid driver board I'm waiting to get back from the fab:

Top:


Bottom:


Even more click!
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #55 on: Tue, 15 April 2014, 20:52:29 »
Also, along with my Model F USB controller, I'm about to order a new board, that is a Beamspring Displaywriter controller.

Top:


Bottom:


Slightly awkward layout with the DAC and drain reference in the middle, fanning out to the two sets of row sense circuitry on the far left and right of the board. Not ideal, but IBM must have got away with it (they didn't even have a ground plane!). If there is too much DC bias left to right, I'll have to change the code to scan one set of rows, then set a new Vref through the DAC, before scanning the other set of rows. Hopefully doesn't come to that as obviously would halve the scan rate.
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
Re: Beamspring USB
« Reply #56 on: Wed, 16 April 2014, 21:41:47 »
Also, along with my Model F USB controller, I'm about to order a new board, that is a Beamspring Displaywriter controller.

Top:
Show Image


Bottom:
Show Image


Slightly awkward layout with the DAC and drain reference in the middle, fanning out to the two sets of row sense circuitry on the far left and right of the board. Not ideal, but IBM must have got away with it (they didn't even have a ground plane!). If there is too much DC bias left to right, I'll have to change the code to scan one set of rows, then set a new Vref through the DAC, before scanning the other set of rows. Hopefully doesn't come to that as obviously would halve the scan rate.

YES! I'll finally be able to use it!

Though I heard Soarer just replaced the controller with a teensy to get his working, the entire controller replacement always struck me as a good solution.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #57 on: Wed, 16 April 2014, 22:45:45 »
Though I heard Soarer just replaced the controller with a teensy to get his working, the entire controller replacement always struck me as a good solution.

What the! Do you mean like desoldering the microcontroller on the original controller PCB and wiring in a Teensy instead?!

Pretty cool but also pretty extreme :P
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #58 on: Tue, 06 May 2014, 23:47:53 »
Here's version 0.6 of source and schematics.

New stuff is mostly concerned with supporting the Model Fs and Beamspring Displaywriters in the same codebase, and of course the schematics and PCB layouts for those new controllers.

Concerning the standard beamspring specifically:
- Rev4 controller (schematics/PCB/firmware support)
- Revamped GUI layout to be less horrendous
- Support for solenoid driver (you will need the solenoid driver board, and a Rev4 controller, with the expansion port, unless you want to do some crazy ninja soldering directly to the ATmega32U2)
- Support for LEDs through that same expansion port
- Allows column skipping if (like with the 5251) you don't have any keys on that column—would speed up scanrate marginally
- Slightly slower overall scanrate for more noise robustness (solenoid can make scary stuff happen)
- Tweaked autocalibration, result will probably end up a bit higher

63896-0
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #59 on: Thu, 08 May 2014, 21:46:27 »
And here is v0.6.1.

This fixes a reasonably major issue on Windows 7 64bit (I think?) which had major issues with the two keyboard descriptors (the fake padding of the boot-mode 6-key only interface was freaking it out and causing the NKRO descriptor to get sent STALLs).

There was also a major bug in the GUI util which prevented 8-row keyboards (Model Fs and Beamspring Displaywriters) from displaying their top four rows of scancodes on layers 1–3.

There was also a minor padding bug in the descriptor for the NKRO interface with the addition of the LEDs; neither Linux or Mac OS X cared, but it really annoyed Windows.

I've also got binaries compiled on Windows and Mac OS X, along with pre-compiled hex files for all the variants so far.

As always, use the old version of the util to put the keyboard into the bootloader first, then flash the keyboard. Afterwards, use the new version of the util to talk to it. Make sure you pick the right hex file to match your board type and revision!

You can download them all here: http://linode.cornall.co/ibm-capsense-usb/0.6.1/
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #60 on: Fri, 09 May 2014, 00:03:00 »
First Beamspring Displaywriter board.

Hopefully ship off for testing on Monday :)
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless

Offline CPTBadAss

  • Woke up like this
  • Posts: 14364
    • Tactile Zine
Re: Beamspring USB
« Reply #61 on: Fri, 09 May 2014, 07:27:36 »
Wow that PCB looks sharp. Let us know how the testing goes :D

This project has motivated me to find a beamspring board. I've was smitten with dorkvader's beamspring board and want one of my own.

Offline xwhatsit

  • Thread Starter
  • Posts: 297
  • Location: NZ
Re: Beamspring USB
« Reply #62 on: Fri, 09 May 2014, 22:25:06 »
Wow that PCB looks sharp.

Heh yeah laying it out was painful but I like the symmetry of having four sense rows at each end :) Just ignore the mini-USB connector not quite matching up with the footprint—turns out Molex makes some slightly weird mini-USB sockets that don't match the standard footprint! D'oh!
Beam spring IBM 5251 (7361073/7362149) & IBM 3727 (5641316) | Model F IBM 122-key terminal & IBM PC-AT 84-key | Model M Unicomp 122-key terminal | Cherry MX Blue Leopold Tenkeyless