#avr Logs

Jul 13 2017

12:08 AM day is now known as daey
03:52 AM JanC_ is now known as JanC
03:54 AM Emil: xentrac: I reset the tv to good values
03:55 AM Emil: tv.tv_sec=60; tv.tv_usec=0
04:09 AM Thrashbarg_ is now known as Thrashbarg
05:49 AM vishwin60 is now known as vishwin
11:36 AM bss36504: The fuck are you talking about? Did I miss a link somewhere?
11:37 AM xentrac: Emil: ah, thought you meant "reset" in another sense
11:37 AM xentrac: so none of the fds actually have any data to read on them?
11:37 AM xentrac: maybe you didn't respond to the previousselect notification by reading the data
12:19 PM Emil: xentrac: I'm doing a read on the fd directly after I get from select
12:28 PM xentrac: and it's blocking/failing with EAGAIN?
12:51 PM Emil: I should print errno. I have a wrapper that blocks if errno is such that it's relevant to block
12:51 PM Emil: xentrac: do you have a minimal example of watching an fd and lets say stdin?
01:02 PM xentrac: not handy
01:02 PM xentrac: maybe you should run your program under strace
01:33 PM Emil: I did :D
01:33 PM Emil: Select returns instantly as does read :D
01:36 PM Jartza: oh
01:36 PM Jartza: it seems MAX31856 is much better than MAX31855
01:37 PM Jartza: better protections and filtering and such
01:37 PM Jartza: also, more accuracy by providing the extra bias line
01:37 PM Jartza: and it also supports different types of thermocouples
02:03 PM LeoNerd: Emil: still having trouble?
02:04 PM Emil: LeoNerd: if you have pointers I'll gladly take them
02:04 PM LeoNerd: Show code?
02:04 PM Emil: Hmm
02:04 PM Emil: Let me see if I have a picture of
02:04 PM Emil: I ended up ripping the select just away :D
02:05 PM LeoNerd: select isn't hard to use...
02:05 PM Emil: I know
02:05 PM LeoNerd: Was probably some fairly minor mistake
02:06 PM Emil: https://emil.fi/jako/kuvat/2017-07-13_21-36-20_q8am9rIC.png
02:07 PM Emil: You can tell it's a result of debugging it :D
02:12 PM Emil: LeoNerd: anything wrong with the usage? Sure checking for i<(sock+1) is ub but I was desperate :D
02:12 PM Emil: no sorry
02:12 PM Emil: it's absolutely right to do that
02:12 PM Emil: nvm
02:13 PM xentrac: Emil: what did it say under strace?
02:14 PM Emil: xentrac: accept instantly returns
02:14 PM Emil: time left 59.99999
02:14 PM Emil: as does read, which is expected
02:16 PM xentrac: can you pastebin the part from one select to the next select?
02:17 PM Emil: ?
02:17 PM Emil: SURE
02:17 PM Emil: sure*
02:20 PM Emil: xentrac: https://emil.fi/jako/koodi/select.c
02:38 PM rue_house: I think the code could be stretched more vertically if you use a seperate line for the semicolon
02:38 PM rue_house: you could also break out the for into atleast 5 lines
02:38 PM theBear: blank lines are good for vertical stretch... also double-height fonts or half-res displays :)
02:39 PM rue_house: we could make this code to prompt the invention of the motorized scroll wheel
02:39 PM rue_house: }
02:39 PM rue_house: else
02:39 PM rue_house: {
02:40 PM rue_house: that is a great way to get that verticle stretch really going...
02:40 PM rue_house: but
02:40 PM rue_house: if(r>0)
02:40 PM rue_house: _could be_
02:40 PM rue_house: if
02:40 PM rue_house: (
02:40 PM rue_house: r>0
02:40 PM rue_house: )
02:40 PM xentrac: Emil: I don't understand what unexpected behavior you're seeing
02:41 PM Jartza: Emil: umm... what you're trying to do?
02:41 PM xentrac: select returns immediately and tells you you have readable data, and you read it, and read successfully reads the data, because there was some?
02:41 PM xentrac: that sounds entirely correct
02:41 PM xentrac: also I don't see an accept in here
02:42 PM xentrac: maybe you meant select
02:44 PM rue_house: http://paste.debian.net/976382/
02:47 PM rue_house: but apparently I ditched that method in favor of a seperate thread that did a blocking read of 1 byte
02:48 PM rue_house: Select might not work right if you dont SET THE FILE HANDLE you want to monitor
02:49 PM rue_house: if its sock, I dont see the zero after it
02:52 PM LeoNerd: Emil: some strace results might be useful
02:53 PM LeoNerd: Also I've no idea what this "shortread" thing is
02:55 PM LeoNerd: Emil: also, why this incredibly odd for loop, looking for one socket? Why not just cut the whole thing down to if(FD_ISSET(sock, &set)) ... ?
02:57 PM Emil: xentrac: select doesn't select :D
02:57 PM Emil: Jartza: not use the whole cpu core :D
02:57 PM Emil: xentrac: there is no data
02:58 PM Emil: xentrac: whatcha mean by accept? you asked for that part
02:59 PM Emil: LeoNerd: 2017-07-13 21:36:35 +0300 < Emil> You can tell it's a result of debugging it :D
03:00 PM Emil: xentrac: maybe you you didn't read? ;)
03:11 PM Jartza: Emil: yeah, but what are you reading?
03:14 PM Emil: Jartza: a socket
03:15 PM LeoNerd: Yah this really shouldn't be hard. Either oyu're doing something wrong or internally this thing is working in a really odd way. Can't tell ye
03:15 PM LeoNerd: t
03:15 PM LeoNerd: Can we get a strace log of what it's doing?
03:16 PM Jartza: well, if using select() for socket, it returns when recv() would succeed without blocking
03:16 PM Jartza: are you sure you have blocking socket?
03:16 PM LeoNerd: That shouldn't matter
03:17 PM Jartza: also, every time select() returns for socket, you must call recv(), or else the next select will just return immediately
03:17 PM LeoNerd: If it's tightlooping, it means select() is never waiting, because the socket is always ready. Maybe it's at EOF condition or closed or some sort of error or whatever
03:17 PM Jartza: if recv() returns without data, that's an indication of closed socket
03:17 PM LeoNerd: But without strace log we're just guessing
03:17 PM LeoNerd: So lets stop until we have hard data
03:17 PM Jartza: sure
03:19 PM Emil: LeoNerd: hmmm
03:19 PM Emil: LeoNerd: that might be it
03:20 PM Emil: Jartza: no, it's not
03:20 PM Emil: unless recv is special from read
03:20 PM LeoNerd: Nope
03:20 PM LeoNerd: read() is perfectly allowable even on a socket
03:20 PM Emil: yeah
03:21 PM LeoNerd: read() should behave like recv() with flags=0 on a socket
03:21 PM Emil: but hmm, it's probably the closed sock
03:21 PM LeoNerd: That's an often-overlooked condition for simple loops, yes. You forget to handle the EOF case
03:22 PM Jartza: yeah, EOF:ed socket always returns, and never blocks
03:22 PM Jartza: I mean, reading it
03:23 PM Emil: But hmm
03:23 PM Jartza: so also select() always returns
03:23 PM Emil: shouldnt read return -1 then
03:23 PM LeoNerd: It should
03:23 PM LeoNerd: Lets see strace. really
03:24 PM LeoNerd: I am tired of blindly guessing
03:25 PM Jartza: yeah, strace would help
03:30 PM Jartza: also. thermocouple reads are MUCH more accurate when placing 10nF cap from T+ and T- to GND, and 0.1uF cap between T+ and T-
03:32 PM Jartza: strangely the MAX31855 datasheet doesn't have that suggestion, but MAX31856 suggests it
03:33 PM xentrac: read() is allowable on a socket under Unix, but not under e.g. VMS or MS Windows
03:33 PM theBear: maybe they didn't work it out till just before they released the 31856 <grin>
03:33 PM theBear: maybe it's the same chip cos they too embarrased to release a update tot he datasheet <cheeky grin>\
03:34 PM xentrac: Emil: if you have an EOF on the fd, it will select as readable, because you can read EOF on it, and then if you read(), read() will return a zero-length read, which is to say EOF
03:35 PM xentrac: that's why I asked you for the strace output from one select to the next an hour and 20 minutes ago
03:35 PM xentrac: sorry, two hours and twenty minutes ago
03:35 PM xentrac: no, got it right the first time
03:36 PM Emil: Ah it was like that
03:36 PM Jartza: theBear: well, it's not same chip :) max31856 does a lot more
03:36 PM Jartza: and even has more pins
03:36 PM Jartza: 31855 is 8 pin, 31856 is 14 pin
03:37 PM julius: hi
03:38 PM Jartza: hallo
03:38 PM Emil: xentrac: hmm
03:39 PM Jartza: well. I'm probably gonna use these 31855 anyway as I already have them :P
03:39 PM Emil: xentrac: so for a blocking fd, read should return 0 only on EOF?
03:40 PM xentrac: in fact for both blocking and nonblocking
03:40 PM Emil: ah true
03:41 PM xentrac: it would have made more sense for nonblocking reads to return 0 when no data was available, but 0 already meant EOF
03:41 PM Emil: no it's okay because we have errno
03:41 PM Emil: I think errno is a shitty solution though
03:41 PM xentrac: so they added EWOULDBLOCK and therefore six zillion special cases to not return errors in that case
03:41 PM xentrac: so do its designers; that's why Golang uses multiple return values instead
03:42 PM Emil: It should be that we pass a pointer to some value/struct that the syscall modifies when necessary
03:42 PM Emil: rather than editing a global errno
03:42 PM LeoNerd: xentrac: If I had a time machine, one thing I'd do is go back to add an errno==EEOF for that exact case :)
03:42 PM Emil: "global"
03:42 PM LeoNerd: -1/EEOF for end of file, and 0 just means "eh, nothing currently"
03:42 PM xentrac: what the actual system call does on Linux is that it returns a negative number, Emil
03:43 PM Emil: xentrac: yes, but to know what error it was you have to check errno
03:43 PM xentrac: LeoNerd: I guess that would make somewhat more sense, but EOF isn't really an error in most cses
03:43 PM Emil: from a programmers standpoint it is
03:43 PM xentrac: Emil: no, it returns the negative number of the error
03:43 PM LeoNerd: It's an error in the sense of "here is the reason why I cannot perform your request"
03:43 PM Emil: xentrac: read what I write :D
03:43 PM theBear: ahh, the joys of binary numbering systems
03:44 PM xentrac: Emil: this is the second time today you've responded to me insultingly after I helped you debug your problem
03:44 PM theBear: "open your effing eyes, and listen to me as hard as you effing can !" <grin>
03:44 PM Emil: xentrac: the man page is clear
03:44 PM Emil: xentrac: on error -1 is returned and errno is set
03:44 PM xentrac: the man page doesn't document the system call but the glibc wrapper around it
03:44 PM xentrac: please don't mistake your ignorance for superior knowledge
03:45 PM Emil: xentrac: I used the wrong term above
03:46 PM xentrac: multiple return values are a better approach than a pointer argument
03:48 PM Emil: I agree
03:49 PM xentrac: an approach used by some mainframe systems which I am not fond of is to report success by incrementing the return address before returning
03:50 PM xentrac: but it does avoid accidentally running the same code path in success and error cases
07:33 PM Tom_itx is now known as Tom_L
08:30 PM BongoShaftsbury: what gauge wire is usually used for prototyping?
08:32 PM JanC_ is now known as JanC
08:35 PM theBear: erm, appropriate :-) maybe 24ish gauge single core for breadboard kinda things, plus that's basically standard non-strandard cat-anything cable (like old phone lines/alarm wire/cat3/4/5, etc etc)
08:37 PM BongoShaftsbury: yeah i'm looking to buy some spools for breadboads
08:38 PM BongoShaftsbury: any tips for working with reed switches? i am seeing that a lot of people say they are fragile
08:47 PM theBear: ummm, they shouldn't be, unless they glass ones, most i seen are in little screw-mount plastic packages for alarm kinda stuff, or little dip ic packages for teeny ones
08:48 PM BongoShaftsbury: they are glas
08:48 PM BongoShaftsbury: s
08:49 PM Tom_L: glass breaks
08:53 PM BongoShaftsbury: yeah
09:42 PM Jartza: hmmh
09:42 PM Jartza: http://i.imgur.com/nWaXBeV.png
09:44 PM theBear: Tom_L, and silicone hubs ?