Qix.Synth.Net

Hey everybody! I got my 5253 and SoundBite last week, so it’s just like Christmas around here!

I plan to concentrate on the Board Support Package, but of course I also want to get into some DSP coding at some point. My main interest is getting the controller working with all the peripherals - I’m quite interested in the CAN architecture for internal communications and in using the ethernet connnection for external command and control. I want to see if we can allow new applications to be uploaded via both ethernet and SD card…

I’ve got a simple case layout in mind - I’m going to house both of these boards in one case with a display and controls on the outside. That way I won’t have to worry (as much) about handling everything.

More soon, Doug

I managed to crack getting an external file system mounted tonight!

It seems the 5251 linux BSP doesn’t support IDE or CDROM devices <DOH!> , so next place to attack was a USB filesystem.

OK, it turns it this was a lot easier than I had anticipated, though the answer was found in the 5253 quickstart guide, not the 5251 evualtion board guide, nor the notes for the BSP.

you just need to type

insmod /lib/modules/2.6.17.7-uc1/kernel/drivers/usb/host/ehci-hcd.ko

(My appologies for the word wrap n the above line. It should, of course all be on one line)

You can see it start the module and scan the USB bus. Here in lies the first catch, it seems that some things just don’t work. My cheap, no-name, 1G flash disk just wouldn’t start. the messages showed ‘device not recognized’ and it would go no further. Luckily I had a USB SD card reader module and a couple of SD cards. Bingo, that worked a treat.

Then you just need to mount the device, it my case the output of the insmod command showed it had mounted the drive as sda1, so we just do the following ;-

mkdir /tmp/usbdisk
mount /dev/sda1 /tmp/usbdisk

I can now read and write to an SD card on the 5251, what this means is that I can develop and compile code on my laptop, pop it onto an SD card and run it on the 5251 dev board.

I know to a lot of people this must seem trivial, but for me, as relative newby to linux, I’m really pleased with this. They say it’s the simple things in life that make you happy, and mounting a USB memory card onto an embedded micro running uClinux has made me quite happy.

But now the fun really starts! I can start working on the code to handle the panel interface, MIDI and connection to the DSP.

Well, I cracked it. I now have the 5251 running uClinux sending data to the panel. It seems I had made a mistake with panel code, in that I was disabling interupts, and hence the reading of the serial port, whilst writing to the LCD, so at high speeds, I was missing characters.

These pictures below were taken with the speed of the serial port on the 5251 and the panel running at 115200 baud. I’m just putting the finishing touches to the protocol which will be used to communicate between linux and the panel. From there we can start adding poteniometers, LEDs and rotary encoders!

Well, I thought I’d make a start with the part I’m most familiar with, the UI. For the moment I’m going to be working around the idea of something like this ;-

So I cobbled together a small AVR based LCD controller and a serial port input. The code displays on the LCD what it receives from serial. Which for the moment ought to be enough for testing. Ultimately the data will be passed from the user app -> the host OS (Linux) then to serial and into the panel where it will be decoded. and either sent as a MIDI out or displayed on the panel (or LED lit).

I’ve not got the Freescale 5253 Linux BSP into flash, so the only thing I need to do to get it to boot now is to type gfl which starts it. no more 20 minute downloads!

Next I soldered a 10 way connector to my 5251c3 board and hooked up a link from the TX of UART1 to the RX on the AVR. Then I configured TTY1 in this way - stty -F /dev/ttyS1 57600 cstopb

Then I sent a directory listing to tty1, ls -la > ttyS1, and got stuff on the LCD, but not the correct thing. A bit of investigation reveals the only way I can get reliable comms from the coldfire to the AVR is if I set the baud rates to 4800! pish!

So I’ve been experimenting with some level converters, the coldfire is 3.3v and the AVR is 5v. My theory being that the signal at 9600 baud and above isn’t of a sufficient level/quality to be read reliably by the AVR. So far my efforts have failed. When I get another chance I’ll dig out a transistor and build a simple level shifter.

The other, now minor, irritation is that I can’t set a non standard baud rate in Linux. The micro because of its 16Mhz clock, gives me an error rate of 3.7% for 115200 baud, but at 62500 baud (double midi speed) gives me an error of 0%. it could also be this error (0.2% at 4800) that is causing the AVR to only receive reliably at 4800 baud.

I’ve been thinking about the design and how best to implement QiX to make it easy for people to develop and yet still keep it as open as possible.

So, I’ve done a little powerpoint presentation and saved the two pages as PNGs in the Gallery.

First is the basic interconnect drawing :-

 As you can see I’ve tried to keep things as simple as possible. MIDI is going to be passed to the front panel (with it’s embedded micro), this will then be merged with the front panel data, have the baud rate upped and then passed to the ColdFire via a serial link.

 The ColdFire is running Linux and controls the whole affair. There will be a serial port link to the ColdFire and also USB OTG. The ColdFire is responsible for controlling the DSP, again via a serial link, but this time a slightly faster SPI link.

 So how do we get it to boot? Here’s what I propose :-

 Fairly straight forward, ColdFire boots a Linux Kernel, It then checks the SD card. If it finds the correct files, it loads the DSP code into the DSP and runs the app in Linux, which controls the panel and handles the MIDI stream from it.

 By using this method all a developer has to do is compile/build their app, copy it to SD, plug it in and boot it up. No downloading via MIDI! In theory it also allows for a simple ‘menu’ system to be created as an app and select from a range of apps stored on the SD card.

Well, My SoundBite Board arrived. Not had a chance to do much yet, but damn, it’s small!

It’s got 3 mono stereo inputs, and 3 mono stereo outputs, in addition to a fourth stereo in and out (which are also optical). There’s a bunch of LEDs some switches and an expansion header for connecting to the soutside world. It seems that I2C commincation should be possible with something like an AVR, so I should be able to get MIDI into it… ooo, what fun!

I should be able to get some time with the soundbite this weekend, I intend to run through the demos and just familiarise myself with it for the moment. And also look into the I2C interface a little deeper, this could be the clue to getting it to talk to the 5251evm board.

Well now, that wasn’t that hard was it?

Well actually yes, and no. Originally I tried to get Linux on my coldfire board (5251) and I discovered I needed a new dbug monitor version, I thought I’d uploaded it correctly and hosed my debug monitor.

Thanks to a friend, I received a PNE USB Multilink programmer, which let’s me reflash the flash with anything I want (yay!), including a new version of the debug monitor. So, that done. I set about getting linux into the coldfire.

Now the instructions say I can do “dnfl 0×20000″ which tells it to download it, then flash it, perfect. Except it doesn’t work. It downloads it but gives an error saying it can’t flash it, humph. Now this might be because the only debug monitor I could find online was for the 5253 Evaluation board, and mine is the 5251 board. The main difference is the lack of ethernet and the addition of audio ins and outs.

Not to give in, I decided to try a straight ‘dl 0×20000′ which just downloads it to ram. you then type ‘go’ and off you jolly well. And guess what, it worked !

booted up, dropped me at a nice # prompt.

Here’s what dmesg had to say ;-

# dmesg
Linux version 2.6.17.7-uc1 (mattw@kea) (collect2: ld returned 1 exit status) #1 Thu Mar 1 16:27:22 MST 2007
uClinux/COLDFIRE(m5253)
COLDFIRE port done by Greg Ungerer, gerg@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
On node 0 totalpages: 4096
Normal zone: 4096 pages, LIFO batch:0
Built 1 zonelists
Kernel command line: rootfstype=romfs
PID hash table entries: 128 (order: 7, 512 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory available: 13532k/16384k RAM, (1052k kernel code, 225k data)
Calibrating delay loop… 92.56 BogoMIPS (lpj=462848)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
USB-MCF5253: (HOST module) EHCI device is registered
USB-MCF5253: (OTG module) EHCI device is registered
USB-MCF5253: (OTG module) UDC device is registered
USB-MCF5253: (OTG module) ULPI device is registered
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
io scheduler noop registered
io scheduler cfq registered (default)
Generic RTC Driver v1.07
ISA-Philips-Basic-CAN memory mapped CAN Driver 3.0_ColdFire_FlexCAN (c) Mar 1 2007 16:26:21
ColdFire internal UART serial driver version 1.00
ttyS0 at 0×100001c0 (irq = 154) is a builtin ColdFire UART
ttyS1 at 0×10000200 (irq = 155) is a builtin ColdFire UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
uclinux[mtd]: RAM probe address=0×15f6f4 size=0×143000
Creating 1 MTD partitions on “RAM”:
0×00000000-0×00143000 : “ROMfs”
uclinux[mtd]: set ROMfs to be root filesystem
MCF5253EVB flash device: 200000 at ffe00000 Partition number 3
MCF5253EVB Flash Map Info: Found 1 x16 devices at 0×0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0×0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on “MCF5253EVB Flash Map Info”:
0×00000000-0×00030000 : “dBUG partition”
0×00030000-0×00040000 : “Date partition”
0×00040000-0×00200000 : “Kernel partition”
MCF5253EVB flash device initialized
QSPI device driver installed OK
ColdFire QSPI (at 0×000c9e6a) called request_irq without a dev_id!
MCF5253 QSPI driver ok
usbmon: debugfs is not available
Initializing USB Mass Storage driver…
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
NET: Registered protocol family 1
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 48k freed (0×137000 - 0×142000)
WARN: Real-time clock power loss.
Date information may be corrupt!
WARN: Real-time clock power loss.
Date information may be corrupt!
#

Cracking stuff! And just for completeness here’s some other extracts ;-

#uname -a
uClinux (none) 2.6.17.7-uc1 #1 Thu Mar 1 16:27:22 MST 2007 m68knommu unknown

# cd /dev
# ls
audio input mtdblock0 ptyp4 random sdc1 ttyp6
audio1 ipsec mtdblock1 ptyp5 rom0 sdd ttyp7
can0 kmem mtdblock2 ptyp6 rom1 sdd1 ttyp8
can1 log mtdblock3 ptyp7 rom2 shm ttyp9
console loop0 mtdblock4 ptyp8 rom3 tty ttypa
cua0 loop1 mtdblock5 ptyp9 rom4 tty0 ttypb
cua1 md0 mtdblock6 ptypa rom5 tty1 ttypc
dsp md1 net ptypb rom6 tty2 ttypd
dsp1 mem null ptypc rom7 tty3 ttype
event0 mtab ppp ptypd rom8 ttyS0 ttypf
fb0 mtd0 psaux ptype rom9 ttyS1 urandom
hda mtd1 ptmx ptypf rtc ttyp0 zero
hda1 mtd2 pts qspi sda ttyp1
hdb mtd3 ptyp0 ram0 sda1 ttyp2
hdb1 mtd4 ptyp1 ram1 sdb ttyp3
i2c0 mtd5 ptyp2 ram2 sdb1 ttyp4
image mtd6 ptyp3 ram3 sdc ttyp5

# df -k
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/rom0 1289 1289 0 100% /

# ps -aux
PID Uid VmSize Stat Command
1 root SW init
2 root RWN [ksoftirqd/0]
3 root SW< [events/0]
4 root SW< [khelper]
5 root SW< [kthread]
6 root SW< [kblockd/0]
7 root SW< [khubd]
8 root SW< [kseriod]
9 root SW [pdflush]
10 root SW [pdflush]
11 root SW [kswapd0]
12 root SW< [aio/0]
13 root SW [mtdblockd]
57 root SW /sbin/syslogd -n
60 root SW /sbin/klogd -n
86 root SW -sh
101 root RW ps -aux


The next Challenge is going to be getting it into flash and booting when I switch it on, rather than waiting the 15 minutes to download it via serial port! From there, getting the second serial port (ttyS1) to work so I can use that for Midi. Then finally getting it to look at the SD card so I can use that to load apps. I’d also *really* like to get it to boot from SD, but I suspect that’s a way off yet.

Anyway, for now, Linux is running!

 Well, finally we’re here.

We have a forum that is up and ready for people to use, this blog and a lot of interest on the SynthDIY mailing list about the sound bite board.

My hope is to build a box that let’s me take what the Chameleon started and take it several levels higher by adding a lot of the extra functionality that would have made it a killer module.

The Project is being helped along by ‘T’ and ‘J’, who for the moment need to remain anonymous. When the time is right I’m sure they will introduce themselves. But for now, why not Join the forum and get started.

Paul