Friday, 22 January 2021

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.




Saturday, 26 September 2020

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.


 

Sunday, 14 June 2020

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.


Wednesday, 29 April 2020

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.