Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
LunaVorax has quit [Ping timeout: 260 seconds]
Patero-ng has joined #qi-hardware
<Patero-ng> is anyone here from UT
<qi-bot> [commit] Werner Almesberger: components/tps6216x.lib: add 9th pin for center pad (AGND) (master) http://qi-hw.com/p/kicad-libs/435a339
<qi-bot> [commit] Werner Almesberger: tornado/cpu/: new version of the CPU board (WIP) (master) http://qi-hw.com/p/UNNAMED PROJECT/87b1fbb
<qi-bot> [commit] Werner Almesberger: tornado/cpu/cpu.brd: improve 3V3 routing (master) http://qi-hw.com/p/UNNAMED PROJECT/0e9b093
<qi-bot> [commit] Werner Almesberger: tornado/cpu/cpu.sch: split overly crowded sheet into two (master) http://qi-hw.com/p/UNNAMED PROJECT/ed61eab
<qi-bot> [commit] Werner Almesberger: tornado/cpu/: rearrange things and fix ERC problems (master) http://qi-hw.com/p/UNNAMED PROJECT/9081d91
<kristianpaul> rearrange sounds big
<wpwrak> naw, just making it look better. the hard one was the split
<kristianpaul> split is not just drag and drop then? ;-)
<wpwrak> it's cut and paste, followed by converting local labels to global labels, giving them a direction, moving them to the right place (local labels and global labels go to different locations with respect to the wire), and then fixing the component references
<kristianpaul> :-\
<wpwrak> messy work. not difficult but many little things
woakas has joined #qi-hardware
<kristianpaul> yeah need to track of all of then..
urandom__ has quit [Quit: Konversation terminated!]
pcercuei has quit [Ping timeout: 252 seconds]
<Patero-ng> is anyone here from UT
emeb has quit [Quit: Leaving.]
panda|x201 has joined #qi-hardware
<xiangfu> qi-hardware.com don't have ipv6. right? ping6 give 'unkonwn host'
<xiangfu> the 'miredo - Teredo IPv6 tunneling for Unix' works just fine in my ubuntu system.
<kristianpaul> seems dig aaaa return nothing ipv6 indeed
<kristianpaul> dig aaaa qi-hardware.com i meant
<xiangfu> ok
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer06 has joined #qi-hardware
fire has quit [Read error: Operation timed out]
panda|x201 has quit [Ping timeout: 252 seconds]
fire has joined #qi-hardware
<kyak> how long do you think it takes kernel to set the desired speed of serial port (cfset(o|i)speed)?
<kyak> or, how i can measure it?
<kyak> i suspect that my application start communicating with device connected via serial before the communication speed has settled
<wpwrak> which side is changing the speed ? and what is your port like - via usb ?
<kyak> so i set 115200 for example, and my external device does a simple echo. And i see that send/receive soem crap.. If i do "stty 115200 -F /dev/ttyACM0" before communications, everything is fine
<kyak> the host side is changing the speed, and yes it's serual over USB
<kyak> the target side has a fixed UART speed - 115200
<wpwrak> and then, what tcsetattr actions argument to you use ?
<kyak> (well, i said it so)
<wpwrak> s/to/do/
<qi-bot> wpwrak meant: "and then, what tcsetattr actions argument do you use ?"
<kyak> one se
<kyak> c
<wpwrak> TCSAFLUSH should be what you want
<wpwrak> in case there's garbage in the receiver
<kyak> i use tcsetattr(fd, TCSANOW, &sTermios);
<kyak> ok, i'll have a look whats different between TCSANOW and TCSAFLUSH
<wpwrak> TCSANOW is the worst choice :) that gives you no synchronization at all
<wpwrak> still shouldn't cause data sent after the tcsetattr to be messed up, though
<kyak> i'll definitely try with TCSAFLUSH to see if it makes any difference, thanks for the hint!
<kyak> btw, i even implemented the "suck off all the garbage from UART before sending actual data" feature on target side, but it doesn't seem to help
<wpwrak> maybe the garbage is already sitting in the receive buffer at the host side
<kyak> this is possible
<kyak> in fact, it is very likely...
<wpwrak> then a good flush will take care of that :)
<kyak> i'm also using cfsetispeed and then cfsetospeed instead of just a single cfsetspeed. Could it be a problem?
<kyak> or everything takes effect after tcsetattr?
<wpwrak> do you set different rates or are they the same ? in the latter case, there shouldn't be a problem
<kyak> the same, of course
<kyak> another idea could be to disable receive and send buffer on host side (if the driver allows to), is it a bad idea? :)
<wpwrak> yes, the cf... only change the parameters you'll later apply with tcsetattr?
<wpwrak> s/?//
<wpwrak> not sure you can do that. in any case, a flush eliminates these issues. after that, the buffers are transparent.
<kyak> ok.. now that you gave me ideas i will try that later in the evening. Thanks again!
<wpwrak> no problem. happy experimenting ! ;-)
<kyak> btw, serial programming howtos (like this one http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/x115.html) all give examples with TCSANOW, i think this is where i took it from without thinkinh
<wpwrak> depends a bit on what you do. in general, if you're starting from an unknown state, you want to flush. then, when done and you want to restore the original settings, you can use TCSANOW if you're sure you're synchronized. otherwise drain or flush.
<wpwrak> synchronized = tx and rx buffer are empty. e.g., if the other side acks the data you send, including the last packet/whatever you just sent.
<kyak> yeah, this is definitely not my case - i'm not synchronized
<kyak> btw, what would be the default speed of serial device when it's plugged in? i noticed that when i call "stty 115200 -F /dev/ttyACM0", and then replug the device, then "stty -F /dev/ttyACM0" indicates the speed is 115200
<kyak> i'm not sure if i can trust that and if it persists across reboots of host
<wpwrak> hmm, not sure there's a single default speed
<kyak> as a side topic, i discovered that there is no way to debug baud rate issues using a loopback jumper on my USB-serial converter :)
<wpwrak> in any case, it's easy enough to set the speed you want. so you should do that :)
<kyak> since the baud rate i set is always "correct"
<wpwrak> ;-)
<wpwrak> you can try an oscilloscope
<wpwrak> or a very very long jumper cable :)
<kyak> heh, right :)
fire is now known as megharsh
xiangfu has quit [Quit: leaving]
xiangfu has joined #qi-hardware
xiangfu has quit [Client Quit]
xiangfu has joined #qi-hardware
xiangfu has quit [Client Quit]
xiangfu has joined #qi-hardware
wolfspraul has joined #qi-hardware
wolfspra1l has quit [Ping timeout: 252 seconds]
_whitelogger has joined #qi-hardware
unclouded has quit [Ping timeout: 245 seconds]
panda|x201 has joined #qi-hardware
LunaVorax has joined #qi-hardware
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 260 seconds]
megharsh has quit [Quit: WeeChat 0.3.9.2]
fire has joined #qi-hardware
panda|x201 has quit [Remote host closed the connection]
kuribas has joined #qi-hardware
Hoolxi has joined #qi-hardware
Hoolxi has quit [Remote host closed the connection]
urandom__ has joined #qi-hardware
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
norg_ has joined #qi-hardware
fire has quit [Quit: WeeChat 0.3.9.2]
fire has joined #qi-hardware
Patero-ng has left #qi-hardware [#qi-hardware]
GNUtoo has joined #qi-hardware
pcercuei has joined #qi-hardware
erikkugel has joined #qi-hardware
DocScrutinizer06 is now known as DocScrutinizer05
xiangfu has quit [Quit: leaving]
zrafa has joined #qi-hardware
zrafa has left #qi-hardware [#qi-hardware]
emeb has joined #qi-hardware
fire has quit [Read error: Operation timed out]
jekhor has joined #qi-hardware
pcercuei has quit [Quit: Bye]
fire has joined #qi-hardware
jekhor has quit [Ping timeout: 250 seconds]
pcercuei has joined #qi-hardware
<GNUtoo> larsc, hi
<larsc> GNUtoo: hi
<GNUtoo> does the xf86-video-glamo do rotation in software or in hardware
<larsc> hardware
<GNUtoo> because I've that: http://paste.debian.net/219597/
<larsc> iirc
<GNUtoo> for xf86-video-omapfb
<GNUtoo> ok
<larsc> but the last time I lokked at xf86-video-glamo was about 3 years ago
<GNUtoo> and the way that works is flawed....it change the resolution
<GNUtoo> the other way, the image is not rotated
<GNUtoo> like the image is 640x480 but goes far over the screen on the right
<GNUtoo> thanks a lot for the answer btw
<qi-bot> [commit] Werner Almesberger: tornado/led/: update schematics for new power distribution (master) http://qi-hw.com/p/UNNAMED PROJECT/d278ebb
<qi-bot> [commit] Werner Almesberger: tornado/led/led.cmp: update for new components and changed references (master) http://qi-hw.com/p/UNNAMED PROJECT/bf2e2c3
<qi-bot> [commit] Werner Almesberger: tornado/led/: layout for new LED board version (master) http://qi-hw.com/p/UNNAMED PROJECT/352779a
<qi-bot> [commit] Werner Almesberger: tornado/led/led.brd: clean up layout (master) http://qi-hw.com/p/UNNAMED PROJECT/12fc6cc
<qi-bot> [commit] Werner Almesberger: tornado/cpu/cpu.brd: include subsystem name (CPU) in text label (master) http://qi-hw.com/p/UNNAMED PROJECT/b75570a
fire has quit [Quit: WeeChat 0.3.9.2]
fire has joined #qi-hardware
<larsc> iirc, it would not work otherwise
LunaVorax has quit [Ping timeout: 260 seconds]
pcercuei has quit [Ping timeout: 256 seconds]
pcercuei has joined #qi-hardware
fire has quit [Quit: WeeChat 0.3.9.2]
megharsh has joined #qi-hardware
jow_laptop has quit [Remote host closed the connection]
jekhor has joined #qi-hardware
unclouded has joined #qi-hardware
<GNUtoo> larsc, ok
<GNUtoo> I'll write to xorg devel mailing list for my issue
GNUtoo has quit [Quit: Program received signal SIGSEGV, Segmentation fault.]
LunaVorax has joined #qi-hardware
rz2k has joined #qi-hardware
GNUtoo-desktop has joined #qi-hardware
erikkugel has left #qi-hardware [#qi-hardware]
jekhor has quit [Ping timeout: 260 seconds]
<qi-bot> [commit] Werner Almesberger: cameo/templates/mkmk-simple: use "set size ratio -1", not "set size ratio square" (master) http://qi-hw.com/p/cae-tools/9a6772f
GNUtoo-desktop has quit [Quit: [INFO] fsogsmd : received signal -11, exiting.]
pcercuei has quit [Ping timeout: 256 seconds]