Category Archives: Microprocessors

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

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.

 

Headless Raspberry PI (PIZero) setup

The PIZero Simple setup without network or monitor. (Requires some prior knowledge of RS232 adapters and serial port setup)

First start by getting a PI SD image I used Raspian Jesse Light https://www.raspberrypi.org/downloads/raspbian/

Install into a sd card and make sure it runs (green light at least)

With a 3.3v RS232 adapter connect earth and RX/TX to your PI. Be careful some adapters are only 5V and will damage your PI’s UART pins.

PiZero

Setup your PC (I use Tera Term) serial adapter for 115200, 7 bits, even parity, 1 stop bit.

Boot your PI

If you get a screen of gobbledegook then good, otherwise swap your TX and RX around. When the gobbledegook has finished, press return a couple of times, and you should get a login prompt.

For some reason the console and boot up output at different baud rates (Caused by auto baud rate detect, settings above amended so this shouldn’t happen now)

Configure your PI the usual way. You will need some network to get your updates, but apart from that you have a working PI.

If you are brave (or idle) you can connect the +5v line from your serial adapter to power your PI too so you don’t need another usb power lead. Just be very careful that you attach it to the correct pins, otherwise your PI will be damaged.

 

Useful links.

(although I found the baud rate setting wrong everywhere I looked. Either auto baud rate detect at work, or it changes from distro to distro)

Element 14 no display using the raspberry pi serial console

RPi Serial Connection

 

Update:

The baud rate is auto detected, the native speed is 115200 (amended above) The auto detection only happens at the login prompt. The auto detection won’t pick up changes in bits/stop bits/ or parity. You can change the console getty port/speed/parity settings look at RPi serial connection above.

WiFi

If you have a wifi adapter and micro USB to USB lead, you can connect to WIFI. After connecting via RS232 edit the file /etc/wpa_supplicant/wpa_supplicant.conf using sudo nano

add in the lines

network={
    ssid="Your_WIFI_SSID"
    psk="Your_wifi_password"
}

and reboot the pi sudo shutdown -r

re log in to the pi and type ifconfig to fins the wifi IP address. 
Then you can ssh to your PI and even better update the software.

Note : for Pi 3. You may need some changes to get the headless conf working, especially at non default baudrates, take a look at http://www.briandorey.com/post/Raspberry-Pi-3-UART-Boot-Overlay-Part-Two

 

 

 

 

 

 

 

Minimus 32 Dev Board – LUFA drivers and Atmel Studio 6.1

So I bought a Minimus32 Development board from [shortlink url=”http://www.modtraders.co.uk/minimus-32-avr-usb-development-board.html” title=”Mod Traders”]

minimus32

Couple of reasons for the purchase, Its was cheap, and it had a small processor and USB support out of the box.

OK, 1 and 2 are true, 3 is a little more complex.

After trawling the internet All I found was out of date information, information on the original Minimus board, or information using an old version of Atmels IDE. Having struggled in the past with old IDE’s I decided to use the newest one and brave it out.

So, For Windows…

You can download Atmel’s latest IDE free from here [shortlink url=”http://www.atmel.com/microsite/atmel_studio6/” title=”http://www.atmel.com/microsite/atmel_studio6/”] It is a Visual Studio based IDE and looks pretty good. Unfortunately there is no support for the bootloader contained in the minimus32 board.

So to get a hex image onto the Minimus 32 you need Flip downloadable for free here [shortlink url=”http://tinyurl.com/7jqeg3l” title=”http://www.atmel.com/tools/FLIP.aspx”]

Braving the new environment I cut and pasted a demo code sample (blink )


#include <avr/io.h>
#define F_CPU 16.000E6
#include <util/delay.h>
#include <avr/wdt.h>

void init_ports(void)
{
PORTB = 0b00000000;
DDRB = 0b00000000;

PORTC = 0b00000000;
DDRC = 0b00000000;

PORTD = 0b00000000;
DDRD = 0b01100000;      // Set LEDs as output
}

int main(void)
{
MCUSR &= ~(1 << WDRF);
wdt_disable();
init_ports();

while(1)
{
if (PIND & 0b10000000) {
PORTD = PORTD & ~0b01000000;
PORTD = PORTD |  0b00100000;
_delay_ms(200);

PORTD = PORTD & ~0b00100000;
PORTD = PORTD |  0b01000000;
_delay_ms(200);
} else {
PORTD = PORTD | 0b01100000;
}
}
}

I set the uP to ATMEGA32U2 hit build and It compiled first time.

Went into Flip, loaded the .hex file and sent it to the Minmus32. After a little playing with the buttons it ran.

(Tip: to put the Minimus into “Load” mode you need to press RESET, press HWB, release RESET and release HWB, just roll your finger over the buttons)

So a USB example.

I found that you can get the latest version of the LUFA libraries from here [shortlink url=”http://tinyurl.com/mx8flmo” title=”http://gallery.atmel.com/Products/Details/47ba24a4-d17b-4fed-b244-f5998b3d789d”] and the are already formatted for Studio 6

Loaded the Libraries and tried the demo project for USB to RS232

It compiled, but wouldn’t run.

Cutting a long story short there were a number of things wrong. The Processor speed was incorrect, the target board wasn’t set correctly and the LUFA libraries didn’t contain the code specific to the Minimus32 Board.

So. to fix these.

In Atmel Studio 6, Goto Project->Toolchain -> AVR/GNU C Compiler -> Symbols

Ensure they look like this

F_CPU=16000000UL
F_USB=16000000UL
ARCH=ARCH_AVR8
USE_LUFA_CONFIG_HEADER
BOARD=BOARD_MINIMUS
USE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)"

Tesla Coil Tuner

First light of a Tesla Coil tuner.

Old TC TunerSo I needed to get a better Tesla coil Tuner. I have been using this NE555 pinger for 10+ years.

Always said I’d put it in a box.. Never happened…

With some of the tuning problems I’ve had recently I needed a better solution.

So..

 

 

 

 

 

PIC powered USB controlled Tesla Coil Tuner using AD9850 DDS Frequency Synthesis.

Built on a PIC low pin count, USB development board (hence redundant RS232 connector)

Direct connectiontctuner to the Primary Coil with current measuring.

Three ways of measuring.

Primary and cap on its own(Secondary removed)

Secondary on its own (driven by primary with no Primary cap)

Primary Cap and Secondary (across spark gap) – Should see both current dips.

 

Tesla Coil Tuner - sec only

First plot of a small Secondary coil, using VB to drive the USB.

Plots at ~15 seconds for 1000 points (e.g will scan from 500Khz to 1.5Mhz in 1khz steps in ~15 seconds.)

 

Range 50Khz to 4Mhz (with some droop at each end)

I’m having some issues getting a plot with just a primary coil, not sure why at the moment. Also my driver (tc428) is damaged, its not driving correctly to ground. Which may be causing me some issues. But not bad for a first go.

More developments

Added an Ariel input (B)

Improved the display, and removed a whole load of noise on the traces.

Also, added the ability to take snapshots of the traces (pale colours) so you can see any change from scan to scan

Tesla Coil Tuner - sec-pri
This shows a current scan in Dark blue, with a snapshot in light blue and the Ariel input in dark green with a light green snapshot. The current scan was done with my hand near the topload hence the lower resonant frequencies.

This clearly shows the primary (C & L) as a large dip on the left and the secondary / topload as the smaller dip on the right. I’m feeding the primary coil and primary cap in parallel as this gives the best indication of the current change in the primary. For some reason driving the coil with Cpri in series shows a lumped resonance (or doesn’t show the primary resonance up at all)