Back
[00:11:44] <rue_house> ?
[00:12:27] <rue_house> Stehe wanted us to write an interactive calculator?
[00:15:45] <Casper> who?
[00:15:58] <rue_house> <studdentt> how should i compile with avr-gcc so that i can see floating point numbers on a serial terminal ?
[00:15:58] <rue_house> <studdentt> i'm using linux ubuntu
[00:16:29] <rue_house> if you turn off join and part messages, maybe you can experience the channel content :)
[00:16:46] <Casper> was watching something
[00:17:04] <Casper> now, X restart time, let's hope it will fix the "f" issue
[00:17:17] <rue_house> I see, not the breathtaking stream of content in our channel tho
[00:17:39] <Casper> if I write "ff" then somehow it take "one character space", same as "fi"
[00:18:00] <Casper> brb
[00:18:32] <Casper> didn't fixed it
[00:24:16] <rue_house> ?
[00:25:42] <Casper> there is a font spacing issue
[00:25:56] <Casper> irc is set to use a monospaced font
[00:26:02] <Casper> but it mix it up
[00:26:50] <rue_house> can you tell which font?
[00:27:09] <Casper> seems to be courrier
[00:28:09] <rue_house> /usr/share/fonts/truetype/
[00:28:11] <Casper> actually, selecting it... make xchat select another one instead
[00:28:41] <Casper> hmmm no truetype folder
[00:28:45] <Casper> interresting
[00:34:23] <Casper> yet... suposelly installed
[00:52:09] <Casper> so I'm surprised my icq account is still active
[00:52:21] <Casper> and hasn'T been compromised, even with the weak password
[00:52:42] * Casper is keeping it only for prosperity
[00:52:49] <Casper> 161xxx ooooooold
[07:13:32] <Lambda_Aurigae> http://idle.slashdot.org/story/15/12/29/0259206/astronaut-tim-peake-calls-the-wrong-number-from-space?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29
[09:27:23] <Jartza> yay
[09:27:35] <Jartza> now finally octapentaveega horizontal scroll is defectless
[09:38:32] <cehteh> Jartza: now screen rotation please :D
[13:26:01] <julius> hi
[13:27:14] <julius> got a sainsmart lcd display which supports automatic switching to av2 when the camera is on, theres a white male connector with 5 pins on the board marked with: GND AV2 GND AV1 ACC but no explanation as to what kind of camera signal is accepted. will it acceot pal/ntsc..any ideas?
[13:27:48] <wondiws> when you hook a VGA monitor to an Arduino, do you really need resistors? When I bypass the resistor, it still does work
[13:31:41] <Casper> julius: a single pin indicate a composite signal, which is ntsc/pal
[13:31:58] <Casper> the monitor most likelly only support one of the 2 standard
[13:33:12] <Casper> wondiws: most likelly need it, the VGA signal is NOT 5V, but 0-0.7V for the 3 colors, the sync signal I am unsure
[13:39:28] <Jartza> hsync + vsync are 5v
[13:39:33] <Jartza> r, g and b are 0-0.7
[13:59:30] <julius> Casper, thx. so im gonna write the support
[14:28:49] <gorroth> Casper: speaking as someone who's not super great at electronics, what would the resistors do? raise the voltage? (V=I*R)
[14:31:09] <Tom_itx> limit current
[14:32:46] <gorroth> oh. so it is really I=V/R
[14:32:50] <gorroth> thanks
[14:33:13] <gorroth> i've been pretty much thinking about it in the latter terms on stuff i'm doing, but i was wondering if it ever works the other way
[14:33:45] <Tom_itx> the formula is the same no matter how you look at it
[14:33:58] <gorroth> it's not the same in terms of how you think about it though
[14:34:19] <gorroth> one implies V is the dependent variable, and the other implies current as dependent
[14:34:34] <Tom_itx> depends what you are trying to find
[14:35:16] <gorroth> i suppose. if you're trying to find the current voltage in the circuit, then V=IR makes sense. but if you're trying to chnage the physical characteristics, it seems like I=V/R makes more sense, since the resistor changes the current limit
[14:35:28] <gorroth> just a way of thinking, and i'm trying to understand what is happening physically
[15:19:30] <studdentt> is this port initialisation correct for i2c? using atmega328p : DDRC |= (1<<PORTC4) | (1<<PORTC5); PORTC |= (1<<PORTC4) | (1<<PORTC5); //PC4 SDA PC5 SCL
[15:19:49] <studdentt> both as outputs and starting at logical 1
[15:54:48] <gorroth> i honestly don't know. i was trying to look through my docs, but it's not too straightforward for i2c setup. i'm guessing AVR calls it TWI?
[16:14:41] <studdentt> goroth: it is yes
[16:54:56] <Yoduza> where is examples for patch china clone usbasp ?
[16:55:13] <learath> china?
[16:55:25] <Yoduza> EU
[16:56:00] <Yoduza> usbasp $1.2 aliexpress free delivery
[16:56:11] <Yoduza> need patch for it
[16:56:25] <learath> I was recommending you ask china.
[16:59:18] <Tom_itx> the trick is to not buy one to begin with
[16:59:28] <learath> true
[17:00:05] <Tom_itx> i built my own using LUFA
[17:00:40] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[18:09:18] <studdentt> help with float to int conversion
[18:09:48] <studdentt> i've broken down a float into 4 bytes but when i recombine, i dont get the decimals, why is that ?
[18:09:52] <Xark> studdentt: Like int val = (int) myfloat;
[18:10:39] <studdentt> Xark : i used test_int_conv[0]=(((uint32_t)test & 0xF000) >> 24 ;
[18:11:05] <studdentt> Xark : then add all the int cells into a float variable
[18:11:23] <Xark> studdentt: Okay, that is wrong (pretty sure). What exactly are you trying to acomplish?
[18:11:32] <Xark> accomplish*
[18:11:40] <studdentt> Xark: writing a float value to an external eeprom
[18:11:57] <studdentt> Xark: so 4 bytes
[18:12:15] <Xark> studdentt: Okay, so you want the raw bit pattern of the float (no "conversion").
[18:12:23] <studdentt> Xark: yes
[18:12:42] <studdentt> Xark:thats why im using & with bitshift
[18:13:32] <Xark> studdentt: I suggest something like: union f2b { float f; uint8_t b[4]; } c; c.f = myfloat; Now you have c.b[0] to c.b[3] as the 4 bytes.
[18:16:00] <studdentt> where does myfloat comes from
[18:16:12] <studdentt> and dont you have to loop to get all bytes ?
[18:20:09] <Xark> studdentt: myfloat is whatever float you are operating on. You may well want to loop or just paste 4 lines for each byte (that is not a "complete" code fragment).
[18:20:59] <Xark> studdentt: However, a "union" basically places all the members "on top" of each other. So we put "in" a float, but then read it out via the bytes (that occupy same memory).
[18:23:22] <studdentt> Xark: you still have to & the float
[18:23:23] <studdentt> ?
[18:23:59] <Xark> studdentt: No
[18:24:29] <Xark> studdentt: That was to "extract" the bytes form a uint32_t (e.g.), this technique breaks them down into bytes (which I assume is what you really want).
[18:24:38] <Xark> from*
[18:25:02] <studdentt> Xark: break the flaot into 4 bytes then recombine these bytes to get a float
[18:26:03] <Xark> studdentt: The exact same trick works in reverse, put in b[0] to b[3] (in same order you got them out) and then c.myfloat will be the combined float.
[18:28:45] <studdentt> Xark: compiler doesnt like it
[18:30:09] <studdentt> can i msg you ?
[18:32:56] <studdentt> Xark: here's the full code
http://pastebin.com/BKn5cZsL
[18:33:33] <Xark> studdentt: That doesn't look "full". I don't even see a function definition...
[18:33:36] <studdentt> Xark: if f and b[]'s are equal, this should work
[18:33:54] <studdentt> Xark: testing from main first
[18:35:37] <Xark> You can't just add the bytes to get the float back. As I mentioned, you need to put them back into the b[] array and then read f
[18:58:21] <studdentt> Xark: it worked, entered the int into b[] and read f
[18:58:32] <Xark> Great. :)
[18:58:38] <studdentt> Xark: so its the compiler that does the work ?
[18:58:55] <studdentt> Xark: thats sort of a lazy solution lol
[18:59:10] <studdentt> but its so elegant
[18:59:27] <Xark> studdentt: Well, okay. Just looking at the same memory locations in two ways. I think ti is one of the "best" way to do it. :)
[18:59:43] <Xark> studdentt: Note that it is non-portable (but for AVR, not a big worry).
[19:00:17] <Lambda_Aurigae> Xark, wouldn't you just have to adjust some for the size of the float on other platforms?
[19:00:51] <Xark> Lambda_Aurigae: And byte order. No biggie, but just mentioning it.
[19:01:11] <Lambda_Aurigae> so long as you keep the byte order the same coming and going that shouldn't be a problem.
[19:01:47] <Lambda_Aurigae> studdentt, yes, it is the lazy way...but C is just a lazy way of writing assembly in commands easier to understand.
[19:02:07] <Lambda_Aurigae> that's why we write compiled languages...to make things easier.
[19:03:35] <studdentt> yes
[19:06:05] <Lambda_Aurigae> unix could well have been written in assembly but Dennis Ritchie wanted something easier so he created C to write Unix.
[19:07:11] <studdentt> i tried the raw bit approach to revise some notions
[19:09:42] <Xark> Lambda_Aurigae: IIRC the first version was. :)
[19:09:50] <Lambda_Aurigae> yeah...early unix was.
[19:10:21] <Lambda_Aurigae> when it was reenvisioned and rewritten for multiple platforms they did it in C,,which was written for that purpose.
[19:34:33] <Lambda_Aurigae> wonderful toys...
[19:34:48] <Lambda_Aurigae> C is my favorite programming language and Unix my favorite OS.
[19:41:08] <Casper> Lambda_Aurigae: yeah yeah, don't lie... visual basic and windows is what you really prefer... :D
[19:41:20] <Lambda_Aurigae> blah.
[19:41:30] <Lambda_Aurigae> I don't even own a copy of windows.
[21:37:31] <Casper> 36 bits... why! ...
[21:38:56] <Xark> Casper: Works great in octal. :)
[21:39:06] <Casper> not in avr storage :D
[21:40:44] * Casper is still wondering how he'll do this...
[21:42:47] <Xark> Casper: What are you referring to?
[21:43:32] <Casper> IR decoding for a remote control for my heat pump
[21:43:40] <Xark> Ahh
[21:43:47] <Casper> it send 4 packets, 36 32 36 32 bits
[21:44:00] <Casper> the first and second is 2 copy, with 1 bit changed
[21:44:10] <Casper> which I find a bit weird
[21:44:26] <dgriffi> what sort of IR decoder module are you using?
[21:44:56] <Xark> Designed for a PDP-10 no doubt. :)
[21:45:07] <Casper> the 3 pins type
[21:45:12] <Casper> for 38kHz
[21:45:58] * dgriffi pricks up at the mention of PDP-10
[21:46:03] <Casper> thing is... it use different width for a 0 and 1 bit
[21:46:48] <Xark> dgriffi: He was mentioning 36-bits. :)
[21:47:24] <dgriffi> strangely enough, my current AVR project involves the PDP-10
[21:48:22] <Xark> Okay, that is somewhat strange. I only mentioned PDP-10 somewhat randomly looking at Wiki page of 36-bit machines. :)
[21:48:56] <Xark> Probably because I was quite fond of free DEC-10 system at UCLA (that my aunt was not supposed to let me use...).
[21:48:56] <dgriffi> Xark: check this out:
https://github.com/DavidGriffith/panda-display
[21:49:34] <dgriffi> Xark: this is a USB device that shows the data bus and some other stuff for the klh10 pdp-10 emulator
[21:49:46] <Xark> Neat.
[21:50:37] <dgriffi> I got the hardware and firmware mostly solidified. I'm working on the emulator tweaks now.
[21:50:46] <Xark> I need to put an AVR into this Altair case in my garage one of these days (the inside is gutted - mouse lived in it, but front panel is in okay shape). ->
https://imgur.com/fZY71kQ
[21:52:10] <Xark> dgriffi: Very cool. I wonder if it can play DECTrek (probably). :)
[21:52:29] <dgriffi> Xark: for your altair, check this page:
http://altairclone.com/
[21:52:55] <dgriffi> Xark: I don't know if he discloses enough information for you to cook up your own clone to fit into a real altair, but it might be worth a shot
[21:53:38] <Xark> dgriffi: All the info is fairly easily available I think. I would probably use an FPGA.
[21:54:18] * Xark doesn't recall the beige top...I thought it was all blue
[21:56:02] <dgriffi> I'm thinking you could distill the functionality of the guts to a seperate board and wire that up to the existing front panel
[21:56:18] <Xark> *Brrr* (cold out there), no, he has it correct (but my original has a lot more dust). :) *cough*
[21:57:18] <Xark> Right, I doubt I would use existing wiring or PCB (or LEDs likely).
[21:57:36] <Xark> With FPGA I can run a few classic systems with blinkin lights
[22:05:22] <dgriffi> there's at least one pdp-10 FPGA design
[22:11:50] <Casper> hmmmm
[22:12:02] <Casper> uint64_t.... is 32 bit?!?!?
[22:12:20] <Casper> (or my code is broken)
[22:14:04] <Casper> I seems to lose the lower 32 bits o.O
[22:19:39] <Xark> ISTR 64-bit is not implement on avr-gcc.
[22:21:39] <Xark> Hmm, double is 32-bit float, but it says sizeof long long is 8 bytes ->
https://gcc.gnu.org/wiki/avr-gcc
[22:22:01] <Xark> I don't see support routines for more than 32-bits, so it may be the type is supported, but not operations on it.
[22:22:44] <Xark> (which would explain missing half the result)
[22:29:46] <Casper> actually, the missing half was a bug in my code, but the data is corrupted...
[22:30:19] <Casper> http://pastie.org/private/g7dbpqe6bu4yrbcnektua <==== you can laught at the ugly code :D
[22:31:04] <Casper> so... that mean I have to split the data into smaller one... grr
[22:33:32] <cehteh> consider using the ISR only to store the result aside, maybe in a queue and handle it synchonously in main
[22:33:49] <Casper> yes, this is for easy debug
[22:34:20] <Casper> and already cause a tiny issue: I have the result only once the timer overflow
[22:34:34] <cehteh> ah btw what you you trying to do . . convert integers to ascii
[22:34:46] <cehteh> i've just writen code for that a few days ago :D
[22:35:05] <Casper> display the bits
[22:35:40] <Casper> this is temporrary code, later on it will just bitmask, shift and store the needed bits
[22:35:43] <cehteh> hehe . that what i did too
[22:35:53] <cehteh> ah
[22:36:09] <Casper> but the first packet is 36 bits, followed by a 32, then a repeat
[22:36:21] <cehteh> well i needed some functions which push left to right on the transmission queue
[22:36:36] <Casper> first 28 bits should be zero... they are 1...
[22:37:48] <Casper> Xark:
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html
[22:38:03] <Casper> it does seems to have 64 bits support
[22:38:26] <cehteh> yes
[22:39:03] <cehteh> i havent looked closely at your code, do you have some coercions to signed int there maybe?
[22:39:15] <Casper> no
[22:40:22] <Xark> Signed int would be 16-bit. :) You need ULL on all constants etc.
[22:40:37] <cehteh> yes
[22:40:59] <cehteh> data[packet] & 8000000000000000) ...
[22:41:01] <Xark> Casper: If you aren't, I suggest -Wall
[22:41:12] <cehteh> + -Wextra
[22:41:18] <Xark> :)
[22:47:20] <Casper> -Wall was already there, nothing
[22:48:19] <Casper> -Wextra give nothing
[23:36:15] <Xark> That is weak if you don't get constant truncated...
[23:45:13] <Casper> Xark: do you see anything in that code that can be wrong?
[23:46:04] <Xark> Well as mentioned 800000000000000 looks wrong (perhaps you want hex and needs ULL suffix)?
[23:47:10] <Casper> ...
[23:47:17] <Casper> I missed cehteh's line...
[23:47:21] <Casper> ...
[23:47:58] <Xark> :)
[23:51:39] <Casper> THANKS!
[23:51:44] <Casper> now... to fix the other bug...
[23:52:54] <Casper> I also have a buffer overflow issue
[23:59:09] <Casper> crap... this is not good...
[23:59:34] <Casper> I have yet another bug, or "copy 1" and "copy 2" is not copy...
[23:59:51] <Casper> meaning that I don't have 36+32 bits to deal with, but 36+32+36+32