Some updates, new boards

Some updates were pushed, most regarding the new Papilio One Board I received today (Jack: thanks again for the prototypes).

Simulator should also work now perfectly, I found some issues with endianness which are already fixed.

The Arduino IDE is also now able to program the simulator directly from IDE. It's very nice.

I'll focus on new boards from Gadget Factory, the Papilio One and the Papilio Uno :) Pretty confusing, but one is a standalone board and other is meant to be used as an Arduino Shield.

So far ZPUino uses 60% of low-end Papilio boards - this does not mean that it can only grow 40% more, means that after 100% we might need to slow down speed to use otherwise unused resources (ask me for clarification if you never heard of related logic packing).

Álvaro

Social Networks Update

You can now find ZPUino in Twitter and Facebook.

Enjoy the news updates! :)

Also a new web page is on the forge, I hope to upload it soon.

Álvaro

UI for ZPUino

Just forked Arduino UI and added specifics for ZPUino. Should work to some extent (some changes still required due to PPS).

You can get it here: http://github.com/alvieboy/ZPUino

Álvaro

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