Linux on the Acer SW3 laptop/tablet

 This machine is the Acer SW3 which is an old tablet PC. It came with Windows 10 32-bit and has a 32Gb internal EMMC storage.

Unfortunately, following many Windows updates, Windows no longer fits in the 32Gb storage and I can't find anything more that can be deleted. Windows won't update and has critical vulnerabilities; new software won't install (there is little space anyway) and Windows is very slow.

So I decided the only way to use the machine was to install Linux.

This is not easy, as in 2021 finding a 32-bit Linux distribution is tricky. But Debian still works.

 

So I put the installer on a usb stick and tried to install. Getting it to boot was the first hurdle - but solved eventually.

The BIOS on this machine is absolutely terrible. After much experimentation:

• The BIOS ignores most of the EFI spec and will only boot Windows Boot Manager from the internal EMMC
• It largely ignores the EFI boot table, and just does its own thing.
• The BIOS setup program (Press F2 to activate) is graphical and does not have many useful keyboard shortcuts - so the only way is to use the mouse (or built-in touchscreen)
•   

 I have *eventually* got it to boot Debian from the emmc after looking at this page https://hansdegoede.livejournal.com/24132.html

 

I copied the EFI boot files from their normal directory (EFI/debian) to where Windows puts them (EFI/Microsoft/Boot) and renamed shimia32.efi to bootmgfw.efi (the Windows loader) - then the BIOS just blindly loads it anyway.

 

So far:

 * Wifi is ok

* Touchscreen works

* There seems to be no sound.

 

Needless to say, this machine is VERY slow and old, web browsing is possible but requires some patience. Videos play with a little skipping.

 

 

Making the BBB Red ESC

 In this post I'll explain why, and how I designed the Bristol Bot Builders N20 Red ESC electronic speed controller for small robots.

The Antweight / 150g robot ESCs

There are quite a few commonly used ESCs available.

• Various "dual channel" speed controllers with or without mixing - these come as a board with lots of flying leads and it's important to connect them correctly. BBB does a special one for Ants which has braking (most don't)
• My previous project - the Malenki Nano - which has a built-in receiver
• The DFRobot N20 

The advantage of the DFRobot controller, is that it's build on the back of the N20 motor and can be plugged directly into a receiver. This makes it easy for newbies and flexible for different designs. It also simplifies the wiring - these robots are very small and it can often be difficult to cram all the wires into the chassis.

The good and bad of the DFRobot:

Good:

• Very easy to use for newbies
• Flexible for designs
• Simple wiring
  

Unfortunately there are some problems: 

Bad

• No braking
• Many reports that these controllers fail on 2S lipo packs (8.4v maximum) after prolonged or regular use
• The supplied lead is much too long for these small robots
• Comes already soldered to a N20 motor - if it isn't the type you want - then you need to desolder it and put on a different motor.

So in this project, I tried to fix all the bad things but keep all the good things :)

Features 

Feature	DFRobot	Red ESC
Maximum voltage	about 6v (all day) 8.4v (for a while perhaps?)	9v forever :)
Orientation	"Vertical"	Horizontal
Braking	No	Yes
Lead	>200mm	80mm

 

Design notes

Connectors

Choosing connectors is one of the most difficult things! The DFRobot esc uses a JST-XH 2.5mm pitch connector. To make it fit, they've put the connector on the opposite side of the board from the other components, and it uses the full width of the board. This means that it's a double-sided assembly. I didn't want to do double-sided assembly as it increases costs and I'm working at a much lower volume.

There are a bewildering array of connectors available, but I eventually settled on the incredibly tiny JST-SH 1mm pitch surface mount and wire-mount connector. Assembly of leads for prototyping was likely to be impossible (it is a super tiny crimp), so I bought some already-crimped leads with bare wires, and crimped my own servo connectors on the other end.

Orientation

I cannot take credit for this, it was Joe's idea. The idea was simply to have the pcb a similar size/shape as the dfrobot, but with the terminals in a different orientation, so it can go out "sideways" from the motor, 

DFRobot (left), Red ESC (right),

 

 

This makes the setup work better for thin robots.

 

Cable assembly

This was a new experience for me - finding a random company to assemble cables. I am pleased that it worked very well.

The crimping for the jst-sh end  is critical - I also wanted to make sure that the wire colours were correct.

The advantage of having these custom cables made - I could specify the length - so I made the cable 80mm, just about long enough for most small robots, but less than half the dfrobot one (which I think is about 200mm)

Microcontroller and firmware

After some messing around, I decided to use the Attiny4 microcontroller - it is the smallest and weakest AVR microcontroller, and one of the smallest ones generally available. It is in a sot-23-6 package, which is just-about hand-solderable, and has an amazing 4 gpio pins.

I did a couple of tricks -

• The internal oscillator on these microcontrollers is not perfectly accurate, so we can't measure 1500 microseconds reliably. So based on an idea from Scott (thanks Scott!) - I simply auto-calibrate when receiving the first pulse after power on.

• The input signal pin - I have used the "reset" pin for the input signal - which has an advantage that it's tolerant of up to 12 volts, as the 12v is used for "high voltage programming mode" 

 

The Attiny4 can be programmed using a Arduino with the ArduinoISP firmware. After the RSTDISABLE fuse is blow, then it can only be reprorgrammed by putting 12v into the reset pin. I haven't yet found a way to reset the fuse (but I think it's possible).

The firmware is about 250 lines and compiles to 362 bytes (the Attiny4 has 512 bytes of flash)

Development pictures

 

 

 An early layout attempt - which didn't actually fit.

 

Doing a fit test on the PCB minus components

A panel made by JLCPCB for the prototypes. I had them assemble some of the trickier components and put the microcontroller and connector on by myself.

 A home made prototype - similar to the production version, but not quite so red 

 

Dogfood-robot with red on one side and dfrobot on the other

Some assembled panels

The Raspberry Pi Pico Microcontroller

Yesterday they launched a new product, the Pi Pico Microcontroller.

I thought "meh" what's so special? We already have plenty of microcontrollers, and several popular platforms with Makers:

* Arduino (AVR-based)

* ESP32 (dual core, weird xtensa architecture, hardware floating point, built-in wifi and bt radio) - a highly capable, very complex and poorly documented chip

* Micro Bit and the NRF52* chips - built in radio, ARM cores

* Loads of 8-bit options and 32-bit options for uc

So, what is good about the Pi Pico?

Proper USB

Many of the other popular microcontrollers don't have a "real" USB interface. The Arduino Nano and ESP32 boards have a USB connector, but it's hard-wired into a usb-serial thing. This means it can only ever be a serial port.

With the Pi Pico, it can be a USB serial if you want, but it can also be other things, possibly at the same time:

* HID emulation (become a keyboard / mouse)

* Storage emulation - that's what the bootloader does

Also, the "USB Serial" on the Pi Pico is only emulated, it doesn't have the limitations of a real serial interface, it doesn't electrically exist - it's much faster and can't get its baud rates mixed up.

 

NB: Yes, I know that a lot of other microcontrollers DO have USB, and the latest ESP* chips have proper USB too.

Unbrickable

I don't like to use the term "unbrickable" as I successfullly bricked a "unbrickable" esp8266 :)

 

But the bootloader is in ROM -so it can't be trashed - and both the SWD interface and USB bootloader will allow you to reflash a Pi Pico.

The Arduinos - are brickable in principle - as the chips have various "fuses" which can be set in a way which prohibits further programming. This is by design, but it's bad if accidetnally activated.

Also the Arduino bootloader, if overwritten, makes it more difficult (although not impossible) to reuse the device.

 

PIO Interface

I think it's fair to say that the hackers who have played with the PIO are only starting to appreciate its capability. I've not played with it yet, but it is:

• Flexible interface for reading / writing serial or modestly parallel protocols at (fairly) high speeds
• Can be reprogrammed to do UART, SPI, and all sorts of other things which don't have dedicated hardware
• Writing data to the "infamous" WS2812 "neopixel" self-clocking serial protocol - which needs to be bit-banged on nearly every device.
  
• Uses yet unimagined

Some other microconrollers have similar things, but as far as I can see, the Pi Pico's PIO is more flexible, easier, better documented, and possibly more powerful than most of them.

 

 To be fair, the ESP32 also has a peripheral called "RMT" which can do some of these things.

Enough memory

A lot of the other chips in the same kind of price range have a smaller amount of SRAM - which makes even simple things awkward. Also low-SRAM chips have little or no capability of using high level languages or text-based diagnostics (think REPL) - because there simply isn't enough RAM to store the strings.

 

I tried programming the esp8266 using Micropython - it works, but there is a crippling lack of RAM which makes complex programs impossible (even though there is execute-in-place).

 

The Pi Pico also has execute-in-place which makes more ram available for applications.

 

ARM cores?

To be honest, it would have been "interesting" to see RiscV cores, but I know that Cambridge-based Raspberry Pi is very ARM-centric. I suppose nobody got fired for using ARM. I'm far less excited about the cores than the rest of the chip.

The PCB / dev board

I've been talking so far about the microcontroller - but the Pi Foundation actually released a dev board (the microcontroller isn't generally available yet - but it will be - and some other integrators have already got samples).

The dev board isn't anything magical or special, but it is quite tidy and looks to have good power regulation.

Personally I'd have quite liked to see the header pins 0.1 inch closer together - but that would probably make breaking out all the GPIOs more difficult or compromise other things - so it's ok.

 "Raspberry Pi Silicon"

As far as I can tell this is a marketing gimmick mocking another fruity company.

 

Weren't the Raspberry Pi 2, 3, 3B+, 4  all Raspberry Pi silicon? They were all chips made by Broadcom but totally to the spec of the RPF and not generally available.  Only the first Pi used an "off the shelf" chip.

It seems the major difference is labelling. And the guts of the Pi Pico presumbly contains lots of IP from different companies. They could have easily outsourced much of the design and/or validation.

So I think it's just marketing words.

1-wire radio control protocols

Ramble...

 These protocols are used typically to communicate between a radio reciever and flight controller, or any other kind of controller in a flying drone, robot, or something else.

 

I'm considering here, ibus, sbus and PPM

 FUTABA S-BUS

------------

This is the protocol used by Futaba receivers, servos, and some other things. It's a serial
1-wire protocol and uses an unusual bit rate of 100kbaud.

Some details are here:
https://os.mbed.com/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/
https://github.com/uzh-rpg/rpg_quadrotor_control/wiki/SBUS-Protocol

The S-bus signal is "upside down" - normally low, and uses low=0, high=1.

S-bus also requires some "bit twiddling" because it uses 10 bits per channel and splits them between several bytes.

 Pros: Many digital receivers support it.

Cons: A pain in the arse to decode, difficult to simulate, USB serial dongles usually can't decode it.

TURNIGY / HOBBYKING / FLYSKY - I-BUS

Ibus uses a bit rate of 115,200 baud, which is a "standard" speed. I-bus is "the usual orientation", normally high, low=1, high=0 (this is consistent with most other serial protocols)

Ibus uses simply 2 bytes per channel and outputs the number of microseconds wide that a pulse would be if the channel was transmitted as a servo pulse (1000 - 2000 with 1500 as the centre).

Pros: Much simpler than S-Bus to decode, can decode with a USB-Serial dongle easily.

Cons: Only Flysky (like) receivers support it.

PPM

PPM is a scheme of multiplexing several channels of servo pulses on the same wire. It still uses 1000-2000 microsecond pulses for the channels, but sends them sequentially with a longer sync pulse.

 

If your microcontroller doesn't have a crystal, you might not be able to detect the 1500us centre pulses accurately, and need to trim the centre position. The microcontroller might vary its speed slightly depending on voltage and temperature.  (Radio receivers need a crystal to operate their radio, so their timing must be spot on)

 

 

Pros: Widely supported

Cons: Analogue; need exact timing to get centre position trimmed correctly. Electrical noise could cause channels to get mixed up with crazy results. Supports fewer channels than sbus or ibus.

 

Malenki-Nano receiver - development pictures

Here are some pictures of prototypes of the Malenki-Nano.

Prototype 0

This was a veroboard / stripboard which was already used for development of my earlier ESC. The MCU was atttiny1614, and the radio module was "dead bug" installed with hot glue and bodge wires.

Motor drivers were mostly none, but I did add a rz7899 on a breakout board at some point. There are various sockets in the front side of the board and quite a few LEDs, I can't remember why I put them all there or what plugged in where.

 

Prototype 1

 I created a PCB with rz7899 motor drivers x3 and components on both sides. It used the attiny1614 which was hand-soldered quite easily due to its 1.27mm pitch.

Unfortunately this prototype died a fiery death caused by a short circuit connected to a lipo.

This was a lot bigger than it needed to be, so I looked for other motor drivers to replace the (excellent, reliable) rz7899.

Prototype 2

This hand-soldered prototype uses the mx113l motor drivers, which are in a little sot23-6 package, but don't handle as much current as the later ones.

Soldering the attiny3217 was quite tricky (no pins, 0.5mm pitch pads) 

This board unfortunately had a couple of design mistakes which were not easily corrected - I added a bodge wire to make the radio work, but the weapon channel is still broken.

It still drives ok and I use it to test firmware in a robot (pictured).

 Prototype 3

I finally got it right! The motor drivers are now drv8837d which are really tiny and drive 1.8 amps. Hand-soldering this prototype was not easy and I broke one board completely before I made this prototype work.

Production board

The first production run. These were panelised with 2 boards per panel, so you can see the "mouse bites" where they were separated. A machine soldered these ones.

Programming pins rig

I made this rig to do programming and testing, to avoid the need to clip / unclip at least three test clips (without creating any shorts...)

 

I can hold the pins down with a test-device, then wait while the firmware is written. It then automatically starts in a special test mode which flashes all the LEDs on the programmer (using the motor drivers) so that I know all the motor drivers are working ok.

Electronics assembly with Kicad and JLCPCB Assembly

I am shortly getting this assembled:



Thanks to JLCPCB Assembly.

Designed with Kicad  

A big thanks to all EEVBlog forum users and EEVBlog forum user "essele" who created this Kicad plugin for jlcpcb assembly which I have now forked to work with panelised boards

Also thanks to Flemming Frandsen for kicad-util which generated the pcb panelisation. I have forked this to work with Kicad-nightly.