Update READMEs.

.gitignore

@@ -0,0 +1,3 @@
+across
+stellaris
+msp430/mecrisp

deploy/sbo-sht31/README.md

@@ -1,10 +1,10 @@
 # deploy-sht31
 
-Runs on the [deploy sensor board] (one of the variants of the board I sometimes
-refer to here as _sbo_), with SHT31-D sensor wired up to it. (I got
+Runs on the [deploy sensor board] -- one of the variants of the board I sometimes
+refer to here as _sbo_ -- with SHT31-D sensor wired up to it. I got
 [this one](https://www.tindie.com/products/closedcube/sht31-d-digital-humidity-temperature-sensor/)
 from Tindie - comes with a protective filter cover, which is really handy since
-this sensor is intended for the outdoors.) Takes readings and sends them
+this sensor is intended for the outdoors. Takes readings and sends them
 over. Consumes 2.5uA in sleep.
 
 I use [this platformio/arduino sketch](https://git.drak.xyz/flabbergast/jee-sensors/src/branch/master/gateway)

jz4/README.md

@@ -11,18 +11,28 @@ tested with `flib/stm32l0/sleep-extra.fs` code, I got cca 11-12uA consumption in
 sleep, with 5V source through the regulator. However powering the regulator
 with 3.3V and sleep gives about 22uA consumption.  Powering with 3.3V directly
 to the "battery" pin asks for the 12-15uA of power (seems to be a tad higher
-with TX/RX pins connected) - so the regulator has very very low ground power,
-and doesn't seem to mind back-powering too much.  Overall, this is pretty
-sweet.
+with TX/RX pins connected).
 
 There is a [blog post](https://jeelabs.org/article/1652b/) in which jcw
 measures power consumption. Roughly the same numbers as here, except the
 very low power stuff is reported lower: 6.5uA with the setup as above
 and 3uA with GPIOs in Hi-Z. Well. (Switching GPIO to Hi-Z mode does save
 about 3uA.)
-
 He reports that the regulator takes 0.5uA, and the radio in sleep 0.1uA.
 
+Hm. I think most of the extra consumption I see on my jz4 is actually consumed
+by the regulator: Directly powering an L041 (on my sbo board) with no regulator
+in sight gives about 2uA consumption in sleep on 3.3V; powering my bat board
+with L052 through a different regulator (NCV8170) with 5V yields about 4uA in
+sleep.
+
+I mean 11-12uA through the regulator is not too bad, but this needs
+either LiPo or 3 AA or something like that. For a direct supply to `vdd`
+(like a CR2032 coin cell or 2 AA), the best course of action would be
+to cut a trace somewher between the regulator and `vdd`. This is hard
+to undo. Or just accept 15uA consumption, this is still fine for a year
+on a CR2032.
+
 
 ## Credits
 

jz4/wieg.fs

@@ -92,6 +92,7 @@ false variable w1msg-on \ are we receiving?
 : p1bin ( -- ) \ print w1 bin format
   w1bit @  w1ptr @  w1recv  printwiegbin cr ;
 
+' p1hex variable w1printfn  \ word to use for printing
 
 \ -----
 \ tasks
@@ -106,7 +107,8 @@ task: w1task
       w1bit~us @ 30000 +  micros u< if
         dint
         false w1msg-on !
-        p1hex clear1recv
+        w1printfn @ execute
+        clear1recv
         eint
         LED ioc! 1 ms LED ios!
       then

sbo-l041/README.md

@@ -3,7 +3,8 @@ STM32L041 with RFM69CW radio.
 
 It runs on both [the dev version](https://flabbergast.drak.xyz/posts/sbo/)
 and the [sensor deploy version](https://flabbergast.drak.xyz/posts/sbo-box/) -
-they've got the same schematic, just the PCBs are different.
+they've got the same schematic (almost - the power jumpers are better
+thought out on the deploy version), just the PCBs are different.
 
 The space is quite tight (32kB flash), of which 16kB is taken up by Mecrisp
 Stellaris core. So I tried to minimize the includes, so various convenience

suf072/README.md

@@ -5,7 +5,7 @@ see [his blog post](http://jeelabs.org/2016/06/standalone-usb-firmware/).
 He has done a really amazing job of getting this running in the first place; in
 his case for F103-based devices.
 I have modified it so that it runs on F072; the primary target for me is the
-[bat board] (with STM32F072CxT6). I have also tried it on 
+[bat board] with STM32F072CxT6.
 
 The assumption is that it runs on a clean Mecrisp Stellaris image, ideally with
 jcw's 'spezial' modification (there are binaries available in this repo in
@@ -29,6 +29,21 @@ done either over USART, or over USB with `dfu-util` - the latter is convenient
 in that no USB-to-serial converter is necessary at all, since everything
 happens over USB.
 
+
+## Version for F042
+
+There is also a version for STM32F042 here; the assumption is the TSSOP-20
+package (so STM32F042F6P6, like [this
+board](https://flabbergast.drak.xyz/posts/arm-breakouts/#stm32f042fxp6)). Just
+a few differences:
+
+* Hal needs to remap PA11/PA12 over PA9/PA10 for USB to work.
+* Expects non-RA mecrisp stellaris (space is tight).
+* `USART2` can not be clocked from HSI, so changing the main clock on these
+  requires changing `BRR` (baud rate) to keep a serial console.
+* The actual USB driver is exactly the same.
+
+
 ### Notes
 
 See also the details about all this (for F103) in jcw's original
@@ -36,7 +51,7 @@ See also the details about all this (for F103) in jcw's original
 
 In particular, `eraseflash` will keep the USB driver/console in, but `$5000 eraseflashfrom`
 erases the USB driver and goes bat to a clean Mecrisp (USART console only). The USB
-driver takes up 6kB of flash. Note that the clean Mecrisp runs the prompt on a particular
+driver takes up 6kB of flash. Note that a clean Mecrisp runs the prompt on a particular
 USART (that was determined when Mecrisp Stellaris was compiled). My images run with TX/RX
 on PA9/PA10, USART1, 115200 baud.
 

suf072/hal-stm32f04.fs

@@ -0,0 +1,71 @@
+\ base definitions for STM32F042 (STRIPPED-DOWN version for USB driver use!)
+\ adapted from jcw's embello for STM32F103
+\ adapted from mecrisp-stellaris 2.2.1a (GPL3)
+
+: chipid ( -- u1 u2 u3 3 )  \ unique chip ID as N values on the stack
+  $1FFFF7AC @ $1FFFF7B0 @ $1FFFF7B4 @ 3 ;
+: hwid ( -- u )  \ a "fairly unique" hardware ID as single 32-bit int
+  chipid 1 do xor loop ;
+: flash-kb ( -- u )  \ return size of flash memory in KB
+  $1FFFF7CC h@ ;
+: flash-pagesize ( addr - u )  \ return size of flash page at given address
+  drop 1024 ;
+
+: bit ( u -- u )  \ turn a bit position into a single-bit mask
+  1 swap lshift  1-foldable ;
+
+$40021000 constant RCC
+     RCC $00 + constant RCC-CR
+     RCC $04 + constant RCC-CFGR
+     RCC $14 + constant RCC-AHBENR
+     RCC $18 + constant RCC-APB2ENR
+     RCC $1C + constant RCC-APB1ENR
+     RCC $30 + constant RCC-CFGR3
+     RCC $34 + constant RCC-CR2
+
+$40022000 constant FLASH
+    FLASH $0 + constant FLASH-ACR
+
+$40006C00 constant CRS
+    CRS $00 + constant CRS-CR
+    CRS $04 + constant CRS-CFGR
+
+: 48MHz-after-reset ( -- )  \ set the main clock to 48MHz (HSI->PLL) assuming we're out of RESET
+  %10001 flash-acr bis!
+  %1010 18 lshift rcc-cfgr !
+  24 bit rcc-cr bis!
+  begin 25 bit rcc-cr bit@ until
+  %10 rcc-cfgr bis!
+  $1a1 $4000440C !  \ change USART2_BRR to match 48MHz
+;
+
+: usb-clk ( -- )  \ enable HSI48, autotrim and set USB clock source
+    16 bit RCC-CR2 bis!                \ switch on HSI48
+    begin 17 bit RCC-CR2 bit@ until    \ wait for HSI48RDY
+
+    27 bit RCC-APB1ENR bis!            \ enable CRS
+    CRS-CFGR @  %11 28 lshift bic      \ prepare setting SYNCSRC
+        %10 28 lshift or CRS-CFGR !    \ set USB SOF, write back
+    6 bit 5 bit or  CRS-CR bis!        \ set AUTOTRIMEN and CEN
+    \ will only start actually working after we start getting SOF
+
+    7 bit RCC-CFGR3 bic!               \ HSI48 is USB clock source
+;
+
+
+\ emulate c, which is not available in hardware on some chips.
+\ copied from Mecrisp's common/charcomma.txt
+0 variable c,collection
+
+: c, ( c -- )  \ emulate c, with h,
+  c,collection @ ?dup if $FF and swap 8 lshift or h,
+                         0 c,collection !
+                      else $100 or c,collection ! then ;
+
+: calign ( -- )  \ must be called to flush after odd number of c, calls
+  c,collection @ if 0 c, then ;
+
+: cornerstone ( "name" -- )  \ define a flash memory cornerstone
+  <builds begin here dup flash-pagesize 1- and while 0 h, repeat
+  does>   begin dup  dup flash-pagesize 1- and while 2+   repeat  cr
+  eraseflashfrom ;

suf072/hal-stm32f0.fs → suf072/hal-stm32f07.fs

@@ -51,7 +51,7 @@ $40006C00 constant CRS
 
 : 48MHz-after-reset ( -- )  \ set the main clock to 48MHz (HSI->PLL) assuming we're out of RESET
   %10001 flash-acr bis!
-  %1000 18 lshift rcc-cfgr !
+  %1010 18 lshift rcc-cfgr !
   24 bit rcc-cr bis!
   begin 25 bit rcc-cr bit@ until
   %10 rcc-cfgr bis!

suf072/usbbase-bat-f072.fs

@@ -6,7 +6,7 @@ $5000 eraseflashfrom  \ this must be loaded on top of a *clean* Mecrisp image!
 cr
 compiletoflash
 
-include hal-stm32f0.fs
+include hal-stm32f07.fs
 include ../flib/any/ring.fs
 include usb.fs
 

suf072/usbbase-f042.fs

@@ -0,0 +1,24 @@
+\ USB console for the bat board with F072
+\ modelled after Jean-Claude Wippler's USB console for F103 boards
+\   in embello: https://git.jeelabs.org/jcw/embello
+
+$4000 eraseflashfrom  \ this must be loaded on top of a *clean* Mecrisp image! (*non* RA)
+cr
+compiletoflash
+
+include hal-stm32f04.fs
+include ../flib/any/ring.fs
+include usb.fs
+
+: init ( -- )
+  \ with the 'spezial' mecrisp base, mecrisp's init doesn't run so...
+  %111 17 lshift RCC-AHBENR bis!  \ enable GPIO ABC
+  48MHz-after-reset               \ go to 48MHz
+  0 bit RCC-APB2ENR bis!          \ enable SYSCFG clock
+  4 bit $40010000 bis!            \ PA11_PA12_RMP in SYSCFG-CFGR1 (remap pa11,12->pa9,10)
+  usb-clk                         \ prepare HSI48 clock and CRS
+  usb-io                          \ switch on USB console
+;
+
+( usb end: ) here hex.
+cornerstone eraseflash