Gertboard

Sorry to hear about the setback, Gert.

I can only say that my own experimental expansion boards will likely contain something Atmel/AVR.

Open source toolchain (already in Debian ARM repo), lots of documentation and available libraries, clear datasheets, cheap programmers available. I'm happy.

That said, AVR is the only thing I know. So I'm biased.

It would be great if the microcontroller could be programmed without an external programmer. (http://www.raspberrypi.org/for.....-avr-chips). Other microcontrollers might be better suited in that respect. Dunno.

Hi Gert - I recommend an mbed http://mbed.org

It uses an NXP (Philips) micro with ARM Cortex-M3, lots of different I/O with drivers, and online compiler so no hassle installing tools.

Rich

MSP430 - the MSP430Gxxxx chips (like the ones used in the MSP430 Launchpad) are VERY cheap and 3.3V compatible.

[rurwin]

Another vote for the AVR. If you put the right lines on the interface (which IIRC includes the SPI lines anyway) it can be programmed from the RPi.

The PIC is an engineer's microcontroller; it has non-orthogonal instructions and low interrupt latency. The AVR is a programmer's microcontroller; orthogonal instructions, lots of registers and high latency. The PIC tends to need paid-for compilers, but the AVR is supported by gcc.

Gert, are you going to publish the board design? It seems to me it would be useful to be able to copy your buffering and interface details, and change the other stuff. For example a board with a prototyping area.

Another vote for AVR.
Connecting the reset and the SPI lines to the RPi it wouldn't require any extra equipment but a soldiering iron($10-$20) and some solder(could be included in the package?) to get it working. Ie, no programmers, no magic code pre-flashed on the processor etc. The bigger AVRs (such as mega88)  also allows you to install a custom bootloader that could be used to program over other ports. Programming over serial would probably be a hot candidate so the SPI-lines could be freed after initial programming. All AVRs comes with a builtin timing circuit that usually goes up to 8MHz even if it can be tweaked to 12MHz afaik. When operating in a 3.3V environment 12MHz is about as far up as the mega88 goes according to specs.

Writing an ISP-programmer for AVR is extremely easy. Just keep the reset low and send data over SPI. Protocol is iirc: send upload instruction + 2 bytes, send flash instruction, repeat. It's well documented and designed to be easy to implement.

Either way, no matter what processor you use, I think two things would help the student:

1. ISP-programmable without pushing any button/moving jumpers. When compilation takes sub-second, flashing takes even less than that, moving a jumper/pushing a button becomes a chore.


2. Connect the serial port of the RPi to the serial of the processor. Debuggers are expensive (especially in the RPi context) and println works very well.

-- edit: Clarified serial boot loader 

Gert said:

Any suggestions?

Parallax Propeller - up to 80MHz, 8 cores (cogs)

[Gert van Loo]

Gert, are you going to publish the board design? It seems to me it would be useful to be able to copy your buffering and interface details, and change the other stuff. For example a board with a prototyping area.

Everything about the board will go into the public domain. But the schematics are not that shocking. Very simple straightforward stuff. The PCB is the most work.

Looks like the AVR has the most votes thus far. It also looks most similar to what was there. But.. I have no experience with them so I need some support:

What is the default debugger and what connections does it require? I had a quick look at it seems to be single pin on the reset line.

What is a good RC combination for the Avcc? I was planning to connect Aref to Avcc.

I plan to post the schematic soon but will only accept corrections, not changes.

[Gert van Loo]

After a looong weekend with my schematic editor and even more hours doing PCB design I am now here:



That is REV2 with an ATmega328P. The board is shorter again as I could drop the RJ12 and I have added two small "patch" areas.

I have ordered five 328"s to play with and they should arrive Tuesday. They are also 28-pins and only power and ground differ. So it should not take long to make a simple patch socket and I can plug one in my Rev-1 instead of the PIC.

The only thing I really, really need to know is this: For PIC I use a ICD2 between my PC and the boards for debugger/programmer. What do I need for these to connect, download, run programs, step, breakpoints etc. Also what compiler/IDE should I use? If I have to buy anything I need to know ASAP otherwise it will take another two weeks before the board can go out.

You might be interested in this article:
http://www.evilmadscientist.co.....rgetboards
The USBtinyISP from ladyada comes as a kit, and has never failed me.
A Linux toolchain would consist of gcc-avr, avr-libc, binutils-avr, gdb-avr and avrdude (to upload hex-files and set fuses).
By choosing the ATMega328P you also went Arduino-compatible. I'm sure a lot of people like that.

Edit: cheapest debugger is probably Atmel's own AVR Dragon.

[rurwin]

You probably want Atmel AVR042: AVR Hardware Design Considerations

If that doesn't help, if you go to the device page on the Atmel site and hit the Documents tab there's a load of other docs, including one about the ADC.

Another design wish:

It is possible brick a 328P by setting the fuse bits wrong, particularly those involving clock source (after all, the first thing you do with an AVR is to either to zero the clock prescaler fuse-bit or change to an external clock source).

It is however possible to unbrick it by either parallell programming a chip erase (section 28.7.3 in the manual) or just send a couple TTL pulses (I usually stay on the safe side with several 100s) to XTAL1 per bit data sent over SPI (28.8). I've always used the latter, as it doesn't require 12V, but on the other hand, it doesn't help when the  ISP disable fuse has been set. Until today I've set the fuse-bits for clock wrong countless times, but never managed to set the ISP disable fuse.

Oh, and btw, THANKS. Now I won't have to reinvent the wheel and instead I'll order one Gert-board per R-Pi

Btw, "manual" is http://www.atmel.com/dyn/resou.....oc8271.pdf

-edit: added url

[Gert van Loo]

Another design wish:

It is possible brick a 328P by setting the fuse bits wrong, particularly those involving clock source (after all, the first thing you do with an AVR is to either to zero the clock prescaler fuse-bit or change to an external clock source).......

The 328P on the Gertboard does not use an external X-tal. Instead it is intended to run of it's internal oscillator. (Space and cost saving). This means the XTAL pins are brought out on the connector. So you can do the reviving trick.

Beware that it runs of 3V3 as the I/O must be voltage compatibel with the raspberry-Pi GPIO voltages. So it is not compatible with Arduino extension cards anyway!

There is one thing I am looking into: Default I was planning to connect all devices using the SPI interface. After reading the manual it seems you can not use SPI and the JTAGICE2 debugger at the same time. So you can not debug the 328P and talk to it from the Raspberry-Pi at the same time. Very, very bad

I can't use the USART in SPI mode as I need an SPI slave interface. Only thing I can think of is to talk using both UARTs but I am running out of space on the board to add the extra connections and the extra header!

do you have any dimentions for the gertboard with headers?

I took a look at the schematics and realized what you were doing. I like it! Kind of like a breadboard but without all the loose connections.

AVR are pretty nice to work with and will love 3V3 on the inputs, even if CPU is running on 5V. A 1k-10k resistor in series with the avr output should keep the R-Pi _relatively_ happy if what I've read on the forums here is true, right?

Can't you use normal serial to talk to the R-Pi instead? Easier to get started with computer-side (just minicom/cutecom) but could of course become pure hell if changing clock.

Either way, the Atmega328p seems to support debugwire(Section 25) unless I'm reading it wrong, and that uses only 1 pin (the reset pin). I can't vouch for it though, as I've never used a hardware debugger for the AVR.

tzj said:

do you have any dimentions for the gertboard with headers?

I count ~50x2.54mm width and ~35x2.54mm height

that doesn"t sound right, the r-pi is 56x85mm and the gertboards bigger.

unless... I jumped the gun n had to do math first. that would mean ~88.9x127mm which does sound about right.
only thing left is header and control indicator locations, unless the board is getting shifted round before production...

tzj said:

that doesn"t sound right, the r-pi is 56x85mm and the gertboards bigger.

http://www.vishay.com/docs/712...../71243.pdf

that's the package of the atmega328p, ie almost as high as the whole R-Pi board and if you look at the gert board schematic, it only covers not even half of the height. Btw, you did understand that I mean ~50x2.54=~125mm and ~35x2.54=~90mm, right? Each hole has center-center spacing of 2.54mm (0.1 inch), thus I just counted holes in the board.

--edit: Yes, you did understand =). This forum needs a "someone has replied to the thread. Would you like to read the reply first?" before posting

[Gert van Loo]

to said:

I took a look at the schematics and realized what you were doing. I like it! Kind of like a breadboard but without all the loose connections.

AVR are pretty nice to work with and will love 3V3 on the inputs, even if CPU is running on 5V. A 1k-10k resistor in series with the avr output should keep the R-Pi _relatively_ happy if what I"ve read on the forums here is true, right?

Can"t you use normal serial to talk to the R-Pi instead? Easier to get started with computer-side (just minicom/cutecom) but could of course become pure hell if changing clock.

Either way, the Atmega328p seems to support debugwire(Section 25) unless I"m reading it wrong, and that uses only 1 pin (the reset pin). I can"t vouch for it though, as I"ve never used a hardware debugger for the AVR.

The Raspberry-Pi is 3V3 but all the Arduino boards are 5V. (I know the 328P can work at 3V3, just not as fast)

I was trying to beat all the 'could you not give it Arduino connectors' requests. Yes I could put the connectors on, (if I extended the board another xxx mm) but still the voltage will be different so you still could not plug Arduino extension boards into it.

And yes, I now plan to talk serial to the Rapsi (Sentence which says "Only thing I can think of is to talk using both UARTs"). I just managed to get the extra wires & connector in.This also makes the CPU interface compatible with other Arduino interconnects (It seems all Arduino boards talk to the master CPU using the UART ports).

p.s. Current board is 132x84 mm exact.

Never touched an Arduino myself, mostly because it wasn't around when I started playing with AVR. Most of the stuff I want to interface with requires 5V though (Mag card reader and servos etc), so I will probably need to mod the board for 5V operation, unless the buffers are running 5V on the "outside"? I can't really follow all parts of your v2 schematic, so I'll wait for the next version.

Maybe a bit off topic, but unless I used crap LEDs, the AVRs I've used have had no problem sinking enough current to do without transistors. You could save a lot of space up there. Ofc, that was running at 5V.. Crap LEDs could still be powered, but when I used a lot, they woulld only emit a very faint glow.

Gert said:

I was trying to beat all the 'could you not give it Arduino connectors' requests. Yes I could put the connectors on, (if I extended the board another xxx mm) but still the voltage will be different so you still could not plug Arduino extension boards into it.

I don't have a clear idea of how to do this but some sort of extensible framework would allow developing Raspi specific extension boards. May be vertically stackable? Or may be this will evolve. Once a couple of different boards are built we can "refactor" the common elements into a "southbridge" sort of card : )

Gert said:

... Only thing I can think of is to talk using both UARTs but I am running out of space on the board to add the extra connections and the extra header!

"both UARTs"--can you explain that some more?  I thought there was only one UART brought out on the R-Pi gpio header.  Or have I got the wrong context?

[Gert van Loo]

lyzby said:

Gert said:

... Only thing I can think of is to talk using both UARTs but I am running out of space on the board to add the extra connections and the extra header!

"both UARTs"--can you explain that some more?  I thought there was only one UART brought out on the R-Pi gpio header.  Or have I got the wrong context?

With both UARTs I mean the UART on the Raspberry-Pi and the UART on the 328P chip.

[Gert van Loo]

This is tested code which accesses the GPIO pins through direct GPIO register manipulation in C-code. Thanks to Dom for doing the difficult work of finding and testing the mapping.

::

//
//  How to access GPIO registers from C-code on the Raspberry-Pi
//  Example program
//  15-January-2012
//  Dom and Gert
//

// Access from ARM Running Linux

#define BCM2708_PERI_BASE        0x20000000
#define GPIO_BASE                (BCM2708_PERI_BASE + 0x200000) /* GPIO controller */

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <dirent.h>
#include <fcntl.h>
#include <assert.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>

#include <unistd.h>

#define PAGE_SIZE (4*1024)
#define BLOCK_SIZE (4*1024)

int  mem_fd;
char *gpio_mem, *gpio_map;
char *spi0_mem, *spi0_map;

// I/O access
volatile unsigned *gpio;

// GPIO setup macros. Always use INP_GPIO(x) before using OUT_GPIO(x) or SET_GPIO_ALT(x,y)
#define INP_GPIO(g) *(gpio+((g)/10)) &= ~(7<<(((g)%10)*3))
#define OUT_GPIO(g) *(gpio+((g)/10)) |=  (1<<(((g)%10)*3))
#define SET_GPIO_ALT(g,a) *(gpio+(((g)/10))) |= (((a)<=3?(a)+4:(a)==4?3:2)<<(((g)%10)*3))

#define GPIO_SET *(gpio+7)  // sets   bits which are 1 ignores bits which are 0
#define GPIO_CLR *(gpio+10) // clears bits which are 1 ignores bits which are 0

void setup_io();

int main(int argc, char **argv)
{ int g,rep;

// Set up gpi pointer for direct register access
setup_io();

// Switch GPIO 7..11 to output mode

/************************************************************************
* You are about to change the GPIO settings of your computer.          *
* Mess this up and it will stop working!                               *
* It might be a good idea to 'sync' before running this program        *
* so at least you still have your code changes written to the SD-card! *
************************************************************************/

// Set GPIO pins 7-11 to output
for (g=7; g<=11; g++)
{
INP_GPIO(g); // must use INP_GPIO before we can use OUT_GPIO
OUT_GPIO(g);
}

for (rep=0; rep<10; rep++)
{
for (g=7; g<=11; g++)
{
GPIO_SET = 1<<g;
sleep(1);
}
for (g=7; g<=11; g++)
{
GPIO_CLR = 1<<g;
sleep(1);
}
}

return 0;

} // main

//
// Set up a memory regions to access GPIO
//
void setup_io()
{

/* open /dev/mem */
if ((mem_fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0) {
printf("can't open /dev/mem n");
exit (-1);
}

/* mmap GPIO */

// Allocate MAP block
if ((gpio_mem = malloc(BLOCK_SIZE + (PAGE_SIZE-1))) == NULL) {
printf("allocation error n");
exit (-1);
}

// Make sure pointer is on 4K boundary
if ((unsigned long)gpio_mem % PAGE_SIZE)
gpio_mem += PAGE_SIZE - ((unsigned long)gpio_mem % PAGE_SIZE);

// Now map it
gpio_map = (unsigned char *)mmap(
(caddr_t)gpio_mem,
BLOCK_SIZE,
PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED,
mem_fd,
GPIO_BASE
);

if ((long)gpio_map < 0) {
printf("mmap error %dn", (int)gpio_map);
exit (-1);
}

// Always use volatile pointer!
gpio = (volatile unsigned *)gpio_map;

} // setup_io

(Sorry tried post-editing to get proportional smaller font.

Not enough HTML knowledge)

Many thanks Gert.

I'm having trouble cross-compiling ( ARM and X86 ) using the Codesourcery C++ Lite gcc setup ... Any C - Posix experts in the house ?

gpio.c:100:53: error: invalid conversion from 'void*' to 'char*'
if ((gpio_mem = malloc(BLOCK_SIZE + (PAGE_SIZE-1))) == NULL) {

gpio.c:117:4: error: invalid conversion from 'unsigned char*' to 'char*'
gpio_map = (unsigned char *)mmap( .... );