PPS implemented

PPS is now implemented and tested. I uploaded to main git repository.

It can be disabled if one wishes, because it uses more LUTs than CPU core. Bootloader is now tuned to S3E eval board, new boards should arrive soon.

GPIO width was increased to maximum of 128 GPIO pins. Unused pins will be removed during synthesis.

Also I changed bootloader from C code to C++ code. This allows for template-based inlined functions for pinMode and digitalWrite, as well as other goodies that C++ can bring.

Álvaro

New features, GUI first version

A new "interesting" feature is now under development, which is PPS - Peripheral Pin Select. This feature (although a LUT eater) allows you to redirect any peripheral pin (such as UART tx/rx, SPI) to any GPIO you might wish - and you can do it in run-time. Some microchip PIC include this feature, and for boards who do not actually include external devices it's always nice to be able to plug them in any connector board might provide, and redirect things like UART and SPI there.

Changes to Arduino IDE also went well - after modifying compiler rules to use standard makefiles you can actually use that same IDE to develop and even upload your "sketch" to ZPUino. Unfortunately Arduino developers do not see this "Makefile-based" build as a good thing, let's hope they do reconsider their position - everyone wins if they do.

Álvaro

Bootloader up and running.

Looks like bootloader and programmer work OK. Still a few things to do, like retry transmission, better detection of ZPUino on startup, and implement drivers for flash other than M25P16.

But generic flash programming seems to work very well. In future, if FPGA is also using SPI for program storage we can program both (FPGA and ZPUino) from a single application (will be slower, because I'm limiting programming to 115200 baud).

Jack decided to offer me a prototype of the upcoming Papilio Overshield (It's a Spartan3E with SPI flash and voltage level converters (5v) that looks like another arduino shield). Looks very promising.

Álvaro

Redesigning bootloader and programmer

Redesigning bootloader and programmer right now. Last one was more a kind of example, and was definitely too specific for my Micron Flash. So the upcoming changes are:

• Use HDLC-like protocol, protected by CRC16. This should avoid communication errors and does not add that much overhead. In the future, it might aswell be compatible with my SerPro library (full RPC).
• Remove specifics from bootloader, move them to programmer. Programmer should be able to identify the flash chip, and choose correct operations accordingly. Page sizes and block sizes differ a lot between flash manufacturers, so the only native operations in bootloader should be READ_FAST, READ_STATUS and READ_JEDEC_ID. All other operations can be issued by programmer in a "generic" way.

Other changes include bootloader identification, flash offset (this one hardcoded in bootloader), and others I see fit while I perform implementation and testing.

Álvaro

New forum

Jack Gassett, from Gadget Factory, was kind enough to create a Forum on their website.

http://www.gadgetfactory.net/gadgetforum/index.php?board=20.0

Thanks Jack!

Memory... is never enough.

Low-end (or mid-end) FPGA do not include that much Block RAM as one might wish. For example, XC3S250E has 27KB of Block RAM, XC3S500E includes 45KB. Looks like a lot of RAM for a micro, that is for sure, but do not forget that these do not include any kind of FLASH memory for program storage. So you'll end up using most of this RAM to store program code.

Using an external SPI flash ROM is interesting, but its speed does not allow for fast execution. So I decided to write a small, direct-mapped instruction cache (1KB, 32-byte line size). It's meant to be small and interoperate well with at least alzpu core (zpu classic core, since uses a non-pipelined approach suffers from 1-clock cycle delay, might not be acceptable).

Let's see how it goes.

Some music ?

I just tested a "test" application which outputs raw 16-bit unsigned data to SigmaDelta (stored in SPI flash). This data was the left-channel of Helloween's "Handful of Pain", clipped to a few seconds.

Then I connected a simple low-pass and DC filter to output, and connected one headphone.

And I heard the music very well :) Next time I'll try with a SD card, flash is too small for raw music.

Output frequency was 44100Hz, like CD. SigmaDelta outputs at 50MHz. That means an oversampling of 1133. Should be enough for any filter to settle down.

Álvaro