From: DylanB <dbr...@un...> - 2009-08-28 08:08:52
|
Hello all, I have an IMU (microstrain 3dm-gx1) that i need to connect to my gumstix stack (xm4, robostix, netwifi). The IMU has a serial connection (rs232?). Is it possible to connect this to the robostix and read the data using i2c-io? Dylan. -- View this message in context: http://www.nabble.com/Robostix-IMU-Serial-tp25185790p25185790.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-08-28 15:13:10
|
Hi Dylan, > I have an IMU (microstrain 3dm-gx1) that i need to connect to my gumstix > stack (xm4, robostix, netwifi). The IMU has a serial connection (rs232?). Is > it possible to connect this to the robostix and read the data using i2c-io? Not as is. It was always my intention to write a driver which would allow the serial ports on the robostix to show up as serial ports under linux, but I never got around to it. It wouldn't be too hard to add a custom command to i2c-io to query the IMU and return the results. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: DylanB <dbr...@un...> - 2009-08-29 00:34:00
|
Hello, >It was always my intention to write a driver which would allow the >serial ports on the robostix to show up as serial ports under linux, >but I never got around to it. What do the ports show up as? >It wouldn't be too hard to add a custom command to i2c-io to query the >IMU and return the results. How do I physically connect to the robostix? Dylan. -- View this message in context: http://www.nabble.com/Robostix-IMU-Serial-tp25185790p25198719.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: UAVDroid <car...@ho...> - 2010-03-24 01:55:35
|
Hopefully no one will mind if I jump in there but I am attempting to do very the same thing, read from a micro strain IMU and additionally run some servos over i2c. I have made some modifications to the API and would like to setup the make files as you described but running into a hitch. I tried linking CC to where the gcc executable is in the cross folder but I am receiving the error 127 "Command not found" when I run the Make file. If not the executable then what is CC supposed to be linked to ? I'm still new to all this so that might explain a lot. what's in the cc path in the make file is now, and below the error massage GUMSTIX_ROOT = $/home/carl/gumstix/gumstix-oe CROSS_COMPILE = $(GUMSTIX_ROOT)/tmp/cross/arm-angstrom-linux-gnueabi/bin/ CC = $(CROSS_COMPILE)gcc :~/gumstix/robostix/gumstix/i2c$ make Creating svn-version.h ... home/carl/gumstix/gumstix-oe/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc -O2 -Wall -I . -I ../Common -I ../../Shared -Os -march=armv5te -mtune=xscale -Wa,-mcpu=xscale -c -o i2c.o i2c.c make: home/carl/gumstix/gumstix-oe/tmp/cross/arm-angstrom-linux-gnueabi/bin/gcc: Command not found make: *** [i2c.o] Error 127 Thanks for you help Dave Hylands wrote: > > Hi Dylan, > > On Mon, Mar 22, 2010 at 1:16 AM, DylanB <dbr...@un...> > wrote: >> >> Hello, >> >> I'm planning to use the method outlined on this page >> http://old.nabble.com/Verdex-XM4-BT-Capabilities-with-Robostix-td15056977.html >> >> The i2c-io code for the Robostix is used along with custom code provided >> in >> the link. The makefile has also included so I would like to trail this >> method first to see how it performs. >> >> It seems that the makefile is setup to use buildroot. How do I compile >> the >> code when I am using OE? I have looked at the link below which suggests >> pointing the makefile to the correct tool chain. I am not sure what this >> means. >> http://old.nabble.com/Code-portability-from-gumstix-to-Gumstix-oe--td15778182.html#a15778631 > > In the old makefiles (for building the gumstix side of the code), they > typically contain something like this: > > GUMSTIX_BUILDROOT = $(PWD)/../../../gumstix-buildroot > BUILD_ARM = $(GUMSTIX_BUILDROOT)/build_arm_nofpu > CROSS_COMPILE = $(BUILD_ARM)/staging_dir/bin/arm-linux- > > and then > > CC = $(CROSS_COMPILE)gcc > > So CC winds up being a path to get to the C compiler. > > Once you've built the OE cross compiler, you can modify the makefile > along these lines: > > OVEROTOP ?= /home/gumstix/overo-oe > CROSS_COMPILE ?= > $(OVEROTOP)/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi- > > Back in October, I worked with Joseph and Steve to get the robostix > stuff working for verdex under OE. I'm not sure what became of those > changes. The files I modified are over here: > <http://www.davehylands.com/gumstix-wiki/robostix-oe/> > > I think that just addressed the robostix driver itself. The other > gumstix side files might also need some slight tweaks. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28009730.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-24 03:50:22
|
Hi, On Tue, Mar 23, 2010 at 6:55 PM, UAVDroid <car...@ho...> wrote: > > Hopefully no one will mind if I jump in there but I am attempting to do very > the same thing, read from a micro strain IMU and additionally run some > servos over i2c. I have made some modifications to the API and would like to > setup the make files as you described but running into a hitch. > > I tried linking CC to where the gcc executable is in the cross folder but I > am receiving the error 127 "Command not found" when I run the Make file. > If not the executable then what is CC supposed to be linked to ? I'm still > new to all this so that might explain a lot. > > what's in the cc path in the make file is now, and below the error massage > > GUMSTIX_ROOT = $/home/carl/gumstix/gumstix-oe > CROSS_COMPILE = $(GUMSTIX_ROOT)/tmp/cross/arm-angstrom-linux-gnueabi/bin/ > CC = $(CROSS_COMPILE)gcc You have an extraneous $ in your definition of GUMSTIX_ROOT > GUMSTIX_ROOT = $/home/carl/gumstix/gumstix-oe And you don't want to use the executable that's just named gcc. Use the one that's called arm-angstrom-linux-gnueabi-gcc So set CROSS_COMPILE to be $(GUMSTIX_ROOT)/tmp/cross/bin/arm-angstrom-linux-gnueabi- -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2009-08-29 01:12:04
|
Hi Dylan, On Fri, Aug 28, 2009 at 5:11 PM, DylanB <dbr...@un...> wrote: > > Hello, > > >It was always my intention to write a driver which would allow the > >serial ports on the robostix to show up as serial ports under linux, > >but I never got around to it. > > What do the ports show up as? Well they don't show up because I never wrote the driver :) > >It wouldn't be too hard to add a custom command to i2c-io to query the > >IMU and return the results. > > How do I physically connect to the robostix? The IMU says it has RS232 interface (i.e. it can be connected directly to a PC). Since the robostix UART ports are logic-level, you'll need a logic-level to RS-232 converter like one of the ones on this page: <http://docwiki.gumstix.com/Serial_adapters> You would connect the Tx from the serial adpter to Rx on one of the UART ports, and Rx from the serial adapter to Tx on one of the UART ports, and connect up the grounds as well. Then the robostix should be able to talk to it. There are some UART functions already coded for the robostix (tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/robostix-1.0-r0/robostix/Common/UART.h and .c). Flash-LED.c has some examples of how to use the functions. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: DylanB <dbr...@un...> - 2010-03-16 03:07:59
|
Hello, I am trying to edit the code in the directory (tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/robostix-1.0-r0/robostix), namely Flash-LED and i2c-io. 1) Am I correct in assuming that I need to create Bitbake recipes to compile the code for the Verdex (rather than using the makefiles supplied) because I have been developing with OE? 2) Can the code that goes onto the Robostix, i.e. all hex files, be compiled using the makefiles that are supplied or will they be affected somehow? 3) Is the source code used in the robostix.bb recipe (i.e. called from the svn URL) exactly the same as the code supplies in tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/robostix-1.0-r0/robostix? 4) I ask 3) because I want to edit the robostix.bb recipe to accept changed versions of the code stored in a local directory instead of the URL. Does this seem like a reasonable approach? I'm just trying to get my head around all of this. As always thanks. Dylan. Thanks, Dylan. -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p27913085.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <as...@gu...> - 2010-03-16 07:40:35
|
Hi Dylan, Responses are inline. On Mon, Mar 15, 2010 at 8:07 PM, DylanB <dbr...@un...> wrote: > I am trying to edit the code in the directory > (tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/robostix-1.0-r0/robostix), > namely Flash-LED and i2c-io. This is fine as long as you keep your work backed up elsewhere. A 'bitbake robostix -c clean' will blow your changes away. > > 1) Am I correct in assuming that I need to create Bitbake recipes to compile > the code for the Verdex (rather than using the makefiles supplied) because I > have been developing with OE? It is not necessary to use Bitbake recipes but this is the work flow (and the benefit) provided by OpenEmbedded to make your life easier. If you have a makefile already, the recipe is usually trivial. http://www.gumstix.net/wiki/index.php?title=HelloWorld_Examples and http://www.gumstix.net/Setup-and-Programming/view/Build-system-overview/Hello-world-tutorial/111.html have examples of this. All that said, if you are trying to develop code to run on the Robostix, you may find it easier just to use the avr-gcc utilities directly. > > 2) Can the code that goes onto the Robostix, i.e. all hex files, be compiled > using the makefiles that are supplied or will they be affected somehow? Bitbake basically sets up the environment correctly (right executables on the path, right compile flags set, right locations of libraries...) and then runs the makefile. Perhaps you could clarify what you mean by 'affected somehow'? > > 3) Is the source code used in the robostix.bb recipe (i.e. called from the > svn URL) exactly the same as the code supplies in > tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/robostix-1.0-r0/robostix? Essentially yes. Bitbake downloaded the code according to the SRC_URI specified in the robostix.bb recipe and unpacked it to tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/robostix-1.0-r0/robostix. It then patches this code with any patches listed in the robostix.bb file. > > 4) I ask 3) because I want to edit the robostix.bb recipe to accept changed > versions of the code stored in a local directory instead of the URL. Does > this seem like a reasonable approach? I'm just trying to get my head around > all of this. The recommended way to do this would be to generate patches against the downloaded code (this page http://blogs.elphel.com/2009/12/openembeddedangstrom-kernel-workflow/ gives some hints about the useful 'quilt' tool). Equally, you could download the code to your own directory (not a directory below tmp/), make modifications, and tell bitbake to fetch code from there instead. For general information about how OE fetches sources, see http://docs.openembedded.org/usermanual/usermanual.html#recipes_sources. Admittedly, OE can be a lot to get your head around at first. Be sure to ask questions and play with different recipes and tutorials. -Ash |
From: DylanB <dbr...@un...> - 2010-03-16 11:14:15
|
That clears a few things up. >Equally, you could download the code to your own directory (not a directory below tmp/), >make modifications, and tell bitbake to fetch code from there instead. This sounds like the best way for me to go. Now to just try and understand the source code... Thanks for the detailed response. Dylan. -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p27916205.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: DylanB <dbr...@un...> - 2010-04-06 14:51:02
|
Hello, >> What does the build enviro. kernel do and why is it not the same from the >> start? > >The kernel verison of the build environment itself isn't all that >important. However, the version of the kernel which is targeted for >the gumstix is quite significant. Argh sorry confusing question. What I meant was why is the targeted kernel not the same? OK so if I want to get the kernel/libraries etc targeted by the build system to be the same as those on the Verdex where do I start? Is some variety of svn download required? I'm not sure where to look. Also I have a couple of questions relating to the sertest program. "Some hardware requires a carriage return (0x0d) to function properly." Does this include level shifters? The reason I ask is that when I run sertest with the shifter (Rx and Tx crossed) connected to the STUART on the robostix I get no feedback. The shifter has leds to show Rx and Tx working, only Tx seems to be doing something. http://www.sparkfun.com/commerce/product_info.php?products_id=8780 Could this be caused by the line carriage issue or might I have other problems? I'm assuming the code is compiled OK because when I do the same with no shifter then it works just fine. I've tried to use the suggested correction in the code but I am having difficulty compiling sertest.c. I get the following error: " ERROR: function do_compile failed ERROR: log data follows (/home/dylan/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/sertestdylan-1.0.0-r0/temp/log.do_compile.10283) | /tmp/ccy9OmAM.o: In function `main': | sertestdylan.c:(.text+0x500): undefined reference to `pthread_create' | collect2: ld returned 1 exit status " I though that pthreads.h would be a part of libc6-dev. I have that already so what else may I be missing? Finally, if I have pre compiled recipes from say gumstix.com collection how do I know that they were compiled for my target system? How can I have bitbaked the basic image if my targeted kernel is different to the one that is on there? Dylan. -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28152933.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-16 14:55:25
|
Hi Dylan, On Tue, Mar 16, 2010 at 4:14 AM, DylanB <dbr...@un...> wrote: > > That clears a few things up. > >>Equally, you could download the code to your own directory (not a directory > below tmp/), >>make modifications, and tell bitbake to fetch code from there instead. > > This sounds like the best way for me to go. Now to just try and understand > the source code... And for another option, it's possible to build both the host side and ATMega128 stuff just using traditional makefiles, and not using OE at all. If you decide to go this route, let me know - I should be able to help with the Makefile modifications. What's really important if you go this route is that the version of linux and glibc etc running on the gumstix match your build environment. Or in other words, make sure that you've build one of the standard images and that you have a bootable SD card containing that image. Or you can look at this Makefile: <http://svn.hylands.org/linux/gpio/app/Makefile> If you need any help understanding any of the robostix code, I'll be happy to help. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: DylanB <dbr...@un...> - 2010-03-22 08:16:53
|
Hello, I'm planning to use the method outlined on this page http://old.nabble.com/Verdex-XM4-BT-Capabilities-with-Robostix-td15056977.html The i2c-io code for the Robostix is used along with custom code provided in the link. The makefile has also included so I would like to trail this method first to see how it performs. It seems that the makefile is setup to use buildroot. How do I compile the code when I am using OE? I have looked at the link below which suggests pointing the makefile to the correct tool chain. I am not sure what this means. http://old.nabble.com/Code-portability-from-gumstix-to-Gumstix-oe--td15778182.html#a15778631 Thanks, Dylan. -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p27983321.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-22 16:04:45
|
Hi Dylan, On Mon, Mar 22, 2010 at 1:16 AM, DylanB <dbr...@un...> wrote: > > Hello, > > I'm planning to use the method outlined on this page > http://old.nabble.com/Verdex-XM4-BT-Capabilities-with-Robostix-td15056977.html > > The i2c-io code for the Robostix is used along with custom code provided in > the link. The makefile has also included so I would like to trail this > method first to see how it performs. > > It seems that the makefile is setup to use buildroot. How do I compile the > code when I am using OE? I have looked at the link below which suggests > pointing the makefile to the correct tool chain. I am not sure what this > means. > http://old.nabble.com/Code-portability-from-gumstix-to-Gumstix-oe--td15778182.html#a15778631 In the old makefiles (for building the gumstix side of the code), they typically contain something like this: GUMSTIX_BUILDROOT = $(PWD)/../../../gumstix-buildroot BUILD_ARM = $(GUMSTIX_BUILDROOT)/build_arm_nofpu CROSS_COMPILE = $(BUILD_ARM)/staging_dir/bin/arm-linux- and then CC = $(CROSS_COMPILE)gcc So CC winds up being a path to get to the C compiler. Once you've built the OE cross compiler, you can modify the makefile along these lines: OVEROTOP ?= /home/gumstix/overo-oe CROSS_COMPILE ?= $(OVEROTOP)/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi- Back in October, I worked with Joseph and Steve to get the robostix stuff working for verdex under OE. I'm not sure what became of those changes. The files I modified are over here: <http://www.davehylands.com/gumstix-wiki/robostix-oe/> I think that just addressed the robostix driver itself. The other gumstix side files might also need some slight tweaks. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: DylanB <dbr...@un...> - 2010-03-29 03:18:23
|
Hello, I tried out the suggested modifications for the original makefiles and they seem to compile OK. I had a look at the "developer how-to" page which shows how to create an SD card with uimage and rootfs (where are these by the way). Why is this required for using makefile compiled programs? Also how can I check to ensure that the versions of glibc and linux etc are the same? Thank you, Dylan. >If you decide to go this route, let me know - I should be able to >help with the Makefile modifications. What's really important if you >go this route is that the version of linux and glibc etc running on >the gumstix match your build environment. Or in other words, make sure >that you've build one of the standard images and that you have a >bootable SD card containing that image. -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28064595.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: DylanB <dbr...@un...> - 2010-04-11 09:34:21
|
Ok so I now have the level shifter connected correctly, and sertest runs correctly. Also I was able to bitbake sertest with the addition of < LDFLAGS =+ "-lpthread" > to my bitbake recipe. Thanks. I also compiled some sample code, for noncanonical input processing, that i found in the link from the sertest wiki page. I first trialled this on my workstation and it works perfectly. After this I bitbaked a version for the gumstix, with a few printfs in there to monitor its progress, and tried that. This is where some strange things happen: -No level shifter attached Rx and Tx (STUART) crossed >> the program works the same way as before when run on the work station -Level shifter attached Rx and Tx (rs232 i/o on shifter) not crossed >> the program show 1 2 3 4 5 i.e. reaches the while loop then doesn't enter it and keyboard inputs are shown in the terminal?! -Level shifter attached Rx and Tx (rs232 i/o on shifter) intermittently crossed >> Same as above but sometimes when the signal lines are crossed the program will perform one execution of the while loop?! Does this sound like a hardware issue or is there something missing in my code that is required when using the Verdex STUARTS that would not be required when using a serial port on a PC? I am thinking that its a hardware issue somewhere but then again the sertest program runs OK ... I think I need to find another level shifter somewhere to rule that out, any other ideas? Dylan Here is the C code I used (source: http://tldp.org/HOWTO/Serial-Programming-HOWTO/x115.html) #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <termios.h> #include <stdio.h> #define BAUDRATE B115200 #define MODEMDEVICE "/dev/ttyS2" #define _POSIX_SOURCE 1 /* POSIX compliant source */ #define FALSE 0 #define TRUE 1 volatile int STOP=FALSE; main() { printf("\n 1 \n"); int fd,c, res; struct termios oldtio,newtio; char buf[255]; printf("\n 2 \n"); fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY ); printf("\n 3 \n"); tcgetattr(fd,&oldtio); /* save current port settings */ newtio.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD; newtio.c_iflag = IGNPAR; newtio.c_oflag = 0; printf("\n 4 \n"); /* set input mode (non-canonical, no echo,...) */ newtio.c_lflag = 0; newtio.c_cc[VTIME] = 0; /* inter-character timer unused */ newtio.c_cc[VMIN] = 1; /* blocking read until 5 chars received */ tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&newtio); printf("\n 5 \n"); for (;;) { /* loop for input */ printf(" this wont work"); res = read(fd,buf,255); /* returns after 1 chars have been input */ buf[res]=0; /* so we can printf... */ printf(":%s:%d\n", buf, res); if (buf[0]=='z') STOP=TRUE; } tcsetattr(fd,TCSANOW,&oldtio); } -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28207454.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-29 06:13:29
|
Hi Dylan, On Sun, Mar 28, 2010 at 8:18 PM, DylanB <dbr...@un...> wrote: > > Hello, > > I tried out the suggested modifications for the original makefiles and they > seem to compile OK. > I had a look at the "developer how-to" page which shows how to create an SD > card with uimage and rootfs (where are these by the way). Why is this > required for using makefile compiled programs? I don't think that it is required (using an SD card). But it's generally easier to mess around with an SD card than it is to create a NAND image. > Also how can I check to > ensure that the versions of glibc and linux etc are the same? The simplest way is to build an SD card from your build environment and boot from it. That way you know everything matches. If you use the kernel and stuff that comes with the gumstix, your build environment is almost certainly newer and if you try to use some files from your build environment and some that came with your gumstix, then you can run into troubles. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: DylanB <dbr...@un...> - 2010-03-29 10:42:37
|
I have made a BB recipe for IMU_control.c, it is like the helloworld example but with changed files, i.e. heaps of header files etc. My recipe fails with the errors below: NOTE: package imucontrol-1.00-r0: task do_compile: started ERROR: function do_compile failed ERROR: log data follows (/home/dylan/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/imucontrol-1.00-r0/temp/log.do_compile.25306) | /tmp/ccKCNCZ1.o: In function `main': | imu_control.c:(.text+0x364): undefined reference to `LogError' | imu_control.c:(.text+0x378): undefined reference to `I2cSetSlaveAddress' | imu_control.c:(.text+0x388): undefined reference to `I2C_IO_WriteReg8' | imu_control.c:(.text+0x398): undefined reference to `I2C_IO_WriteReg8' | imu_control.c:(.text+0x3a8): undefined reference to `I2C_IO_WriteReg16' | imu_control.c:(.text+0x3b8): undefined reference to `I2C_IO_WriteReg16' etc... Seems that I am missing these object codes: OBJS = \ i2c-api.o \ i2c-io-api.o \ AvrInfo.o \ BootLoader-api.o\ Crc8.o \ DumpMem.o \ Log.o Based on this line from the makefile: IMU_control: svn-version.h IMU_control.o $(OBJS) How can I get them into a .bb recipe? Also since I have a makefile that compiles the code I am after will making a .bb recipe that uses the makefile solve the potential issues caused by different linux, glibc etc versions between gumstix and build environments? Dylan -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28067517.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-29 14:20:28
|
Hi Dylan, On Mon, Mar 29, 2010 at 3:42 AM, DylanB <dbr...@un...> wrote: > > I have made a BB recipe for IMU_control.c, it is like the helloworld example > but with changed files, i.e. heaps of header files etc. My recipe fails with > the errors below: > > NOTE: package imucontrol-1.00-r0: task do_compile: started > ERROR: function do_compile failed > ERROR: log data follows > (/home/dylan/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/imucontrol-1.00-r0/temp/log.do_compile.25306) > | /tmp/ccKCNCZ1.o: In function `main': > | imu_control.c:(.text+0x364): undefined reference to `LogError' > | imu_control.c:(.text+0x378): undefined reference to `I2cSetSlaveAddress' > | imu_control.c:(.text+0x388): undefined reference to `I2C_IO_WriteReg8' > | imu_control.c:(.text+0x398): undefined reference to `I2C_IO_WriteReg8' > | imu_control.c:(.text+0x3a8): undefined reference to `I2C_IO_WriteReg16' > | imu_control.c:(.text+0x3b8): undefined reference to `I2C_IO_WriteReg16' > > etc... > > Seems that I am missing these object codes: > OBJS = \ > i2c-api.o \ > i2c-io-api.o \ > AvrInfo.o \ > BootLoader-api.o\ > Crc8.o \ > DumpMem.o \ > Log.o > > Based on this line from the makefile: > IMU_control: svn-version.h IMU_control.o $(OBJS) > > How can I get them into a .bb recipe? I used a makefile based bb recipie rather than a file based one. > Also since I have a makefile that compiles the code I am after will making a > .bb recipe that uses the makefile solve the potential issues caused by > different linux, glibc etc versions between gumstix and build environments? What's important is not how the stuff gets built, but that it gets loaded onto a gumstix that's running a kernel from the same build environment. User mode programs aren't as critical this way, but kernel modules are. glibc doesn't change version very often, but the kernel changes version more frequently. You can tell what version of kernel is on your gumstix by doing: uname -a on the gumstix itself. You can tell what version of kernel is in your build environment by looking at tmp/work/armv7a-angstrom-linux-gnueabi. You'll find a directory that starts with linux-libc-headers-*. My build environment contains: linux-libc-headers-2.6.31-r0 and that will contain a directory called linux-2.6.31. So you know that your build environment is using a 2.6.31 kernel. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: DylanB <dbr...@un...> - 2010-03-30 07:11:32
|
OK I think I understand a bit, gumstix: 2.6.21 build enviro.:2.6.20 Do I try to update the build enviro. kernel or downgrade the gumstix? Based on this thread it seems that upgrading the gumstix is quite a hefty undertaking. Is it the same story for the build enviro.? http://old.nabble.com/Gumstix-Verdex-Kernel-td27358561.html#a27376112 Considering that I have compiled/used the various sample programs by Dave Hylands before without trouble is it reasonable to assume that a slight variation to these programs will function OK? What does the build enviro. kernel do and why is it not the same from the start? Also where does glibc come into this? I thought that once I compiled something using say bitbake then I just have some variety of executable that would not need any further libraries (i.e. the ones on the gumstix) to work. Thanks for all attempts to remedy my state of mass confusion! Dylan. -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28078478.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: DylanB <dbr...@un...> - 2010-04-19 02:44:45
|
Dave, My setup is as you have described: Verdex, Robostix, external IMU connected to STUART via level shifter. The level shifter works with sertest (RX TX crossed). When I try to run the IMU code, which works on my laptop, on the Verdex strange things happen. With no level shifter attached the code runs. With the level shifter attached the code does not run at all, i.e. not even a printf before I try to open the port. The IMU is not even connected here so I don't know what is causing all the trouble. I have tried a couple of level shifters. Does this seem very odd? How can code be stopped from running when the only difference is the level shifter being attached? Its not as though sertest doesn't work when the shifter is attached. Dylan. Dave Hylands wrote: > > Hi Dylan, > > On Mon, Apr 12, 2010 at 7:03 AM, DylanB <dbr...@un...> > wrote: > ...snip... >> Centrale OK >> -------------------------------- >> roll:0.00000 >> yaw: 2.056752 >> pitch:0.00000 >> --------------------------------- This section just repeats and stays the >> same, everytime >> >> When I run it on my PC the first 3 or 4 runs of the repeating section all >> read zero (i.e. pitch: 0.00000), and then the correct values start >> spitting >> out. > > OK - What's your exact setup? > > i.e. From your emails, I gather that > 1 - You're using a Verdex. > 2 - You're using a robostix > 3 - You've got an external IMU connected to the STUART through a level > shifter > 4 - Presumably you don't have the robostix serial connected to the > STUART as well. > > I'd probably start by looking at the raw data bytes coming from the > IMU and compare that with the raw bytes being received by the PC. > > It's possible that the problem is related to floating point conversion > or something, so I'd try to see if the raw data is the same. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28286590.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-30 18:11:56
|
Hi Dylan, On Tue, Mar 30, 2010 at 12:11 AM, DylanB <dbr...@un...> wrote: > > OK I think I understand a bit, > > gumstix: 2.6.21 > build enviro.:2.6.20 > > Do I try to update the build enviro. kernel or downgrade the gumstix? It seems like your build environment is older, so personally I would update my build environment. > Based on this thread it seems that upgrading the gumstix is quite a hefty > undertaking. Is it the same story for the build enviro.? There are a bunch of steps required to make a proper bootable SD card, but once you've got it, making further updates is pretty straight forward. > http://old.nabble.com/Gumstix-Verdex-Kernel-td27358561.html#a27376112 > > Considering that I have compiled/used the various sample programs by Dave > Hylands before without trouble is it reasonable to assume that a slight > variation to these programs will function OK? It depends. User mode programs will probably work fine. Kernel modules built to target a 2.6.20 kernel won't load on a gumstix running 2.6.21. > What does the build enviro. kernel do and why is it not the same from the > start? The kernel verison of the build environment itself isn't all that important. However, the version of the kernel which is targeted for the gumstix is quite significant. Let's say that your build environment is targeting 2.6.20. Then any loadable modules which you compile will also be targeted for 2.6.20 and will only work on a gumstix which is running 2.6.20. > Also where does glibc come into this? I thought that once I compiled > something using say bitbake then I just have some variety of executable that > would not need any further libraries (i.e. the ones on the gumstix) to work. glibc is typically built as a shared library, which means that the executable program doesn't actually include the runtime functions. So if your build environment builds your program against glibc version 2.5, and your gumstix has glibc version 2.6 and you only copy the executable, then it might not work since it won't find version 2.5 of glibc. glibc is typically called something like libc.so.6 and this is often a symlink to the real glibc library, which in my build environment is libc-2.9.so (so it's glibc version 2.9) -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2010-04-09 02:51:42
|
Hi Dylan, Sorry to take so long to respond. Your email got marked as read - and then I forgot about it. On Tue, Apr 6, 2010 at 7:50 AM, DylanB <dbr...@un...> wrote: > > Hello, > >>> What does the build enviro. kernel do and why is it not the same from the >>> start? >> >>The kernel verison of the build environment itself isn't all that >>important. However, the version of the kernel which is targeted for >>the gumstix is quite significant. > > Argh sorry confusing question. What I meant was why is the targeted kernel > not the same? > > OK so if I want to get the kernel/libraries etc targeted by the build system > to be the same as those on the Verdex where do I start? Is some variety of > svn download required? I'm not sure where to look. What I do is to setup whatever build environment I'm going to use (OE or buildroot), build the kernel and rootfs and use the ones I built. Then I'm 100% sure that everything matches. > Also I have a couple of questions relating to the sertest program. > > "Some hardware requires a carriage return (0x0d) to function properly." > > Does this include level shifters? The reason I ask is that when I run > sertest with the shifter (Rx and Tx crossed) connected to the STUART on the > robostix I get no feedback. The shifter has leds to show Rx and Tx working, > only Tx seems to be doing something. Level shifters don't care about the content. In order for the level shifter to work, it requires the correct voltages to be present at the right places. The Tx and Rx from the STUART port are from the gumstix perspective (so Tx is an output and Rx is an input). Generally speaking, when using level shifters I ignore the Tx/Rx stuff and just look at inputs and outputs. So you need to make sure that you're connecting inputs to outputs. This means that the Tx from the STUART needs to connect to the input on the level shifter. And the Rx from the STUART needs to connect to the output from the level shifter. And it needs to connect to the logic-level side of the level shifter, and not the RS-232 level side. > http://www.sparkfun.com/commerce/product_info.php?products_id=8780 > Could this be caused by the line carriage issue or might I have other > problems? I'm assuming the code is compiled OK because when I do the same > with no shifter then it works just fine. You probably have the level shifter mis-wired. RS-IN is the RS-232-level signal which is an input. It connects through to Tx which is the corresponding logic-level output, which should be connected to the STUART Rx (input) signal. RS-OUT is the RS-232 level signal which is an output. Rx is the logic level input, which needs to be connected to the STUART Tx (output) signal. > I've tried to use the suggested correction in the code but I am having > difficulty compiling sertest.c. I get the following error: > " ERROR: function do_compile failed > ERROR: log data follows > (/home/dylan/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/sertestdylan-1.0.0-r0/temp/log.do_compile.10283) > | /tmp/ccy9OmAM.o: In function `main': > | sertestdylan.c:(.text+0x500): undefined reference to `pthread_create' > | collect2: ld returned 1 exit status " > > I though that pthreads.h would be a part of libc6-dev. I have that already > so what else may I be missing? You're actually getting a linker error, not a compiler error. Which means that you need to add the pthreads library (i.e. -lpthreads) to the link stage command line. > Finally, if I have pre compiled recipes from say gumstix.com collection how > do I know that they were compiled for my target system? How can I have > bitbaked the basic image if my targeted kernel is different to the one that > is on there? I'm not sure. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2010-04-11 17:13:03
|
Hi Dylan, > struct termios oldtio,newtio; Because these are declared on the stack, they will have random contents. > printf("\n 3 \n"); > tcgetattr(fd,&oldtio); /* save current port settings */ > I think you're missing one critical line of code here: Either so what sertest does: newtio = oldtio; or do what the sample code does: memset( &newtio, 0, sizeof( newtio )); The sample code you referenced used bzero rather than memset, but same idea. > newtio.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD; > newtio.c_iflag = IGNPAR; > newtio.c_oflag = 0; > > printf("\n 4 \n"); > /* set input mode (non-canonical, no echo,...) */ > newtio.c_lflag = 0; > > newtio.c_cc[VTIME] = 0; /* inter-character timer unused */ > newtio.c_cc[VMIN] = 1; /* blocking read until 5 chars received */ -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: DylanB <dbr...@un...> - 2010-04-12 14:03:44
|
Hi Dave, Dave Hylands wrote: > > I think you're missing one critical line of code here: > > Either so what sertest does: > newtio = oldtio; > or do what the sample code does: > memset( &newtio, 0, sizeof( newtio )); > I think I had those in when I bitbaked it for the Verdex. I took them out because I had errors when trying to run it on my PC. Taking those out let it compile and run OK. Ive been trying to implement some sample code for the IMU I'm using. It works on my PC but when I try and transfer it over (i.e. change /dev/ttyUSB0 to /dev/ttyS2) to the Verdex it doesn't quite work. I was looking at the imput processing example code to help understand the IMU code because they appear to be quite similar. The code seems to run and the LEDs on the level shifter blink like crazy but the output I get is: Centrale OK -------------------------------- roll:0.00000 yaw: 2.056752 pitch:0.00000 --------------------------------- This section just repeats and stays the same, everytime When I run it on my PC the first 3 or 4 runs of the repeating section all read zero (i.e. pitch: 0.00000), and then the correct values start spitting out. Other forum users have said that using this code has worked for them so I don't know where I'm going wrong. I've tried to rule out: the level shifter by running and checking sertest. the baud rate by trying all that the IMU uses as per documentation the code by running it on my PC all of the wiring by running a voltage through sections and checking that no parts are receiving voltage that shouldn't I don't know what else to try. I'm worried that my build enviro. might be doing something funny but I don't know how to set the targeted kernel/libraries etc to the ones on the Verdex at the moment. Do i need to point/link something to the gumstix-basic-image that I have bitbaked and put onto the Verdex? How do I configure the target system to that which is on the Verdex? Dylan. This is the IMU code I'm using: http://old.nabble.com/3DM-GX1-IMU-communications-td14948202.html#a14948202 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/mman.h> #include <termios.h> #include <fcntl.h> #define MODEMDEVICE "/dev/ttyS2" struct orientation{ double roll; double pitch; double yaw; double droll; double dpitch; double dyaw; unsigned char commande; }; unsigned int readgain(int dev,char type); struct orientation read_3dm(int dev,double accelgain,double gyrogain,struct orientation prev_angles); int ouvre_com(void); int main(int argc, char *argv[]) { int rs232,i,j,k; struct orientation angles; unsigned int accelgain,gyrogain; //connexion serie rs232=ouvre_com(); accelgain=readgain(rs232,'A'); gyrogain=readgain(rs232,'G'); printf("Central OK\n"); while(1) { angles=read_3dm(rs232,accelgain,gyrogain,angles); printf("roll %f\n",angles.roll); printf("pitch %f\n",angles.pitch); printf("yaw %f\n",angles.yaw); } close(rs232); return 0; } unsigned int readgain(int dev,char type) { unsigned char data,buf[7]; unsigned int gain; data=0x28; write(dev,&data,1); data=0x00; write(dev,&data,1); switch(type) { case 'G': data=0x82; break; case 'A': data=0xe6; break; } write(dev,&data,1); read(dev,buf,7); gain=buf[1]*256+buf[2]; return gain; } struct orientation read_3dm(int dev,double accelgain,double gyrogain,struct orientation prev_angles) { struct orientation angles; signed char buf[23]; char data; unsigned long check=0,i; data=0x31; write(dev,&data,1); read(dev,buf,23); check=(unsigned char)buf[0]; for(i=1;i<21;i=i+2) { check=check+((unsigned char)buf[i]*256)+(unsigned char)buf[i+1]; } check=check&0xffff; if(check==((unsigned char)buf[21])*256+(unsigned char)buf[22]) { angles.roll=(double)(buf[3]*256+buf[4])*360/65535; angles.pitch=-(double)(buf[1]*256+buf[2])*360/65535; angles.yaw=(double)(buf[5]*256+buf[6])*360/65535; angles.droll=(double)(buf[15]*256+buf[16])*gyrogain/32768000; angles.dpitch=-(double)(buf[13]*256+buf[14])*gyrogain/32768000; angles.dyaw=(double)(buf[17]*256+buf[18])*gyrogain/32768000; angles.commande=buf[0]; } else { angles=prev_angles; } return angles; } int ouvre_com(void) { int fd; struct termios newtio; fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY ); if (fd<0) printf("prob ouverture"); newtio.c_cflag = B115200 | CS8 | CLOCAL | CREAD; newtio.c_iflag = IGNBRK;//IGNPAR; newtio.c_oflag = 0; /* set input mode (non-canonical, no echo,...) */ newtio.c_lflag = 0; newtio.c_cc[VTIME]=0; /* inter-character timer unused */ newtio.c_cc[VMIN]=1; /* blocking read until chars received */ tcsetattr(fd,TCSANOW,&newtio); tcflush(fd, TCIFLUSH);//vide bufffer return fd; } -- View this message in context: http://old.nabble.com/Robostix-IMU-Serial-tp25185790p28218187.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-04-13 05:14:18
|
Hi Dylan, On Mon, Apr 12, 2010 at 7:03 AM, DylanB <dbr...@un...> wrote: ...snip... > Centrale OK > -------------------------------- > roll:0.00000 > yaw: 2.056752 > pitch:0.00000 > --------------------------------- This section just repeats and stays the > same, everytime > > When I run it on my PC the first 3 or 4 runs of the repeating section all > read zero (i.e. pitch: 0.00000), and then the correct values start spitting > out. OK - What's your exact setup? i.e. From your emails, I gather that 1 - You're using a Verdex. 2 - You're using a robostix 3 - You've got an external IMU connected to the STUART through a level shifter 4 - Presumably you don't have the robostix serial connected to the STUART as well. I'd probably start by looking at the raw data bytes coming from the IMU and compare that with the raw bytes being received by the PC. It's possible that the problem is related to floating point conversion or something, so I'd try to see if the raw data is the same. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |