Category Archives: Microprocessors

Farnsworth (Warehouse 13 artifact) – Continued

From the last post a lot has changed.

I’ve resized the cases and moved some of the aesthetics around to get every thing to fit in the case.

The display now gives connection information and displays status connected/not connected, and has the ability of displaying graphics with this information.

The software has had a lot of additions, I can now read from the SD card a set of destinations and select them using the rotary encoder wheel on the front of the case.

A destination is defined as an IP address, port and channel. The Channel is used by the UDP repeater to join Farnsworths together (Strowger.py)

The connection has gone from just Farnsworth to Farnsworth, to connection options using a central UDP proxy, (Strowger.py) hopefully with the aim of getting communication out from only being in the local network. This has also added various testing additions along the way including a test card and a loopback mode, both locally in the Farnsworth and to/from the proxy for remote testing.

If you have multiple Farnsworths on a local network, they need to be set to different ports so NAT can find them for the incoming channel.

Audio is proving to be a pain. The Pico’s A2D is very noisy, and the simple amp I put on the existing PCB isn’t up to the task to overcome this. I’ve replaced the single transistor amp with a low voltage op-amp that will hopefully have a lower output impedance into the ADC.

The other issue is ensuring that the 8khz sampling and playback happens regularly regardless of the camera’s capture and incoming UDP connections.

From comments from Mastodon, the two sound clips from the original Farnsworth have been incorporated, with the “text” tone used to indicate that the Farnworth has connected to WIFI, and the “RING” tone used to indicate that a Farnsworth to Farnsworth connection has been made.

Finally got it all into the Case. This one is a Woodroffe, for obvious reasons for those that know me. When I get time ill update the older Farnsworth to the same case standard.

Just so happy I have two and they can talk to each other.

Code circuit diagram audio files and graphics are available on Github https://github.com/ExtremeElectronics/PhiloFax

Previous Article

Farnsworth (Warehouse 13) artifact creation

So for reasons I’m not entirely sure of myself I decided I was going to build a Farnsworth.

For those of you who are not fans of Warehouse 13, as Farnsworth is a Steampunkesque hand held video and audio communication device, named after Philo Farnsworth the inventor of electronic Television.

A picture of one from the TV series is viewable on the Warehouse13 fandom site here

Of course this is only a prop, me, being me wanted one that worked.

“The Farnsworth is a two-way audio and video communications device invented by Philo Farnsworth in 1929, soon after the invention of the television. They’re used by Warehouse agents because they are on their own secure frequency spectrum and can’t be cracked, hacked, tapped, or otherwise “broken.” However, Artie stated in Season 5 that it could potentially be vulnerable to hacks if Claudia messed with it.”

My Farnsworth, will be totally hackable, insecure and very easily broken, but working. (hopefully)

Of course I could have just put a phone in a box and extended the display, microphone etc. but where is the fun in that ?

I’ve been playing with Pi Picos a lot recently, and Id not really explored the Pi PicoW and its networking abilities.

So all I need to do is to attach a camera, a display microphone and speaker and I’d be ready to go. Oh, and I didn’t want it to cost me an arm and a leg.

Looking in my spares box I had a cheap camera the OV7670, the problem with this device is, although cheap, it uses 14 IO, this would severly limit what else I could do with the PICOW. Luckily UsedBytes( Brian Starkey) https://github.com/usedbytes/camera-pico-ov7670 had done a pico project for robot vision using this camera, for this he had used a parallel to serial shift register to drop the 8 data lines to a single line and the PIco’s PIO to reconstruct the data. The downside was his library only ran at 80×80 pixels in mono.

After quite a lot of changing parameters in his library I got it to work dropping a 240×320 colour (RGB565) image into the Picos ram.

The Display was much easier, the GC9A01 35mm circular display is much more common, and as all I needed was to be able to write bitmaps to the display, I soon had cut down the available librarys and had a DMA running to drop the camera image to the display.

As I only wanted 240×240 on the display, I split the process into lines, rather than moving the whole buffer at once.

This also meant that I could send this data easily to a UDP Socket on the PicoW. All I do is add the line number to the beginning 240 RGB565 integers, and send this as a UDP packet.

At the receiving end, I strip off the first byte and dump the rest directly into the display. If a line is missing or corrupt (this is UDP) it gets over written in 1/5 second anyway.

This scheme also left me with 241-255 as a starting byte I could use for other purposes. Sound being one of these.

Sound is via a single transistor amp (probably needs to be a better amplifier) into the pico’s A2D sampled at 8Khz

So sound is given a starting byte of 250 and 10mS of sound is sent in the same way a line is sent every 10mS

At the other end the sound packet is unpacked and pushed into a FIFO buffer so it plays for 10mS, if the buffer empties then silence is played.

The Case outer is 3d printed from black PLA, and the two front plates are made from black acrylic engraved on a laser cutter with infill of acrylic paint.

Loads still to do, Ill update here as the project progresses.

The code is available on Github https://github.com/ExtremeElectronics/PhiloFax

Continued here…

Pico Lynx

A Pico Emulated Camputers Lynx

The Camputers Lynx was a classic, although not massively popular computer in the early 1980’s. It featured a z80 at 6Mhz and full colour graphics, with none of the BBC micro’s (or others) Graphics mode shenanigans. And for its time many advanced capabilities like 96K memory, a disk system (later upgradable to CP/M 80), and a proper keyboard. Unfortunately it hit at a bad time, the Spectrum was much cheaper, but much less capable, and the BBC was being pushed massively by the BBC (unsurprisingly). It’s eventual down fall was that its brilliant graphics were both quite slow and due to its strange memory banking system, rather hard to program. Eventually it lost out due to the lack of game titles compared to the Spectrum and BBC Micro/Electron.

But I had one and I loved it (latterly I had three)

Camputers Lynx (By Retro-activity, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=31282859)

I already have a PCB that Ive used for Pico Emulation of a number if things, so that was my go to as a start.

I had asked for permission to use the code by Charles Peter Debenham Todd retrogubbins (as there is no licence on his GitHub pages) and he graciously let me use his code with no restrictions.

I based my Pico design on his PALE emulator and his ESP 32 emulator https://github.com/retrogubbins/PaleESP32VGA

One of the first issues I had was that the Z80 emulation that he used did not have any licence either, so early on I swapped it to LIBZ80 © Gabriel Gambetta (gabriel.gambetta@gmail.com) 2000 – 2014 which is currently maintained by EtchedPixels as part of the z80 emulation kit https://github.com/EtchedPixels/EmulatorKit

I’ve used this library before in the RC2040 So familiarity was on my side too.

Swapping over the emulator and porting the ESP32 code to the Pico was amazingly straight forward, I needed to write some code to DMA out the RGB banks to a display (240×320 OLED) and I quickly got a Lynx prompt.

Unfortunately it was in Yellow, and the emulation stopped there. I took me a while to get past this, until I realised that the Lynx Beeps, between writing the Red and Green banks, and before writing Blue. I hadn’t implemented the code for the sound / speaker.

Adding this in gave me not only a while logo, but two power up beeps, and (after spanering in serial to the keyboard emulation ) a workable basic.

So time to make a case.

I took the measurements from a real Lynx and scaled it to roughly fit the keyboard I had with the PicoPuter. It came out as roughly 1:3

Of course Not everything fitted correctly, so after a few goes.

I got one that fitted and held the PCB’s in roughly the right place.

Of course I needed a monitor, so I did a quick 3D print of an IBM 5151 style monitor. This gave me the space to the right to hide the display connector. and as the original was only 12″ didn’t look out of place with the small Lynx Case.

For the keyboard I wanted actual working keys.

So I made an escutcheon from grey sprayed card

and laser cut/engraved a set of small keys to fit. Because I couldn’t get grey acrylic I used transparent acrylic, on top of a grey sprayed key holder.

The effect is grey keys with white painted idents.

Not 100% happy with these, but I have a set for working grey keys, on a grey Lynx shaped case. For a more accurate layout I’d need a custom Lynx keyboard PCB.

The whole case is only 120mm wide to give you some idea of scale.

The two PicoPuter PCB’s sit inside and a small battery, because it was vital for this to run as a portable 🙂

The Ribbon cable is the feed to the display, which is mostly hidden by the case and the display itself.

and attached to the back of the display by a small daughter board.

Pico Cray – Small scale distributed computing.

The Pico Cray is a cluster of 8 Picos and a controller Pico. All Picos are connected in parallel by an I2C bus. The controller is designated by one GPIO being held low, the processor Pico’s addresses are allocated automatically. The Controller Pico has a 320x240px display connected by SPI and a couple of buttons. As all of the Picos run the same software updating the cluster is easy.

Currently the cluster is programmed to run a Mandelbrot program. With each processor Pico calculating 120 points before returning them to the Controller.

Pico Cray

More RC2040 settings

The INI file

The ini file sets the defaults for the Rc2040 and substitutes for switches and buttons on boards that have none.

It allows you to select the ROM, RAM settings, and CPM settings for the emulation.

Using SIO based software

Requires CPM Inc Transient Apps SIO2.img,CPMIDE.id, 24886009.BIN and rc2040.ini for SIO2 as below

Rom Details

ROM has basic at address 0x0000 (000) ROMsize 0x2000
ROM has basic at address 0x2000 (001) ROMsize 0x2000
CP/M / Basic via monitor at address 0x4000 (010) ROMsize 0x4000
Small Computer Monitor at 0xe000 (111) ROMsize 0x2000
More detail at [https://github.com/RC2014Z80/RC2014/tree/master/ROMs/Factory]

RC2040.INI for SIO2

Config with no switches and other emulation settings for SIO2

[IDE]
idefile = “CPM Inc Transient Apps ACIA.img”;
idefilei = “CPMIDE.id”;

[ROM]
a13 = 0; // Address switches 0=0x0000 100=0x8000 111=0xE000
a14 = 1;
a15 = 0; // ROM file as ROM source
romfile = “24886009.BIN”; // source for Rom Loading – see a13 a14 a15
romsize=0x4000; // Size of ROM

[CONSOLE]
port = 1; // Console port 0=UART or 1=USB

[EMULATION] // ACIA=0 SIO=1;
serialtype = 1; //SIO selected
inidesc=”SIO using 24886009.BIN”; //describe the ini

[SPEED] //vPico overclocking *1000 Mhz
overclock = 250; //overclock the PICO at 250 x 1000


Using ACIA Software

Config with no switches and other emulation settings for ACIA

Requires CPM Inc Transient Apps ACIA.img,CPMIDE.id, R0001009.BIN and rc2040.ini as below

Rom Details

Rom has basic at address 0x0000 (000)
CP/M via monitor at address 0x8000 (100)
Small Computer Monitor at 0xe000 (111)
More detail at [https://github.com/RC2014Z80/RC2014/tree/master/ROMs/Factory]

RC2040.INI for ACIA

Config with no switches and other emulation settings

[IDE] idefile = “CPM Inc Transient Apps ACIA.img”;
idefilei = “CPMIDE.id”;

[ROM]
a13 = 0; // Address switches 0=0x0000 100=0x8000 111=0xE000
a14 = 0;
a15 = 1;

// Size of ROM
romsize=0x4000;

#ROM file as ROM source romfile = “R0001009.BIN”; // source for Rom Loading – see a13 a14 a15

[CONSOLE] // Console port 0=UART or 1=USB
port = 1;

[EMULATION]
serialtype = 0; // ACIA=0 SIO=1; ACIA selected
inidesc=”ACIA using R0001009.BIN”; //describe the ini

[SPEED] //Pico overclocking *1000 Mhz
overclock = 250; //overclock the PICO at 250 x 1000

Other INI options.

[ROM]
jumpto = 0x2000; // non standard start vector (e.g not 0x0000);
ramonly = 1;// ram only (no rom, 64K load from romfile);

[PORT]
pioa=0; // set the IO address of the 8 bit port

[IDE]
ide=0; //Turn off IDE
iscf=1; //enable cf file as idefile, rather than the .img format

[EMULATION]
inidesc=”Broken INI file”; //ini file description to show at boot

[DEBUG]
trace = 0 // trace details in RC2040.c

CPM Manager / CPM Tools

You can edit the contents of the SD card .img file using CPM Manger and directly add or remove files in the CPM img.

CPM Manager is available here.

If you are using Linux (or windows), you can use the CPM tools to add or remove files. CPM tools are available here If you are using CPM tools, you will need a diskdef files. Disk defs for the RC2040 format(s) are available here DiskDefs

PIO PORT

8 bits of a simple IO post are brought out to the RP2040 GPIO as an input/output port. The port is configured on the fly, So if you execute an IN instruction, the port becomes an input port, (with pull ups). If you execute an OUT instruction the port becomes an output port. (The Original RC2014 port is arranged as 8 outputs and 8 inputs, but there were only 8 bits available. )

Switches and Buttons

Details are in the Circuit diagram . Switches and buttons are not required. But give you direct access to the ROM addresses (top 3 address lines) and the buttons allow for a z80 reset, Dump and other functions.

A complete kit of parts for the RC2040 is available here from Extreme Kits

The RC2040 – Get you Started

A work in progress

Programming the PI Pico

The easiest way to do this is to go to the latest release of the RC2040 Git hub and download the RC2040.uf2 Plug in your PICO and drop the uf2 file into the Pico

Making an SD card

Take an empty SD card (this process will destroy ALL the data on it)

Format the card with a FAT32 filesystem either using windows format or a SD card writing program.

From RC2040 Git hub download the source_files zip (or tar) and extract the SD Card Contents directory.

Copy the contents of the ‘SD Card Contents’ directory onto the newly formatted SD card. You will need to unzip “CPM Inc Transient Apps ACIA SIO2.ZIP”

Connecting an SD Card

Wire in the SD card to your Pico or RC2040 board

Connecting to the serial port

For communicating with the RC2040, there are two options. By default the RC2040 uses the USB interface. When the RC2040 starts this should appear as a serial port on you connected computer.

I use Terra term, but MiniTerm or putty should work ok too.
#TODO add MiniTerm and putty details

Open Tera Term and select the newly added serial port

The COM port will vary, but it is usually the last one in the list.

Speed 15200, 8Bits, No parity, 1 stop bit, No flow control.

If you are doing copy and paste via serial, you will also need to set the transmit delay of 1mS per character and 3ms per line to prevent serial overruns.

Click New open and hit enter…

Hopefully you should see

_______________________________________________________________________________

RC2040 more settings


A complete kit of parts for the RC2040 is available here from Extreme Kits

The RC2040

Continuing from Emulating a Z80 RC2014 with CPM and IDE drives via an SD card here..

RC2040

What is a Rc2040

The RC2040 is an emulated RC2014 (a build your self Z80 computer). But this one is entirely contained within a RP2040 (Raspberry Pi PI Pico) processor.

On the RC2040 you can Run any RC2014 Stock ROM image. including Basic and various Z80 monitors and CPM monitor. (except RomWBW there isn’t enough RAM)
RC2014 Rom Image details are here

Details on running the various RC2014 ROM based programs are here

Emulated ROM and RAM is a bit weird, because internally it’s all actually RAM, but the RC2040 allows a user definable area of RAM that is read only, or no ROM at all.

It also allows loading of RC2014 ROM images (rather than programming ROMS or EPROMs) directly from the attached SD card.

With CPM the RAM is more interesting, as CPM starts running from a ROM, but when it loads, the ROM is switched out so it can use the full 64K RAM. This is achieved in the RC2040 by simulating the RC2014 RAM/ROM card that allows an IO port to “swapout” or disable the ROM

Running the CPM monitor from the ROM, allows you to run any CPM-80 compatible program. There are hundreds out there and they include BASIC, Infocom Adventures (Zork, Hitchhikers) Wordstar, Startrek this list is endless.

CPM of course requires disk drives. These are emulated in file(s) on the SD card. The format is similar to the format used in the RC2014 CF card module (and with some simple changes, It will also work with the same CF images).

Instead of the CF format, the RC2040 uses a .img format, this makes it directly compatible with the CPM images from the RC2014 web site. But for CPM to work we also need a drive geometry structure which matches the .img, this is provided with an additional .id file.

The img format gives 128M of drive space, Split into drives from A-P

The img file system also makes it directly compatible with CPM Disk Manager which allows you to directly write into the CPM img file from your computer, which saves a lot of time when transferring software to your RC2040

The RC2014 uses its serial port to talk to the world. The RC2040 has the ability of using either its own USB embedded serial port, or a physical serial port similar to the RC2014’s this is selectable (see ini file settings )

The RC2040 also allows you to run with two different serial port configurations ACIA and SIO. Unfortunately you need a different ROM and CPM bios to work with each serial port type. Hence the selection in the Github SD card section. (again this is selectable via ini file settings.)

The CPM IDE images come with a few CPM programs to get you started. Anything ending in .COM will run directly from CPM. anything with a .BAS extension needs you to run basic first (c:MBASIC) then load the program (load “programname.BAS”) and then run.

More details on running CPM are here

Get You started. ( a work in progress..)


A complete kit of parts for the RC2040 is available here from Extreme Kits

Emulating a Z80 RC2014 with CPM and IDE drives via an SD card

The RC2040

Ive always loved Z80’s Even before programming in high level languages I was had compiling Z80 code on a Nascom1

Recently I’ve discovered the world of emulated Z80’s via the emulator written for linux by Alan Cox (Etched Pixels) (https://github.com/EtchedPixels/RC2014) This allows various configurations of Z80 RC2014 (https://z80kits.com) machines to be emulated (along with 8080 8086 and may other 8 and 16 bit processors)

My C code was rather rusty and I wanted a project to re teach me the basics.

Starting with the Etched pixels code I quickly got it running on a Raspberry PI Zero and added a few simple peripherals.

Z80 Emulated RC2014 driving a colour OLED display from BASIC

Which is all fine, but well it was, all a bit easy.

Not So easy

So, I was looking for a project to play with the RP2040, ideal, apart from The RP2040 doesn’t give a linux OS, It doesn’t have any storage (other than its own flash) and it only has 240K of memory.

To emulate a CPM system you need a minimum of 64K (plus a switchable ROM) some form of storage, ideally removable. Some way of loading the ROM (although this can be compiled in as an image) and a serial terminal.

Well the serial terminal is easy, there are 4 plus USB to play with, although all of the emulation uses STDIO uniquely, which is only partially supported on a PI Pico in C

As I was only interested in the Z80 bits of the emulation and only with the peripherals commonly supported on an RC2014. I started on the Raspberry pi, removing all of the other non z80 library’s and the other peripherals I wouldn’t need.

This was easy, rip a bit out, patch the code so it didn’t require it, edit the make file, recompile, test. Repeat until you have a basic Z80 emulated machine.

ROM/RAM

The ROM, I temporally coded into C via the linux xxd command, from one of the factory ROM’s available on the RC2014 git hub. https://github.com/RC2014Z80/RC2014/tree/master/ROMs/Factory

The next problem is that the emulator as configured uses 512K of ram (RC2014 – 512k ROM 512k RAM Module) to emulate a paged ram card. As the RC2040 only has 240K of memory I needed to remove the Ram/Ram paged memory code and replace it with a 64K ram/Rom paged emulation (RC2014 64k RAM Module and RC2014 Pageable ROM Module), that will only take at max 128K. It also must allow for the ROM to be paged out to allow the bootloader to be installed at 0x0000.

Using the compiled ROM I could easily fill an array of uint_8 with a ROM image, and switch using port 0x38 as a RC2014

CPM

CPM was emulated using the EtchedPixels code for a removable CF card. The Binary is readily available already configured to boot on an RC2014 again from the RC2014 git hub https://github.com/RC2014Z80/RC2014/tree/master/CPM

From the CPM source image (.img) file, you need to make an IDE file system onto a .cf file. using CPMtools. Details are towards the bottom of this page under “CP/M Application Disks” https://github.com/RC2014Z80/RC2014/tree/master/ROMs/CPM-IDE

Luckily this CF file can again easily be tested by loading up the image using the RPI z80 linux emulator.

SD Card

Of course the Pico doesn’t have any storage like a CF card and the 3.3v bus makes interfacing to a 5v CF difficult, but there is the possibility of using a SD card via SPI.

Luckily there is a library for SD cards which works with the PICO no-OS-FatFS-SD-SPI-RPi-Pico https://github.com/carlk3/no-OS-FatFS-SD-SPI-RPi-Pico

Working through the example was straight forward and gives a great way to test your SD card connections and if required, format a fat32 SD card.

The connections to the SD card are simple, 4 wires and power.

PICO Z80 Emulation test bed.

PICO or bust

At this point there is no way we can test the code on a RPI, so we need to dive into the PICO.

Compiling the code to the PICO without IDE support was surprisingly straightforward. All that was required was to replace the TX/RX STDIO calls with a call to the PICO UART. Unfortunately there was no easy non-blocking call to the receive queue using the USB serial. So initially the input/output was all via the hardware serial port.

I tackled the SD card next, making a simple bit of code to read a 64K rom image from the CD card directly into the ROM array, so I could remove the horrible compiled C ROM. The ROM images came directly from the RC2014 Factory ROM images on Git hub.

Buttons and switches

To make the ROM selection easier I added three switches to emulate the RC2014 A13, A14, & A15 ROM select jumpers, This meant I could easily switch between ROM starting addresses when loading from a rom image.

As I was adding switches, I decided to add a few buttons. which give me a Z80 reset and a dump RAM initially as a hex dump to the terminal, and latterly as a .bin file into the CD card for debugging.

To allow for a switch-less operation for the switches / buttons to work you need to ground GPIO 22, otherwise the RC2040 will run with switch-less defaults( currently CPM ROM and USB serial)

PICO CPM

I changed the IDE library to use the FatFS-SD-SPI-RPi-Pico file system and pointed it to load the .cf image from the card.

After A LOT of playing around with the differences in read/write and seek, plus RAM/ROM switching and serial problems. It finally loaded 🙂

I also found that if I disabled the RAM/ROM switching on a emulated z80 reset (from the button), I could warm boot into CPM, bonus…

Circuit

More Serial fun

Eventually I sorted the problems with the blocking USB serial by writing an interrupt driven routine that fills its own circular buffer, so now (from a switch) you can select which serial port you prefer.

Tiny Rc2040

If you don’t need the switches/ buttons, you can run it without, using a Pimoroni Tiny 2040 using the USB serial, making the smallest z80 CPM machine, ever (unless you know different?)

vbnvbn

Make your own

All of the files to emulate a Z80 with IDE on SD are available via git hub https://github.com/ExtremeElectronics/RC2040

Unfortunately I haven’t quite solved the Serial issues yet. The serial interface(s) will only take characters as a really slow rate. If you are going to cut/paste code into the RC2040 you will need to add in a 40mS (or longer delay) into your terminal program.

Serial issues are much improved. If added a block to the RX char circular buffer code that will only allow char RX, if the ACIA isn’t currently in an interrupt and added a fake interrupt to drive the USB RX circular buffer in the same way as the UART RX

Added SIO support and some bodges to delay the emulated interrupts to allow serial as fast as the Z80 emulation can cope with.

Using Terra term I can now drop files onto the RC2040 with only a 1ms TX delay.

Continued here

RC2040 Emulated RC2014 kit

Micro Python with ESP8266 & Oled Display

How to load a test script

After loading python on your own system

Install esptool
pip install esptool –upgrade

Install AMPY
pip install adafruit-ampy

Download ssd1306.py from https://github.com/adafruit/micropython-adafruit-ssd1306/blob/master/ssd1306.py

Plug in the board and find the Com port that is created (mine was COM4)

Download the micropython from https://micropython.org/download#esp8266
Should save as a bin file like esp8266-20171101-v1.9.3.bin

Erase the board
python esptool.py –port COM4 erase_flash

Flash the board with MicroPython
python esptool.py –port COM4 write_flash –flash_size=detect -fm dio 0 esp8266-20171101-v1.9.3.bin

Bodge the ampy package

Open /usr/local/lib/python2.7/site-packages/ampy/pyboard.py. Find line 171. Specifically go to the enter_raw_repl method:

add a time.sleep(2). So it becomes
def enter_raw_repl(self):
self.serial.write(b’\r\x03\x03′) # ctrl-C twice: interrupt any running program

# flush input (without relying on serial.flushInput())
n = self.serial.inWaiting()
while n > 0:
self.serial.read(n)
n = self.serial.inWaiting()
time.sleep(2)

Create main.py

Using a terminal open the com port and at the >>> prompt write

f = open(“main.py”, “w”)
f.write(“print(\”main.py: Hello\”)\n”)
f.close()

Write the oled Library to the board

ampy –port COM4 –baud 115200 put ssd1306.py

Create a file called oledtest.py with the following content

import machine, ssd1306
i2c = machine.I2C(scl=machine.Pin(4), sda=machine.Pin(5))
oled = ssd1306.SSD1306_I2C(128, 64, i2c)
oled.fill(0)
oled.text(‘MicroPython on’, 0, 0)
oled.text(‘an ESP8266 with an’, 0, 10)
oled.text(‘attached SSD1306’, 0, 20)
oled.text(‘OLED display’, 0, 30)
oled.show()

ampy –port COM4 –baud 115200 run oledtest.py

RPI I2C interface to Microchip embedded uP – Clock stretching

If you are going to implement I2C to an embedded uP read this first http://www.slate.com/blogs/bad_astronomy/2016/03/28/psychedelic_stroboscopic_easter_eggs.html

If you are using a Microchip uP you might want to continue reading.

Here is the problem, Raspberry Pi’s I2C software can’t cope with slave clock stretching, not a problem if you can service the data request quickly, well you would have thought not anyway. Unfortunately Microchip’s hardware (using a PIC18F14K50 and many others)  always puts in a small clock stretch for a slave transmit, even if you disable clock stretching with the SEN bit.   A thorough read of the data sheet gives you a clue “The ACK pulse will be sent on the ninth bit and pin SCK/SCL is held low regardless of SEN“.

So data transmission TO the PIC works fine (if you can deal with the I2C data quickly enough), but for Slave data transmit TO the RPI you get errors. The problem is, they are random and depend on the exact timing of the I2C bus and uP speed.

This clock stretch only happens after the address byte and before the transmission data. It causes a short or missing clock pulse (as the RPI ignores the presence of the clock held low by the slave) as in the transition of bytes 3 &4  of data in the oscilloscope capture below.

DS1Z_QuickPrint7

So how do we work around this, well to be honest there isn’t a total solution. (that I’ve found) the best that I have achieved is to change the I2C clock speed  so the timing of a clock stretch happens when the clock is already low and tweak the uP interrupt software.

The clock speed change is unfortunately a trial and error process whilst monitoring the data (and probably watching with a scope). To change the I2C bus speed with a newer PI distro, you need to edit the /boot/config.txt and edit or add the line “dtparam=i2c1_baudrate=clockspeed” try clock speeds from 20000 to 400000 and follow by a reboot of the PI to make the changes active.

The bus clock speed that will work will vary with the microprocessor speed,  so there is no single solution. With my setup 200Khz and 50Khz works well (uP clock @32Mhz) where 400khz and 100khz is a total wright off.

I have also changed the I2C code in the PIC18F14K50 to give a fast set of the  BF flag after data transmission which helps minimise the clock hold time.

if (PIR1bits.SSPIF) {
      
        if (!SSPSTATbits.D_NOT_A) {
            //
            // Slave Address
            //
            i2c_byte_count = 0;

            if (SSPSTATbits.BF) {
                // Discard slave address
                sspBuf = SSPBUF;    // Clear BF
                SSPSTATbits.BF=1;
            }

            if (SSPSTATbits.R_NOT_W) {
                // Reading - read from register map
                SSPCON1bits.WCOL = 0;
                SSPBUF           = i2c_reg_map[i2c_reg_addr++];
              
            }

        } else {
            //
            // Data bytes
            //
            i2c_byte_count++;

            if (SSPSTATbits.BF) {
                sspBuf = SSPBUF;    // Clear BF
                
            }

            if (SSPSTATbits.R_NOT_W) {
                // Multi-byte read - advance to next address
                SSPCON1bits.WCOL = 0;
                SSPBUF           = i2c_reg_map[i2c_reg_addr++];
                SSPSTATbits.BF=1;
               
            } else {

                if (i2c_byte_count == 1) {
                    // First write byte is register address
                    i2c_reg_addr = sspBuf;
                } else {
                    // Write to register address - auto advance
                    //   to allow multiple bytes to be written
                    i2c_reg_map[i2c_reg_addr++] = sspBuf;
                }
            }
           
        }//else
        
        SSPCON1bits.CKP = 1;            // Release clock
        // Limit address to size of register map
        i2c_reg_addr %= sizeof(i2c_reg_map);

        // Finally
        PIR1bits.SSPIF  = 0;            // Clear MSSP interrupt flag
      
    }   

With these changes, I have got (as the adverts say) up to 100% TX from a slave without error. This is about the best we can do until either Microchip change their hardware, or RPI write a I2C handler that supports clock stretch.