From: Steve B. <ste...@gm...> - 2006-01-12 08:54:03
|
> > I'm still trying to figure out the problems I'm having getting the > gumstix to talk to my GPS module (Lassen IQ). > I'm using the same GPS, but with C code instead of directly to the console - the example code here worked straight away, I've modified it to log to a file. I can send my code if you want (it's a bit hacky though, my C skills are lacking). http://www.comptechdoc.org/os/linux/programming/c/linux_pgcserial.html -- Steve Bullock * ste...@gm... * 07977 216406 |
From: Steve B. <ste...@gm...> - 2006-01-12 15:40:50
|
> > In the past I have experimented with the C-style port initialisation, > but recently I've altered my system to use gpsd, so the old C program > has become obsolete. > How's that working? Haven't heard of it before - just did a quick google and it looks interesting. What are you using for the rest of your code? I'm controlling servos via the robostix in response to my GPS signals, using the robostix as basically just a sensor/servo controller. Both sides of the system are coded in C, taking NMEA in on ttys2, then I2C/SPI to the robostix (haven't worked them out totally yet...). Is C the convention for embedded apps? Or is there a more elegant linux-y way? (spot the newbie). |
From: Craig H. <cr...@gu...> - 2006-01-12 18:36:33
|
On Jan 12, 2006, at 7:40 AM, Steve Bullock wrote: >> >> In the past I have experimented with the C-style port initialisation, >> but recently I've altered my system to use gpsd, so the old C program >> has become obsolete. >> > > How's that working? Haven't heard of it before - just did a quick > google and it looks interesting. What are you using for the rest of > your code? gpsd is in the buildroot, and I patched it a while back to work right with the lasseniQ module on a gumstix. It should "just work" out of the box. C |
From: Dan T. <log...@gm...> - 2006-01-12 10:53:16
|
Thanks to you both for your help. Dave's suggestions gave me cause to fiddle with the init script, which I altered as shown in the following link... http://logicalgenetics.com/forums/viewtopic.php?p=3D6192#6192 Basically, I removed some semicolons and instead of piping the output of various commands to /dev/null, I allowed them to be echo'd. I've no idea why this works, or what particular change made it work, but it was obviously some error with my scripting (I'm used to using bash, not sh). In the past I have experimented with the C-style port initialisation, but recently I've altered my system to use gpsd, so the old C program has become obsolete. Cheers, Dan -- Dan Taylor Software Development Engineer, JTL Systems Ltd PhD Student, Reading University, UK http://www.logicalgenetics.com |
From: Dave H. <dhy...@gm...> - 2006-01-12 16:39:15
|
Hi Dan, > Basically, I removed some semicolons and instead of piping the output > of various commands to /dev/null, I allowed them to be echo'd. I've > no idea why this works, or what particular change made it work, but it > was obviously some error with my scripting (I'm used to using bash, > not sh). Heh - Here's the reason why it didn't work. You wrote: echo "blah" > /proc/something > /dev/null; which means the same thing as: echo "blah" > /dev/null You're basically saying send "blah" to stdout. The > /proc/something says "send stdout to /proc/something". The > /dev/null says "No I've changed my mind. Send stdout to /dev/null" So the pins weren't being configured. I think I understand the motivation behind your additional redirection. If you do: echo "AF2 in" > /proc/gpio/GPIO46 then you'll see this message on the console: Set (AF2,in,set) via /proc/gpio/GPIO46 You were probably trying to get rid of this message, but redirection isn't going to work :( This is because the proc_gpio "driver" is using printk to print its output to the console. Now, if you really want to get rid of this output, you can do something like this: save_printk=3D$(cat /proc/sys/kernel/printk) echo 6 > /proc/sys/kernel/printk echo "AF2 in" > /proc/gpio/GPIO46 echo $save_printk > /proc/sys/kernel/printk What this does is tell printk to filter out messages tagged as level 6 (KERN_INFO) or higher. The proc_gpio driver doesn't use any level modifier, so it gets out as KERN_INFO level. You run the risk that any INFO messages printed by other drivers between the echo 6 and the restore will also get lost, but on your embedded system, that's probably pretty unlikely. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Dan T. <log...@gm...> - 2006-01-12 16:44:49
|
I'm an idiot... ...but at least I can move forward with what I'm doing now :o) Dan On 12/01/06, Dave Hylands <dhy...@gm...> wrote: > Hi Dan, > > > Basically, I removed some semicolons and instead of piping the output > > of various commands to /dev/null, I allowed them to be echo'd. I've > > no idea why this works, or what particular change made it work, but it > > was obviously some error with my scripting (I'm used to using bash, > > not sh). > > Heh - Here's the reason why it didn't work. You wrote: > > echo "blah" > /proc/something > /dev/null; > > which means the same thing as: > > echo "blah" > /dev/null > > You're basically saying send "blah" to stdout. The > /proc/something > says "send stdout to /proc/something". The > /dev/null says "No I've > changed my mind. Send stdout to /dev/null" > > So the pins weren't being configured. I think I understand the > motivation behind your additional redirection. If you do: > > echo "AF2 in" > /proc/gpio/GPIO46 > > then you'll see this message on the console: > > Set (AF2,in,set) via /proc/gpio/GPIO46 > > You were probably trying to get rid of this message, but redirection > isn't going to work :( > This is because the proc_gpio "driver" is using printk to print its > output to the console. > > Now, if you really want to get rid of this output, you can do > something like this: > > save_printk=3D$(cat /proc/sys/kernel/printk) > echo 6 > /proc/sys/kernel/printk > echo "AF2 in" > /proc/gpio/GPIO46 > echo $save_printk > /proc/sys/kernel/printk > > What this does is tell printk to filter out messages tagged as level 6 > (KERN_INFO) or higher. The proc_gpio driver doesn't use any level > modifier, so it gets out as KERN_INFO level. > > You run the risk that any INFO messages printed by other drivers > between the echo 6 and the restore will also get lost, but on your > embedded system, that's probably pretty unlikely. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- Dan Taylor Software Development Engineer, JTL Systems Ltd PhD Student, Reading University, UK http://www.logicalgenetics.com |
From: Dave H. <dhy...@gm...> - 2006-01-12 19:15:34
|
Hi Dan, > I'm an idiot... Naaahhh. You learned something (and so did I by doing a little bit of research when I answered the question). I like to say that there's no such thing as stupid questions, just stupid answers. > ...but at least I can move forward with what I'm doing now :o) That's always good. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |