From: <fo...@it...> - 2007-06-13 17:36:05
|
Hi Dave, Thanks for your response. The i2c-Sensor.c file does indeed have a main function, but for some reason this file isn't being compiled. I have attached my i2c-Sensor* files and the Makefile. The output of the commands that you suggested also appears below. Daniel +++++++++++++++++++++++ [fokumdt@iodine i2c-Sensor]$ make v=1 Creating svn-version.h ... make: Circular i2c-Sensor.elf <- i2c-Sensor dependency dropped. Compiling i2c-slave-boot.c ... avr-gcc -Os -Wall -Werror -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wunused -Wcast-qual -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DCFG_CPU_CLOCK=16000000 -mmcu=atmega128 -I . -I ../Common -I ../Shared -c -MMD -MF i2c-slave-boot.d -o i2c-slave-boot.o i2c-slave-boot.c Compiling Delay.c ... avr-gcc -Os -Wall -Werror -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wunused -Wcast-qual -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DCFG_CPU_CLOCK=16000000 -mmcu=atmega128 -I . -I ../Common -I ../Shared -c -MMD -MF Delay.d -o Delay.o Delay.c Compiling Timer.c ... avr-gcc -Os -Wall -Werror -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wunused -Wcast-qual -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DCFG_CPU_CLOCK=16000000 -mmcu=atmega128 -I . -I ../Common -I ../Shared -c -MMD -MF Timer.d -o Timer.o Timer.c Compiling Hardware.c ... avr-gcc -Os -Wall -Werror -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wunused -Wcast-qual -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DCFG_CPU_CLOCK=16000000 -mmcu=atmega128 -I . -I ../Common -I ../Shared -c -MMD -MF Hardware.d -o Hardware.o Hardware.c Compiling Sensors.c ... avr-gcc -Os -Wall -Werror -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow -Wunused -Wcast-qual -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -DCFG_CPU_CLOCK=16000000 -mmcu=atmega128 -I . -I ../Common -I ../Shared -c -MMD -MF Sensors.d -o Sensors.o Sensors.c Assembling memcpy_EP.S ... avr-gcc -DCFG_CPU_CLOCK=16000000 -mmcu=atmega128 -I . -I ../Common -I ../Shared -c -o memcpy_EP.o memcpy_EP.S Linking i2c-Sensor.elf ... avr-gcc -mmcu=atmega128 -Wl,-Map,i2c-Sensor.map i2c-slave-boot.o Delay.o Timer.o Hardware.o Sensors.o memcpy_EP.o -o i2c-Sensor.elf /usr/local/avr-toolchain-2006.1/lib/gcc/avr/3.4.5/../../../../avr/lib/avr5/crtm128.o: In function `__bad_interrupt': ../../../../crt1/gcrt1.S:123: undefined reference to `main' make: *** [i2c-Sensor.elf] Error 1 [fokumdt@iodine i2c-Sensor]$ avr-nm i2c-Sensor.o avr-nm: 'i2c-Sensor.o': No such file > > Hi Daniel, > > On 6/13/07, fo...@it... <fo...@it...> wrote: >> I am trying to compile a program for the robostix with I2C support, and >> I >> am getting the following error: >> >> +++++++ >> [fokumdt@iodine i2c-Sensor]$ make >> Creating svn-version.h ... >> make: Circular i2c-Sensor.elf <- i2c-Sensor dependency dropped. > > This warning is significant. It suggests that you somehow have a > circular dependency. > >> In function `__bad_interrupt': >> ../../../../crt1/gcrt1.S:123: undefined reference to `main' >> make: *** [i2c-Sensor.elf] Error 1 > > There is a main function in i2c-io.c. > > If you do "make v=1" it will show the complete command line being > used. If you're not linking in i2c-io.c and you're replacing it with > i2c-Sensor.c then it will need to proviode a main function which does > more or less the same stuff that i2c-io.c does. > > You can find out whether your file is exporting the main function or > not by running: > > avr-nm i2c-Sensor.o > > I've done this for i2c-io.o below: > >>avr-nm i2c-io.o > U __do_clear_bss > U __do_copy_data > 0000003e a __SP_H__ > 0000003d a __SP_L__ > 0000003f a __SREG__ > U __stack > 00000000 a __tmp_reg__ > 00000090 T __vector_33 > 00000001 a __zero_reg__ > 0000000e D gDDR > 00000000 D gPIN > 0000001c D gPORT > U gTickCount > U I2C_SlaveBootHandler > U I2C_SlaveBootInit > U I2C_SlaveBootProcessCommand > U InitHardware > 00000000 T main > 000000e2 T ProcessCommand > > The symbols with numbers beside them are actually defined. > > T = public function > t = static function > U = undefined (i.e. a reference to an external function or variable). > D = public variable > d = static variable > > As you can see main is listed. > > So, do an avr-nm on i2c-Sensor.o and also do the following: > > make clean > make v=1 > > and show us the output. If you want to send me the Makefile, I can > figure out what the circular reference is about. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > > > ------------------------------ > > Message: 4 > Date: Wed, 13 Jun 2007 19:56:06 +0300 > From: "Demetris Zavorotnichenko" <fgc...@cy...> > Subject: [Gumstix-users] See Revision > To: "'General mailing list for gumstix users.'" > <gum...@li...> > Message-ID: <200...@de...> > Content-Type: text/plain; charset="us-ascii" > > How can I see the current revision on Gumstix? Is there a way ? > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 5 > Date: Wed, 13 Jun 2007 19:57:43 +0300 > From: "Demetris Zavorotnichenko" <fgc...@cy...> > Subject: [Gumstix-users] Show Revision ? > To: "'General mailing list for gumstix users.'" > <gum...@li...> > Message-ID: <200...@de...> > Content-Type: text/plain; charset="us-ascii" > > How can I see the revision of the buildroot that I have on my gumstix ? > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 6 > Date: Wed, 13 Jun 2007 17:57:50 +0100 > From: Colin Sauze <cj...@ab...> > Subject: [Gumstix-users] UARTs on breakout-gs, which is which? > To: gum...@li... > Message-ID: <467...@ab...> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Can anyone tell me which UART on the breakout-gs is which? On my > breakout-gs its not obvious, I have a set of 4 holes labelled > gnd,txd,vcc and rxd near the power connector but on the other side of > the board. > > Then I have holes labelled bt_uart at the top of the board (the top when > holding it so the power/usb are at the bottom). These are labelled > GND,TXD,VCC,RXD,RTS,CTS. > > Then on the other side (same side as the power and usb connectors) I > have two sets just labelled RXD,VCC,TXD and GND. > > Can anyone tell me which is which? Are all four uarts exposed? According > to the wiki the breakout-gs only has 3 uarts? Are there still 3 usable > uarts when a cfstix is in use? > > -- > Colin Sauze > PhD Student, Intelligent Robotics Group > Department of Computer Science > University of Wales, Aberystwyth > SY23 3DB, United Kingdom > http://users.aber.ac.uk/cjs06 > > > > > ------------------------------ > > Message: 7 > Date: Wed, 13 Jun 2007 10:07:49 -0700 > From: "Dave Hylands" <dhy...@gm...> > Subject: Re: [Gumstix-users] GPS Stix Usb Client Failure > To: "General mailing list for gumstix users." > <gum...@li...> > Message-ID: > <c32...@ma...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Arethm > >> Small Update: >> I mucked around last night and got a little further in answering my own >> question. >> Apparently the MAX823 connects to the Y0_CTX (X_CTS on the hirose and >> FF_CTS on the CPU) GPIO35. It keeps the USB host from trying to talk to >> the gumstix before the boot sequence is done. > > Actually, the MAX823 is a reset monitor chip, designed for reseting a > processor when the voltage goes too low. However, on this situation, > it's being used to detect when voltage is present on the USB VBUS > line. > > So the /RESET signla is an output from the 823, and Y0_CTS (aka GPIO > 35) is configured as an input to detect when voltage is present or > not. Aside: with the bead present and being powered by V-BATT, the > gumstix will always detect a voltage. > > Y0_RTS (aka GPIO 41) is used to pullup the D+ line, which tells the > host that a device is present. > > So you should be able to test these manually: > > modprobe proc_gpio > cat /proc/gpio/GPIO35 > > You should see that it's configured as a GPIO and is zero when no > cable is present and 1 when plugged into the host. > > Doing: > > echo "GPIO out set" > /proc/gpio/GPIO41 should make the host think > that the device is there, and echo "GPIO out clear" > > /proc/gpio/GPIO41 should make the host think that the cable is plugged > in. You should confirm that approx +5 v is present on the VBUS line as > well. > > If GPIO35 doesn't react properly when you plug and unplug the cable, > then that would tend to indicate that 823 chip is blown/damaged. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > > > ------------------------------ > > Message: 8 > Date: Wed, 13 Jun 2007 10:10:55 -0700 > From: "Dave Hylands" <dhy...@gm...> > Subject: Re: [Gumstix-users] Fwd: Problem with robostix adc input > shutting down > To: "General mailing list for gumstix users." > <gum...@li...> > Message-ID: > <c32...@ma...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Esger, > >> I'm convinced it is not a software problem as the robostix program is 1. >> very >> simple, and 2. is still running and reporting the other inputs correctly >> when >> the brake is stuck at zero. > > Also, the ADC inputs are run through a MUX internally and there is > really only one A/D converter with a MUX front-end, so that the fact > that some of the channels work means that the A/D itself is probably > fine. > > The MUX could have damaged inputs (say due to a static discharge). > > You could have a cold solder joint (often affected by temperature), or > other hardware problem with the board/circuitry. > > What code are you using to read the A/D converter on the robostix? > Obviously, passing in a bad channel number could cause interesting > things to happen (the A/D can interpret the inputs as differential > channels plus some other modes). > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > > > ------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > > ------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > End of gumstix-users Digest, Vol 14, Issue 80 > ********************************************* > |
From: Dave H. <dhy...@gm...> - 2007-06-13 17:51:45
|
Hi Daniel, On 6/13/07, fo...@it... <fo...@it...> wrote: > Hi Dave, > > Thanks for your response. The i2c-Sensor.c file does indeed have a main > function, but for some reason this file isn't being compiled. I have > attached my i2c-Sensor* files and the Makefile. The output of the > commands that you suggested also appears below. This line in your Makefile: MAIN_OBJS = i2c-Sensor should read: MAIN_OBJS = i2c-Sensor.o make is kind of fussy that way :) -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |