Gertboard

Gert said:

In due time all will be revealed. I think I should release a simple block diagram.

Can't wait - however from what I've read here so-far, I think it's going to be really easy to get my own stuff going - via serial interface. As long as I can put my micro kernel into the Atmel chip life will be great - and I've no issues programming a blank chip either. (Is it coming with a chip, or shall I get one in anyway? Actually, I might just get another chip or 2 as I've been meaning to for my own stuff too)

Now if only I had one & a proper RPi to play with, but my Arduinos and QEMU will have to do for now...

Cheers

Gordon

[texy]

texy said:

Can you confirm how the comms are carried out between the arduino chip and the pi?
Also earlier on it was stated that there is no i2c, but the arduino doe support i2c.
Are the gpio lines for the target project to/from the pi or the 328p or both?
Obviously we are keen to see the circuit, pi software and also the 328p software as well

T.

All interface signals come out on headers. So you can connect the Atmel chip using any interface you like by making connections. The UART headers Rx/Tx of each chip are adjacent so they are the easiest to connect.

When I said noI2C I meant the Gertboard itself is not using the Raspberry-Pi I2C interface, nor does the board bring the I2C pins through any buffer/protection system. You can still access the GPIO0/GPIO1 lines directly to use them as I2C. Also you can use the Atmel I2C interface. If you want you can connect those headers and have the two devices talk to each other using I2C.

"Are the gpio lines for the target project to/from the pi or the 328p or both?"
Sorry I don"t understand the question.

In due time all will be revealed. I think I should release a simple block diagram.

What I meant was that the pi has a certain amount of gpio lines, but also that the 328p has a certain amount also. Will the 328p be configured as such that "unused" lines can be pulled high or low is set as outputs by the pi?
Thanks so far!
T.

[texy]

GordonH said:

Technical details:

I'm intersted in learning more about the GERTboard at the bit-twiddling level!

I've done a lot of work on Arduinos and I've just put together a little "remote control" system to poke data to/from an Arduino over the (USB) serial line - so any Linux PC can talk to an Arduino (nothing new there), but via my little Library which emulates most of the Arduino "wiring" system - so a program running on the Linux host (and that'll be an RPi when I get my hands on one!) can do stuff like:

pinMode (2,1) // Pin 2 to output

digitalWrite (2, 1) // Pin 2 on

x = analogueRead (4) // Read analog input 4

and so on. This mimics code running natively on an Arduino, but in my case, I'm doing it from C and my BASIC on a Linux host, talking via USB/Serial to the Arduino.

So the idea I have is to extend it to being able to use the same system to poke the GPIO directly and noddle bits and stuff on a GERT board - add in an abstraction layer and off you go:

arduino = drcOpen ("/dev/ttyUSB0")

pinMode (arduino, 2, 1) // Pin 2 on the Arduino to output

digitalWrite (arduino, 2, 1) // Set pin 2 ON on the Ardunio

gpio = drcOpen ("GPIO")

pinMode (gpio, 3,0) // Pin 3 on the GPIO to input

y = digitalRead (gpio,3) // Read the state of pin 3 from the GPIO

gert = drcOpen("GERT")

pinMode (gert, 5, 2) // Set pin 5 on the GERT to PWM

digitalWrite (gert,5,1234) // Set the PWM coutner to 1234 on pin5 on the GERT

You get the drift. (hopefully!) So the essence is that from one high-level language there is a common interface to Arduino(s) over the USB serial line (or in-fact anything over the serial line that talks my 'drc' protocol), or directly to the on-board GPIO, or via the GERT board (who's interface I've yet to find out about!)

So the stuff I'm interested in is knowing the low-level interface between the RPi and the GERT, and also the possibility of putting my own software directly into the Atmel chip on the GERT (since it's the same chip as Arduinos?)

An example in BASIC - my Arduino test board has 10 LEDs connected to pins 2 through 11 (pins 1 & 2 are reserved for the serial line):

  100 ard = DrcOpen ("/dev/ttyUSB0")
110 FOR pn = 2 TO 11 CYCLE
120   PinMode (ard, pn, 1) // Set to output
130 REPEAT
140 //
150 FOR pn = 2 TO 11 CYCLE
160   DigitalWrite (ard, pn, 1)
170   WAIT (0.2)
180 REPEAT
190 FOR pn = 2 TO 11 CYCLE
200   DigitalWrite (ard, pn, 0) // Turn off
210 REPEAT
220 END

So that lights up the LEDs, one at a time, then turns them all off more or less instantly.

When I get some time I'll be publishing all this (GPL), so someone can take the C libraries and apply them to Python or whatever they want to (Python's not really my thing) the actual protocol down the serial line is very simple - 2 bytes to set a bit, 4 bytes to set a PWM value and 4 bytes (2 out and 2 in) to read an analogue port, so super-fast it's not going to be but at 115200 baud, it's over 5000 bit set/resets a second and over 2500 analogue reads a second (which is actually faster than the arduino can handle)

So, GERT board technical details please

Gordon

One of my Arduino test-beds:

This is the kind of stuff I would also like to do, so looking forward to your published code. I have built a few arduino projects of my own, but am a Linux newbie. I am also keen to learn Python, and disappointed that the hardware level coding has so far been done in C, and not the prefered RPi programming language, however there may be technical reasons why C has had to be used.

In the mean time I have dedicated a spare hard drive in my main PC and installed Debian on it to play around with. Which Basic are you using, so I can play with your code?

Texy

texy said:

This is the kind of stuff I would also like to do, so looking forward to your published code. I have built a few arduino projects of my own, but am a Linux newbie. I am also keen to learn Python, and disappointed that the hardware level coding has so far been done in C, and not the prefered RPi programming language, however there may be technical reasons why C has had to be used.

In the mean time I have dedicated a spare hard drive in my main PC and installed Debian on it to play around with. Which Basic are you using, so I can play with your code?

Texy

I wrote my own BASIC... (In C). I'm in the process of tidying it up and will publish it all under GPL soon - and provide binary Debian packages for both i386 and ARM.

The Arduino interface is all done & tested now too, so Basic & C programs can poke commands at my Arduino and it then emulates the Arduinos 'Wiring' library to do things like DigitalWrite, AnalogueRead and so on. And if I have interpreted correctly what I've seen of the Gertboard and Gerts postings here, then I think I have a pretty good idea of how I can integreate that into my system too in a fairly seamless manner. My plan is to publish all my Arduino code too, however I don't use the Arduinio IDE, so will publish HEX files for the images for those that can't compile it the old-fashioned Makefile way!

I don't see why my libraries won't be callable from other languages too - but I've no idea (nor not much interest) how Python does it all, but I'm sure it's fairly easy to integrate a new function or Library (written in C) into Python if needed - and that function can be written in some language that does allow hardware access, so GPIO access from Python ought to be very possible. (And I'm sure Serial port access is already supported)

Actually, thinking about it now, it probably wouldn't be too hard to write a Linux device driver for it all, then simply open the device and send controls to it in a fairly standard manner - do-able from most high level languages including Python, I'd have thought. I don't have the resorces at the moment to do this though - maybe when I get hardware myself though.

A quick piccie of a BASIC test program, talking to an Arduino:



the bar-graph at the bottom is reading a potentiometer, showing it set to 26%, the circles are the buttons - the blue one was pressed, temperature is from an LM35 on an analogue input. The program also updates the potentiometer on a set of LEDs on the board itself (see an earlier post for a picture of the test board).I must investigate videos - one of these days!

If you want to look at the BASIC program that generates this, then it's http://unicorn.drogon.net/ardu3.rtb.txt

Gordon

There are already high level methods of using GPIO from the Linux filesystem. I have also written a Python module for GPIO access. A search of this forum will reveal much more detail about this than I will repeat here.

[jamesh]

texy said:

This is the kind of stuff I would also like to do, so looking forward to your published code. I have built a few arduino projects of my own, but am a Linux newbie. I am also keen to learn Python, and disappointed that the hardware level coding has so far been done in C, and not the prefered RPi programming language, however there may be technical reasons why C has had to be used.

In the mean time I have dedicated a spare hard drive in my main PC and installed Debian on it to play around with. Which Basic are you using, so I can play with your code?

Texy

TBH, C is a better language for controlling hardware than Python (IMO) - its much closer to the HW for a start, and is much faster.

That's not to say you shouldn't use Python if you want, but it's just not the best tool for the job when you are talking HW. Although it does depend on the job!

croston said:

There are already high level methods of using GPIO from the Linux filesystem. I have also written a Python module for GPIO access. A search of this forum will reveal much more detail about this than I will repeat here.

I think it's worthwhile repeating - seriously. Otherwise we're going to end up with lots of poeple doing lots of different things - mostly because searching this forum and trying to keep up with old posts is not the easiest of things to do. (I can't find your postings for example and the prospect of re-reading 12 pages of posts in this thread and who knows what elsewhere doesn't fill me with joy - if only I could search on author... )

I'd actually like to see a standardised "built-in" way to access the GPIO - perferably via a device entry like /dev/gpio using open/read/write/ioctl/close rather than lots of different libraries... It's all very good to use /dev/mem, but that needs root access and get it wrong and you might as well be poking random data into an old 8-bit micro... And if /dev/gpio doesn't already exist, then I'll write one as soon as I get hardware.

Gordon

JamesH said:

texy said:

This is the kind of stuff I would also like to do, so looking forward to your published code. I have built a few arduino projects of my own, but am a Linux newbie. I am also keen to learn Python, and disappointed that the hardware level coding has so far been done in C, and not the prefered RPi programming language, however there may be technical reasons why C has had to be used.

In the mean time I have dedicated a spare hard drive in my main PC and installed Debian on it to play around with. Which Basic are you using, so I can play with your code?

Texy

TBH, C is a better language for controlling hardware than Python (IMO) - its much closer to the HW for a start, and is much faster.

That's not to say you shouldn't use Python if you want, but it's just not the best tool for the job when you are talking HW. Although it does depend on the job!

As an old C programmer I have to agree, but sometimes I think you need something that's a bit more "entry level" and produces more instant results. I think this is how the Arduino (and clones) have managed to take-off and be so successful, and although I'm not a fan of their IDE it has made it easier for a lot of people to get intersted.

The entry-level in my Basic to light an LED on an Arduino (from a Linux host) is:

x=drcopen ("/dev/ttyUSB0")

pinmode (x,13,1)  // Pin 13 to output mode

digitalwrite (x,13,1)

(pin 13 on an Arduino is the on-board LED, so no additional hardware required)

It's still a lot of typing just to light up an LED, but letting someone see an LED light up from their own actions might not seem pretty fantatic, but it might just be enough to get them intersted in some sort of programming, etc. then once hooked, introduce them to higher (lower) levels of control...

From what I can gather, the GERT board is 2 things; an IO board for the RPi with (I guess) bufferd IO and some A/D and D/A and some LEDs and buttons on-board, and an Arduino (well AVR) chip with all it's IO capabilities too. My aim would be something like:

y=drcopen ("/dev/gert")

pinmode (y,2,1)

digitalwrite (y,2,1)

assuming pin 2 was connected to an LED on the GERTboard...

But who knows!

Gordon

GordonH said:

I think it's worthwhile repeating - seriously.

OK then. A quick search reveals this thread (it is in several more) -->

http://www.raspberrypi.org/for.....pio-module

GordonH said:

I'd actually like to see a standardised "built-in" way to access the GPIO - perferably via a device entry like /dev/gpio using open/read/write/ioctl/close rather than lots of different libraries...

You mean like /sys/class/gpio ? This is already part of the kernel.  BTW this is what the Python module uses.  This is what Gert's original C code used before it was changed to /dev/mem in the wiki.  For an example of how to use this, look at the Python module source code.

As JamesH said a few posts earlier, choose your language carefully and use the correct tool for the job.  C is going to be faster and more predictable than Python where high precision switching is required (real time).

croston said:

GordonH said:

I think it's worthwhile repeating - seriously.

OK then. A quick search reveals this thread (it is in several more) -->

http://www.raspberrypi.org/for.....pio-module

GordonH said:

I'd actually like to see a standardised "built-in" way to access the GPIO - perferably via a device entry like /dev/gpio using open/read/write/ioctl/close rather than lots of different libraries...

You mean like /sys/class/gpio ? This is already part of the kernel.  BTW this is what the Python module uses.  This is what Gert's original C code used before it was changed to /dev/mem in the wiki.  For an example of how to use this, look at the Python module source code.

As JamesH said a few posts earlier, choose your language carefully and use the correct tool for the job.  C is going to be faster and more predictable than Python where high precision switching is required (real time).

Thanks. It's stuff like that which I've found hard to find - possibly because I only really started to pay attention once I could order hardware, so I've missed 6 months worth of postings... Searching for python gpio driver - much different from searching for python gpio module! I had found the /dev/mem interface, but /sys/class/gpio is new to me... (Obviously not new to people developing systems with GPIO, however I have used /sys/class/leds on my ALIX systems, so maybe I should have guessed!) Right now, I think there is currently too much in too many places and the learning curve still somewhat vertical... Hopefully that'll change in time. The wiki is a start, but it's still a bit thin in places.

So - /sys/class/gpio - very high level access but possibly not the fastest - can be used from the shell command line!

/dev/mem - very low level (& root privs) access and very high speed - usable from a C program, but has the potential for letting you shoot yourself in the foot and produce the Linux equivalent of the BSOD (or worse)

I still think there's space for a /dev/rpi type interface - allow it to validate your access from userland and still let you mmap the actual hardware and poke it directly from C...

My interests are making it accessable in a relatively efficient manner from a C program (and therefore my Basic system as it's written in C) and I don't particularly want to run a language interpreter as root or SUID...

Cheers,

Gordon

Great video on the gertboard!

Excellent work...should be an excellent piece of hardware.

The supporting code looks very good too.

Let me know if you want any details/specs added to the wiki!

Will it be CE tested?

I'll get my coat.

Yurp...ya C E over terr...da tis tut Gert board...

[Gert van Loo]

Grumpyoldgit said:

Will it be CE tested?

I'll get my coat.

No. In contract to the Pi which can be seen as a complete end product, the Gertboard is clearly a lab/experiment system and as such doe not require CE testing.

How do we get hold of one of these boards?

[texy]

You wait until the design is finalised, Gert orders the bare pcb"s and they get delivered, and he approves them. I think it was mentioned that they will be sold via the foundations "shop" page.
Texy

The shop has been "down for maintenance" for some time so hard to tell what would be available.

Yea they said the shop was coming back sometime this month ™ ... it probably will when the forums get updated etc...

[Gert van Loo]

nemmi69 said:

The shop has been "down for maintenance" for some time so hard to tell what would be available.

The boards will take at least 4 weeks to arrive so I assume the shop to be open by then.

[abishur]

Gert said:

nemmi69 said:

The shop has been "down for maintenance" for some time so hard to tell what would be available.

The boards will take at least 4 weeks to arrive so I assume the shop to be open by then.

Just a reminder to anyone who randomly reads this thread without looking at the title, he's talking about the gertboards not the R-Pi boards

[Gert van Loo]

I followed Rurwin's advice and added a BSD header but with the "no rights reserved text".

So I have a ZIP file with the Gertboard demo software. No all I need is a suggestion where to upload it to.....

To the Wiki?

http://elinux.org/Special:Upload

[Gert van Loo]

naicheben said:

To the Wiki?

http://elinux.org/Special:Upload

It won't let me.

I keep gettng an error message: "Files of the MIME type "application/zip" are not allowed to be uploaded."

There are only .c/.h files in there and a Makefile. It also refuses if I omit the makefile.

Can't you get the admins of this area to put it online in the same manner as the Linux images?

Or Dropbox?

However, I run a small hosting company - if stuck email it to me and I'll stick it online at least temporarily until you can find a more permanent home for it all, although I'm sure there is no rush since hardware is still 4 weeks away!

(I'm more intersted in a block diagram though

Gordon@drogon.net

Will the surface mount resistors come pre-installed on the board or will we need to have a reflow oven to place them ?