I'm wondering if the USB protocol tax now allows you to run Scheme. I mean if you didn't need USB you could use something like the PIC16F54 (512 ROM, 25 bytes of RAM) for $0.39 each... but you will almost certainly write the code in assembly language. I tried to find the cheapest microcontroller with USB support: I found C8051T622-GM ($0.982), with its luxurious 16KB of ROM and 1.25K of RAM. Curious if Microscheme will run on this- nope, it only supports Atmega..
Atmega32u4 is like $3.43.. too much when you consider that you can buy a keyboard for $4.00.
We use(d?) it at U of Montreal to drive small PIC18 robots. Except for the one time I had to debug its GC, it was a fine platform, even for HS students.
I doubt PICBIT (or Microscheme for that matter) could run on the PIC16 family, with it's 25 bytes of RAM. Wouldn't be much of stretch to port Microscheme to PIC18s though (with 512+ bytes of RAM), the code generator is pretty straight-forward: https://github.com/ryansuchocki/microscheme/blob/master/src/...
I have a prototype model of my keyboard that runs a firmware written in Forth. It is built around an ARM Cortex M4 dev board I got for $19. The ATMega doesn't have enough ram for Forth or a real (non-subset) Scheme.
You can get bare ARM chips for practically nothing, but for this project I ruled out SMT since it's intended for a DIY kit and most people don't feel comfortable soldering SMT. An ATMega dev daughterboard costs a bit more ($9 vs $3) but fits the requirements of this project much better.
>I ruled out SMT since it's intended for a DIY kit and most people don't feel comfortable soldering SMT
this is superstition and education issue, not technological one, SMD is EASIER, faster to solder, and cheaper.
People are scared because they have soldering iron and know only soldering iron. Show them hot plate or hot air gun. I dont buy "but they already bought soldering gun, they would have to buy next tool" arguments. Its like peddling wooden car frames, because people have glue already. Soldering with hotair is easier to learn, faster to master, and more versatile.
You have to pick your battles. That may be true, but unfortunately there's not much I can do about it; I've talked to a lot of people who were hesitant to buy an Ergodox when they saw the assembly instructions mentioned a magnifying glass and tweezers.
In any case you can't get around the need for a soldering iron anyway in a kit that includes key switches.
> Atmega32u4 is like $3.43.. too much when you consider that you can buy a keyboard for $4.00.
You can buy a McDonalds hamburger for $4.00 too, but if it's something you're going to eat every day let's hope you can do better than that.
I've got a prototype keyboard that is built around a $19 ARM dev board that runs a firmware written in Forth. I tried running that on the ATMega, but 2.5kb of RAM is just not enough.
You can get bare ARM chips for nearly as cheap as AVR, but most people aren't going to be interested in a kit if it requires SMT soldering, so the daughterboard approach actually makes a lot of sense here. Surprisingly it only raises the cost from $4 to $9.
This is nice - after recently building an ergodox I've been curious to understand better the 'matrix scan' and how it's achieved, this should help significantly.
Aside - Kind of an impressive project to replace firmware on various keyboards, including the ability "run small compiled programs written in a C-like language" (compiled with haskell) with a "Built-in virtual machine interpreter for running up to six concurrent independent tasks" https://github.com/chrisandreae/keyboard-firmware
Cool to see languages besides C running on small hardware.
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
Cool to see languages besides C running on small hardware.
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
Cool to see languages besides C running on small hardware.
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
Cool to see languages besides C running on small hardware.
I would guess that memory consumption, not speed, is the limiting factor vs. C in many applications. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells take a lot of extra space. At least it has vectors.
Cool to see languages besides C running on small hardware.
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
That's true; on the ATMega32u4 it's the 2.5kb of RAM that kills you. The 16MHz clock speed is plenty fast for most microcontroller applications. That's why Microscheme is just a subset of Scheme; there are no continuations or runtime eval in order to save memory.
It's true that there are no structs, but it wouldn't be much of a stretch to add them. There's a discussion of writing a macroexpander in another Scheme runtime like Guile which can compile macros to microscheme output. (This is a bit like how ClojureScript lacks runtime eval but allows you to write compile-time macros in Clojure.) Writing a define-struct macro that compiles to vector-ref at runtime would be pretty trivial once you have a macroexpander working.
I have an ergodox, and I love the look of this Atreus keyboard. I would love to see better firmware support for more advanced keyboard features like dual role keys and one shot modifiers, for ergodox and its descendants.
Right now the tmk firmware has the best support for these features, but I'm having to do a lot of monkeying around with it to get dual role keys to work in the home row without interfering with my normal typing.
For example, holding the 'f' or 'j' key acts as CTRL, but tapping works normally.
The TMK firmware works on the Atreus keyboards too; I used it for a while before writing my own firmware. I plan on putting up some better docs soon on how to use it with the Atreus if you want some of these more advanced features.
From a learning perspective it's also nice to have a dramatically simpler firmware too. The initial version of the C atreus-firmware codebase was just over 100 lines.
Yeah, there is value in simplicity. I am trying to understand tmk to modify it and it is a challenge.
At some point I want to make something like the Atreus but with a bit more buttons. Basically the ergodox without the thumbs pads and most of the bottom row and without a split.
On the subject of keymaps, it seems like a finite state machine with transitions on down and release. I haven't seen any firmware try that yet. Perhaps its the debouncing logic which makes that too complicated.
21 comments
[ 4.0 ms ] story [ 62.8 ms ] threadAtmega32u4 is like $3.43.. too much when you consider that you can buy a keyboard for $4.00.
We use(d?) it at U of Montreal to drive small PIC18 robots. Except for the one time I had to debug its GC, it was a fine platform, even for HS students.
I have a prototype model of my keyboard that runs a firmware written in Forth. It is built around an ARM Cortex M4 dev board I got for $19. The ATMega doesn't have enough ram for Forth or a real (non-subset) Scheme.
You can get bare ARM chips for practically nothing, but for this project I ruled out SMT since it's intended for a DIY kit and most people don't feel comfortable soldering SMT. An ATMega dev daughterboard costs a bit more ($9 vs $3) but fits the requirements of this project much better.
this is superstition and education issue, not technological one, SMD is EASIER, faster to solder, and cheaper.
People are scared because they have soldering iron and know only soldering iron. Show them hot plate or hot air gun. I dont buy "but they already bought soldering gun, they would have to buy next tool" arguments. Its like peddling wooden car frames, because people have glue already. Soldering with hotair is easier to learn, faster to master, and more versatile.
In any case you can't get around the need for a soldering iron anyway in a kit that includes key switches.
You can buy a McDonalds hamburger for $4.00 too, but if it's something you're going to eat every day let's hope you can do better than that.
I've got a prototype keyboard that is built around a $19 ARM dev board that runs a firmware written in Forth. I tried running that on the ATMega, but 2.5kb of RAM is just not enough.
You can get bare ARM chips for nearly as cheap as AVR, but most people aren't going to be interested in a kit if it requires SMT soldering, so the daughterboard approach actually makes a lot of sense here. Surprisingly it only raises the cost from $4 to $9.
Aside - Kind of an impressive project to replace firmware on various keyboards, including the ability "run small compiled programs written in a C-like language" (compiled with haskell) with a "Built-in virtual machine interpreter for running up to six concurrent independent tasks" https://github.com/chrisandreae/keyboard-firmware
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
I would guess that memory consumption, not speed, is the limiting factor vs. C in many applications. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells take a lot of extra space. At least it has vectors.
I would guess that memory consumption, not speed, is the limiting factor vs. C. I skimmed through the source code and couldn't find a way to define heterogeneous packed data types (i.e. structs). That would be a serious turn-off for me. Cons cells are a lot of overhead. At least it has vectors.
It's true that there are no structs, but it wouldn't be much of a stretch to add them. There's a discussion of writing a macroexpander in another Scheme runtime like Guile which can compile macros to microscheme output. (This is a bit like how ClojureScript lacks runtime eval but allows you to write compile-time macros in Clojure.) Writing a define-struct macro that compiles to vector-ref at runtime would be pretty trivial once you have a macroexpander working.
If you're interested in hacking on a small Scheme implementation, I'd encourage you to give it a go. The author is very responsive and friendly.I blame arduino, 70Mips >40KB ram STM32/dsPIC is same price, but teach sheep arduino and they will only know arduino.
Right now the tmk firmware has the best support for these features, but I'm having to do a lot of monkeying around with it to get dual role keys to work in the home row without interfering with my normal typing.
For example, holding the 'f' or 'j' key acts as CTRL, but tapping works normally.
The TMK firmware works on the Atreus keyboards too; I used it for a while before writing my own firmware. I plan on putting up some better docs soon on how to use it with the Atreus if you want some of these more advanced features.
From a learning perspective it's also nice to have a dramatically simpler firmware too. The initial version of the C atreus-firmware codebase was just over 100 lines.
At some point I want to make something like the Atreus but with a bit more buttons. Basically the ergodox without the thumbs pads and most of the bottom row and without a split.
On the subject of keymaps, it seems like a finite state machine with transitions on down and release. I haven't seen any firmware try that yet. Perhaps its the debouncing logic which makes that too complicated.
Keep up the good work!