Over the last couple of weeks, I’ve spent some time working on the TCP/IP stack used by VoIP32 to handle all its network connections.  It only recently gained the ability to properly manage a relatively large number of concurrent connections, limited by available RAM.  The firmware is currently set to allow 10 simultaneous connections.  The PIC32MX340F512H has 32kB of RAM, which should be enough to support some 25 simultaneous clients.  The ~380kBps of available bandwidth is shared among all connections.

The total available bandwidth is a bit lower than expected, but is still nearly 60% higher than the available bandwidth on VoIP8.  As I write this, I am downloading a file from VoIP32 at a sustained rate of 375kB/s.  When compared with large commercial Web servers, this isn’t impressive at all; however, we must keep in mind that this server is running on an 80MHz processor with limited RAM instead of a quad-core Intel chip with gigabytes of memory.

Other tweaks added recently (but not yet fully debugged) are case corrections in filenames to support non-standard Microsoft extensions (this mostly works) and automatic TCP packet retransmission (this still needs some work).

The next steps planned are to start working on a Telnet UI for administrative purposes, a pushbutton-and-LCD-based local UI, and possibly integration with services like Pandora and Twitter.

Other things that I would eventually like to add include a bootloader for remote programming, a Unix-like Telnet or SSH interface, and the ability to execute small programs from the SD card.

First, let’s congratulate George.  He has graduated from Purdue University as of this morning, so he is now qualified to go forth to solve the world’s engineering problems.  Congrats, George!

With the end of the school year comes moving to new places, and as such, the 8-bit Web server has come out of storage.  What’s different than last time is that it now has the LED array hooked up and playing the messages that Internet users send to it.  To give it a try (and send stuff to the LED array), simply visit http://benlaskowski.is-a-geek.net:8000/.

As I will have a little more free time this summer, I intend to get the 32-bit VoIP board up and running.  I have so far made it send dummy ARP packets over the network correctly.  Complete implementations of TCP/IP and the like are a long way off, but hopefully everything will come together this summer.

Edit:  VoIP32 now supports ARP and ICMP.  Yes, these are small steps, but it shows that different buffers work properly and that I actually can correctly compute checksums in software.  In preliminary testing, the board can echo 1kB of ping data in one millisecond.  Not too shabby…

The 32-bit VoIP board can, as of tonight, play media from a microSD card inserted into the onboard socket.  This has the added bonus of demonstrating that the code segments for fragmented file handling, file name caching, SD card file searches, and cooperative multitasking all work as they should.

Right now, the handler for audio playback is the SD card filesystem reading layer.  It’s specific to audio tasks, but a bit of rewriting should make it much more general so that every task needing SD card access will be able to use it.

This means it’s time to start working on the Ethernet capabilities of the server.  This comes at a time when the semester is starting to pick up, so we’ll see how quickly this is accomplished.

I’ve spent a few hours (okay, okay, more like 20 hours) over the last two weeks working on implementing SD card support in MIPS assembler.  As of approximately 15 minutes ago, the code successfully implements some subset of the SD SPI protocol as well as FAT32.

(continue reading…)

I got the last couple of parts in for the 32-bit VoIP board, and had some time today to finish up a little soldering.

Isn’t it purdy?

(continue reading…)

Any reference to John Conway not intended.

Today I assembled a minimal subset of the components on the 32-bit VoIP board:  the processor, voltage regulators, decoupling caps, etc.  I was able to make the processor blink an LED.

I seem to be having some trouble with the PLL however.  The chip should be running at 80MHz, but seems to be running at more like 8-10MHz.  Hopefully I’ll get this sorted out reasonably soon.  Next up:  to figure out how interrupts work on this beast.

I leave you with some basic MIPS assembly:

 .ent	main
main:	li	$v0,0x00000032	#enable prefetch cache, 2 wait states
sw	$v0,CHECON
li	$v0,1<<8
sw	$v0,TRISDCLR
sw	$v0,LATDSET
1:	li	$v0,1500000
2:	addiu	$v0,$v0,-1
bne	$v0,$zero,2b
li	$v1,1<<8
sw	$v1,LATDINV
b	1b
.end	main

This code sets PORTD.8 to an output, then blinks the LED at about 1Hz with my probably-messed-up oscillator configuration.

EDIT:  I found the problem — it was NOT with the PLL configuration.  I had assumed that the instruction cache was enabled by default, but it wasn’t.  Enabling it and dialing in a lower number of flash wait states took care of the problem.  Web server at 80MIPS, here I come!

Perhaps you’ve read the original VoIP Server project article.  If you did, you probably noticed that while it works, it’s woefully lacking in processing power.  Ben noticed this, too, and set out to work on an upgrade.

The upgraded server has a 32-bit microcontroller, 10/100 Ethernet, a dedicated DSP for decoding compressed media, USB, and a switching power supply on-board.

The board does not exist yet, but here’s an Eagle3D rendering:

This project was featured on the Make Blog in October 2009.

I’ve always wanted to embed an Ethernet port onto something. This, I claim, is an Electrical Engineer’s trait. I also just like networks.

This project is, without a doubt, the most ambitious I have attempted to date. The finished product (or almost-finished product, as the case may be) has several significant subsections. Aside from the hopefully-obvious TCP/IP component and core processing circuit, there’s a file retrieval subsystem, an audio subsystem, and a user interface of sorts. We’ll explore these in (roughly) order of increasing complexity.

(continue reading…)