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.

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: