Geekport support in Haiku?

So, since Bebox had the cool Geekport, and BeOS supported it, does Haiku support a special port like this and in a similar manor?

Or is Geekport gone for good?

Kind of like the new AmigaOne X1000 coming out has special access to XMOS, kind of to me a geeky port accesible for folks to tinker with, similar idea.

Would be cool if Haiku had something like this.

TJ

The questions would be:

  1. Does anyone have any devices that plugged in to the 37-Pin DIN?
    If not, then you could make your own 'new' port
  2. Is there software on the BeOS/Haiku side to monitor the port?
    If not, then you don't need to worry about legacy software and drivers.
  3. If there is a need for the 37-pin DIN original port, then I imagine someone could write a new driver to talk to a newer card via pci-express/usb/pci/ISA?
  4. Why do this via an internal card when you could now use USB?
  5. If there was already software on Haiku/BeOS for the Geekport, one could re-write the driver to talk to an arduino over USB instead?

From the above, you could recreate it all… you could even build an ‘external geekport’ that had an Arduino microcontroller and the 37-pin DIN to allow existing hardware to still connect.

The question would be ‘What does everyone want?’

I, for one, would love to see the Arduino supported on Haiku, but I believe that has already been achieved; via avrdude anyway, just no GUI via java.

Meanwhile, some references:

Arduino would be the modern day equivalent to the Geekport, in fact it would probably be a much more popular solution than the BeBox’s port ever could have been.
Also if OpenJDK gets ported, you’d be able to get the java GUI up and running.

Yeah I pretty much had the same thought regarding using an Arduino instead of needing a GeekPort. It’s a neat idea but other newer ideas (like Arduino) have superseded it.

As for the Arduino Java GUI, it would probably be less work to make our own Arduino IDE than to port Java just to get that running. From what I’ve seen though, it isn’t really all that special. You need to be somewhat technical to be doing Arduino hacking, so I don’t see why a dumbed down IDE is needed.

I know for ROS (Robot Operating System) software which I’ve been using on a project you can just build it with cmake so an IDE setup to use cmake with the right headers could work… I think you can just copy alot of it right out of the regular arduino IDE installation

I like the idea of geekport. Allows people to make their own hardware electronic thingies with the power of a whole computer to do the boring and/or interesting bits.

I for one would love to get this working.

IIRC didn’t someone have java working (including netbeans)… Looncraz?

It won’t take much to get this working, first we need to be able to recognize the ATMega microcontroller as a serial port; doing that will help a ton. if we can get this working then most of the programmed controllers can be addressed through the serial port.
After that it would just take someone to figure out the “write” portion of the code from Atmel, well for that also the read portion… and the compiler… most of this should be well documented from what I’ve seen…

now for my motive :slight_smile:
This will also get my blinkenlights working (I’ve made a custom USB driver, but it doesn’t work well if you switch ports… eventually I’ll be able to get this working right, but I’d like to have it where the arduino support is wider than my device).

If only I had more than 20 minutes a week to work on Haiku :slight_smile:

Just tried compiling avrdude version 6.0.1 mostly went well… anyone want to make a BEP file?
~/Desktop/avrdude-6.0.1> ./configure --prefix=/boot/common && make && make insta
ll
checking build system type… i586-pc-haiku
checking host system type… i586-pc-haiku
checking target system type… i586-pc-haiku
checking for a BSD-compatible install… /bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking whether make supports nested variables… yes
checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… conftest
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking whether gcc understands -c and -o together… yes
checking for style of include used by make… GNU
checking dependency style of gcc… gcc
checking for a sed that does not truncate output… /bin/sed
checking for bison… bison -y
checking for flex… flex
checking lex output file root… lex.yy
checking lex library… -lfl
checking whether yytext is a pointer… yes
checking for -ranlib… no
checking for ranlib… ranlib
checking for -ar… no
checking for ar… ar
checking whether yylex_destroy is generated by flex… version 2.5.35 => yes
checking for tputs in -ltermcap… no
checking for tputs in -lncurses… no
checking for readline in -lreadline… no
checking for elf_begin in -lelf… no
checking for library containing gethostent… no
checking for library containing setsockopt… -lsocket
checking for usb_get_string_simple in -lusb… no
checking for libusb_init in -lusb-1.0… no
checking for libusb_init in -lusb… no
checking for ftdi_new in -lftdi1… no
checking for ftdi_usb_get_strings in -lftdi… no
checking pthread.h usability… yes
checking pthread.h presence… no
configure: WARNING: pthread.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: pthread.h: proceeding with the compiler’s result
checking for pthread.h… yes
checking for pthread_create in -lpthread… no
checking limits.h usability… yes
checking limits.h presence… no
configure: WARNING: limits.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: limits.h: proceeding with the compiler’s result
checking for limits.h… yes
checking stdlib.h usability… yes
checking stdlib.h presence… no
configure: WARNING: stdlib.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: stdlib.h: proceeding with the compiler’s result
checking for stdlib.h… yes
checking string.h usability… yes
checking string.h presence… no
configure: WARNING: string.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: string.h: proceeding with the compiler’s result
checking for string.h… yes
checking fcntl.h usability… yes
checking fcntl.h presence… no
configure: WARNING: fcntl.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: fcntl.h: proceeding with the compiler’s result
checking for fcntl.h… yes
checking sys/ioctl.h usability… yes
checking sys/ioctl.h presence… no
configure: WARNING: sys/ioctl.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: sys/ioctl.h: proceeding with the compiler’s result
checking for sys/ioctl.h… yes
checking sys/time.h usability… yes
checking sys/time.h presence… no
configure: WARNING: sys/time.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: sys/time.h: proceeding with the compiler’s result
checking for sys/time.h… yes
checking termios.h usability… yes
checking termios.h presence… no
configure: WARNING: termios.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: termios.h: proceeding with the compiler’s result
checking for termios.h… yes
checking unistd.h usability… yes
checking unistd.h presence… no
configure: WARNING: unistd.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: unistd.h: proceeding with the compiler’s result
checking for unistd.h… yes
checking for ddk/hidsdi.h… no
checking for an ANSI C-conforming const… yes
checking whether time.h and sys/time.h may both be included… yes
checking for memset… yes
checking for select… yes
checking for strcasecmp… yes
checking for strdup… yes
checking for strerror… yes
checking for strncasecmp… yes
checking for strtol… yes
checking for strtoul… yes
checking for gettimeofday… yes
checking for usleep… yes
checking for a Win32 HID libray… no
checking for uint_t… no
checking for ulong_t… no
checking for parallel device… configure: parallel port access disabled for this system
checking for serial device… unknown
checking if gcc accepts -Wno-pointer-sign … no
checking that generated files are newer than configure… done
configure: creating ./config.status
config.status: creating doc/Makefile
config.status: creating windows/Makefile
config.status: creating avrdude.spec
config.status: creating Makefile
config.status: creating avrdude.conf.tmp
config.status: creating ac_cfg.h
config.status: executing depfiles commands

Configuration summary:

DON’T HAVE libelf
DON’T HAVE libusb
DON’T HAVE libusb_1_0
DON’T HAVE libftdi1
DON’T HAVE libftdi
DON’T HAVE libhid
DON’T HAVE pthread
DISABLED doc
DISABLED parport
DISABLED linuxgpio
/bin/sh ./ylwrap config_gram.y y.tab.c config_gram.c y.tab.h echo config_gram.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/ y.output config_gram.output – bison -y -d
updating config_gram.h
/bin/sh ./ylwrap lexer.l lex.yy.c lexer.c – flex
make all-recursive
make[1]: Entering directory /boot/home/Desktop/avrdude-6.0.1' Making all in . make[2]: Entering directory/boot/home/Desktop/avrdude-6.0.1’
source=‘config_gram.c’ object=‘libavrdude_a-config_gram.o’ libtool=no
DEPDIR=.deps depmode=gcc /bin/sh ./depcomp
gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR="/boot/common/etc" -Wall -g -O2 -c -o libavrdude_a-config_gram.o test -f 'config_gram.c' || echo './'config_gram.c
In file included from /boot/home/Desktop/avrdude-6.0.1/avr.h:27,
from /boot/home/Desktop/avrdude-6.0.1/config.h:26,
from /boot/home/Desktop/avrdude-6.0.1/config_gram.y:31:
/boot/home/Desktop/avrdude-6.0.1/pgm.h:144: warning: duplicate const' source='lexer.c' object='libavrdude_a-lexer.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/sh ./depcomp \ gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR=\"/boot/common/etc\" -Wall -g -O2 -c -o libavrdude_a-lexer.otest -f ‘lexer.c’ || echo './'lexer.c In file included from /boot/home/Desktop/avrdude-6.0.1/avr.h:27, from /boot/home/Desktop/avrdude-6.0.1/config.h:26, from /boot/home/Desktop/avrdude-6.0.1/lexer.l:33: /boot/home/Desktop/avrdude-6.0.1/pgm.h:144: warning: duplicateconst’
source=‘arduino.c’ object=‘libavrdude_a-arduino.o’ libtool=no
DEPDIR=.deps depmode=gcc /bin/sh ./depcomp
gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR="/boot/common/etc" -Wall -g -O2 -c -o libavrdude_a-arduino.o test -f 'arduino.c' || echo './'arduino.c
In file included from /boot/home/Desktop/avrdude-6.0.1/arduino.c:35:
/boot/home/Desktop/avrdude-6.0.1/pgm.h:144: warning: duplicate const' source='avr.c' object='libavrdude_a-avr.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/sh ./depcomp \ gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR=\"/boot/common/etc\" -Wall -g -O2 -c -o libavrdude_a-avr.otest -f ‘avr.c’ || echo ‘./‘avr.c In file included from /boot/home/Desktop/avrdude-6.0.1/avr.h:27, from /boot/home/Desktop/avrdude-6.0.1/avr.c:33: /boot/home/Desktop/avrdude-6.0.1/pgm.h:144: warning: duplicateconst’
/boot/home/Desktop/avrdude-6.0.1/avr.c: In function avr_tpi_chip_erase': /boot/home/Desktop/avrdude-6.0.1/avr.c:73: parse error beforeunsigned’
/boot/home/Desktop/avrdude-6.0.1/avr.c:90: cmd' undeclared (first use in this function) /boot/home/Desktop/avrdude-6.0.1/avr.c:90: (Each undeclared identifier is reported only once /boot/home/Desktop/avrdude-6.0.1/avr.c:90: for each function it appears in.) make[2]: *** [libavrdude_a-avr.o] Error 1 make[2]: Leaving directory/boot/home/Desktop/avrdude-6.0.1’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory /boot/home/Desktop/avrdude-6.0.1' make: *** [all] Error 2 90: for each function it appears in.) make[2]: *** [libavrdude_a-avr.o] Error 1 make[2]: Leaving directory/boot/home/Desktop/avrdude-6.0.1’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/boot/home/Desktop/avrdude-6.0.1’
make: *** [all] Error 2
data source

There is the GizmoBoard, which has some interesting features like both high and low speed connectors. Plus it should run haiku with no trouble, but you need to by the full kit with other stuff included (like an expansion card, power suppy and a probe) a which puts the price up to $200 USD.

http://www.gizmosphere.org/

Hi alphaseinor,
did you use gcc4 to build (run setarch x86 before you start) as that looks like c89 incompatibility. I could look at making an hpkg for this over the next few days, but doesn’t this need a fully working libusb anyway?

I’d like to look in to libusb at some point (too many projects already though) as I have an oscilloscope and also a logic analyser that I’d like to use in haiku.

Had a quick go and got avrdude to build, it just needed a little nudging. It runs, but it is not linking pthread in yet, so I need to fix that (don’t know what it needs it for…). Also want to check libelf linkage and see what the state of our libusb port is. I don’t think we have libftdi, but that would also be handy so I might look at that too. I’ll try and get an hpkg in when I’m done…

Without these drivers how would it actually connect to an AVR? Serial?

What’s the next step, avr gcc?

Yes it’s going to need libusb

Pulkomandy has been working part time on porting it to Haiku…

I’ve got a ton of things I would love to have libusb for :slight_smile:

Maybe I’ll put up a bounty some time this year (gotta save up!)

alphaseinor - Pulkomandy added libusb and avrdude to haikuporter and I’ve ported libftdi (also in haikuporter now) and fixed up avrdude to use libftdi, libelf and pthread, and that should also be added to haikuporter tomorrow. On a gcc2h system you should be able to install by doing:

haikuporter gettext_x86 --no-dependencies
haikuporter confuse_x86 --no-dependencies
haikuporter libusb_x86 --no-dependencies
haikuporter ncurses_x86 --no-dependencies
haikuporter bzip2_x86 --no-dependencies
haikuporter icu_x86 --no-dependencies
haikuporter boost_x86 --no-dependencies
haikuporter libftdi_x86 --no-dependencies
haikuporter libelf_x86 --no-dependencies
haikuporter avrdude_x86 --no-dependencies

The reason for not just doing “haikuporter avrdude_x86” is that there’s currently a bug in hakuporter that means when compiling for a secondary arch (_x86) it will not handle dependencies properly and will build a lot of stuff unnecessarily (it should still work however, but will take forever), so those are all the dependencies in the correct order (I think). Hopefully that bug will be fixed soon. Note that a couple of those will take a while (ncurses and boost, maybe icu). On a gcc4 or gcc4h system though, you should just be able to do:

haikuporter avrdude

I don’t have any hardware to test with (at least, not now as I’m not at home for the next weeks), so if you could test this it would be awesome!

I’ve got some other hardware that uses libusb that I’m working on porting software for too (logic analyser, oscilloscope), so more will be coming. Fingers crossed on whether libusb works already!

EDIT: latest avrdude is now in haikuports!

Ooooooooh nice!

Unfortunately I’m stuck working the next few days, I’ll dig out a teensy and see what I can mess with!