Back
[01:15:53] <julius> morning
[01:15:58] <Casper> o/
[01:16:04] <julius> cehteh, are you from germany too?
[01:16:26] <julius> in germany its 07:15
[01:16:47] <Casper> here: 1:52.... am
[01:17:25] <julius> weird, my bouncer says in the last 7 hours, only one person wrote something
[01:17:35] <julius> must be disconnected
[01:17:42] <Casper> julius: seems to be about that
[01:17:48] <julius> oh
[01:18:10] <julius> for 177 people, thats quiet
[01:18:21] <Casper> [18:18:34] <Jartza>
https://www.youtube.com/watch?v=VECIEO941d4
[01:18:21] <Casper> [01:51:09] <julius> morning
[01:18:34] <Casper> it happend
[01:18:55] <julius> hehe
[01:19:15] <Casper> wants some spicy ramens?
[01:19:40] <julius> whats a ramen
[01:20:05] <Casper> what? you don't know what ramen is? where are you living? under a rock? :D
[01:20:15] <Casper> some sort of instant noodles
[01:20:46] <lald> Accusing people of livng under rocks when your only exposure to ramen is the instant kind :P
[01:21:09] <julius> english is not my first language
[01:21:25] <julius> i learned most of it from tv shows like stargate
[01:22:08] <Casper> ラーメン <==== that is how it should be actually written as...
[01:22:23] <lald> Ramen is a Japanese dish, but usually people mean this particular brand which is really cheap and cooks really quickly
[01:22:38] <lald> so its good when you're coding all night and need to eat something quickly
[01:22:55] <Casper> also, when you're a poor student
[01:23:24] <lald> People joke about "living off ramen" but I'm fairly sure you'd starve.
[01:23:30] <Casper> yup
[01:23:39] <julius> ah yes, now i got a picture via google
[01:23:43] <Casper> last year, a student somewhere in the usa tried it...
[01:23:50] <Casper> ... ended up in the ER
[01:23:58] <lald> Sigh.
[01:24:27] <lald> People who've started a business also say they're "ramen profitable" to mean they could live off that income if they only ate ramen.
[01:24:41] <julius> thats funny
[01:24:47] <lald> and that is pretty much everything you ever need to know about ramen :P
[01:25:12] <lald> By the by, your english is excellent.
[01:25:26] <Casper> julius: 25 cents a bag/serving, or even cheaper...
[01:25:56] * Casper wants to learn japanese one day... but too much effort for no purpose
[01:28:31] <lald> Honto?
[01:31:21] <julius> true. if you dont live there finding a reason to learn it could be difficult
[01:33:15] <lald> There is a lot of research suggesting that learning more languages helps you think better.
[01:35:19] <julius> interesting
[02:06:34] <julius> Casper, theres something like japanese, it can also be used to program the kodi media center ;)
[03:38:06] <hetii> :)
[04:06:53] <nuxil> good day
[04:08:28] <nuxil> so i managed to screw up my wireing on my shiftregisters. wireing them so msb becomes lsb. now i need to fix this on my tiny85 by sending the bytes in reverse.
[04:09:04] <nuxil> any suggestion on how i go about reversing a binary number?
[04:17:20] <Snert> if it's not an etched circuit board I would rewire.
[04:23:23] <nuxil> nah.. outof the question. to many wires to move around.
[04:24:32] <nuxil> i found this tho
[04:24:41] <nuxil> http://graphics.stanford.edu/~seander/bithacks.html#BitReverseObvious
[04:24:58] <nuxil> but what is CHAR_BIT ?
[04:26:18] <nuxil> int s = sizeof(v) * CHAR_BIT - 1;
[04:33:36] <Snert> how many shift registers are there in your circuit?
[04:35:56] <nuxil> 3
[04:36:49] <nuxil> http://sprunge.us/bcYF
[04:37:02] <nuxil> -- number of bits for smallest object that is not a bit-field (byte)
[04:37:02] <nuxil> -> CHAR_BIT
[04:37:07] <nuxil> whatever that means :p
[04:37:35] <Snert> It means you'd have your circuit half rebuilt by now.
[04:38:01] <nuxil> lol..
[04:39:13] <nuxil> 8*3 wires that need to be unsoldered and resoldered.
[04:39:57] <nuxil> besides. i take it as a challange to try to fix up my mistake by recoding the tiny.
[04:54:08] <nuxil> http://pastebin.com/k9JcZ6xh got 2 functions now.. which one of these is most effictive ?
[05:04:34] <phinxy> can you -finline-functions in atmel studio?
[05:07:41] <nuxil> no idea.. is anyone using atmel studio ?
[05:18:09] <Flutterbat> do you still have to click multiple times to flash your project? :D
[05:19:59] <Flutterbat> nuxil: how do you feed the registers?
[05:20:06] <Flutterbat> do you use a hardware interface?
[05:20:42] <Flutterbat> maybe it has the option to lsb/msb first
[05:22:58] <phinxy> debug > start without debugging is two click
[05:23:03] <phinxy> or just the hotkey
[05:23:46] <phinxy> What part of the EEPROM is most durable? i need to choose a location for my settings
[05:24:19] <Flutterbat> most durable?
[05:24:43] <Haohmaru> the middle ;P~
[05:24:48] <Flutterbat> phinxy: didnt know there was a hotkey. i was used to the one click in studio4
[05:25:03] <Flutterbat> then switched to avrdude/vim
[05:55:23] <Lambda_Aurigae> phinxy, no part of eeprom is more durable than others...100K writes is the rated lifetime on avr eeprom
[05:55:53] <Lambda_Aurigae> if you have to do a lot of writing to eeprom, use some kind of wear leveling,,,write to different locations with a tag or something showing which is the newest.
[06:04:16] <phinxy> uint8_t EEMEM NonVolatileOdometer[31];
[06:04:17] <phinxy> or
[06:04:18] <phinxy> uint8_t EEMEM NonVolatileOdometer[32];
[06:04:21] <phinxy> for uint32_t
[06:05:46] <phinxy> wait this tutorial is weird. uint8_t SRAMstring[10];
[06:05:48] <phinxy> that aint a string
[06:06:05] <phinxy> wait, yes it is
[06:06:21] <phinxy> with a cast i guess it could be a char
[06:06:57] <Lambda_Aurigae> uint8_t is the same as char...just different name.
[06:07:11] <Lambda_Aurigae> but, yeah, you will have to cast between them.
[06:09:40] <LeoNerd> Aha! I fiiiiinally managed to find some throughhole USB miniB connectors. Should be more physically secure against ripping off the board than these surface mount ones
[06:09:41] <phinxy> and when you define it liek this SRAMstring[10]; its 10 bytes
[06:09:42] <phinxy> not 11
[06:10:14] <Lambda_Aurigae> yes.
[06:10:22] <Lambda_Aurigae> but you can't put a 10 character string in that.
[06:10:34] <Lambda_Aurigae> well, you can, but you have to deal with the terminator being missing.
[06:13:47] <phinxy> always strlen +1
[06:17:47] <lald> What about when the string is ~0 bytes long? :P
[06:18:27] <Lambda_Aurigae> if it is a string it is a minimum of 1 byte...the terminator.
[06:18:42] <Lambda_Aurigae> at least, it is in C
[06:19:01] <Lambda_Aurigae> other languages might deal with it differently but C uses null terminated strings.
[06:19:46] <Lambda_Aurigae> the lack of null termination in strings has been the entry point for a plethora of hacking points too.
[06:19:52] <lald> I meant if the string was INT_MAX bytes long
[06:20:22] <Lambda_Aurigae> irrelevant to the string subsystem I would think.
[06:20:39] <Lambda_Aurigae> but not sure.
[06:20:45] <lald> It'd wrap around to 0
[06:20:53] <Lambda_Aurigae> doubt you would run into those on an avr anyhow.
[06:21:15] <lald> Mmhmm, that'd be all of the memory thats available on my m328p
[06:41:04] <phinxy> anyone who knows basic eeprom stuff could you take a look at this short code?
http://pastebin.com/aLaByMTU
[06:41:56] <phinxy> ive checked the actual eeprom the EEMEM value is written
[06:42:26] <phinxy> but the read fails. (it sets integer to 0)
[06:44:30] <phinxy> only thing i can think of is the castinf
[06:44:59] <phinxy> i understand what its for and what it does but the "const" there is a little suspect, i dont know what its doing
[07:02:31] <Lambda_Aurigae> I would save and read as individual 8bit unsigned integers myself.
[07:03:23] <Lambda_Aurigae> uint32_t eeprom_read_dword ( const uint32_t * __p )
[07:03:25] <Lambda_Aurigae> or that
[07:03:55] <Lambda_Aurigae> void eeprom_update_dword ( uint32_t * __p, uint32_t __value )
[07:04:01] <Lambda_Aurigae> and that for writing new data.
[07:04:40] <Lambda_Aurigae> right out of the avr-libc manual.
[07:34:42] <phinxy> uint32_t EEMEM OdoKm = 2048;
[07:34:44] <phinxy> eeprom_read_dword(&OdoKm);
[07:34:54] <phinxy> returns 0 when i debug and hold mouse over it
[07:38:15] <phinxy> okay now stuff is happening again efter i set fuse eesave to 0
[08:34:01] <cehteh> phinxy: to prevent eeprom wearout you want multiple locations where you store the data rund robin, possibly with a generation counter and checksum
[08:34:23] <phinxy> yup
[08:34:42] <phinxy> the thing is each time i program flash memory the eeprom seems to be set to weird values
[08:34:52] <phinxy> if i press program eeprom its fine after taht
[08:35:13] <cehteh> there is a EESAVE fuse
[08:35:33] <phinxy> i don't see anything weird in eeprom but the display thats supposed to show the eeprom value shows something like -3405
[08:35:41] <phinxy> when i download eeprom everything is FF
[08:35:46] <phinxy> its fine tough
[08:35:51] <cehteh> if that is not programmed, the default, then issung a chip erase before flashing a new version of your program will clear out the eeprom as well
[08:36:11] <LeoNerd> Also don't forget the asymmetry - you can clear 1 bits into 0 bits easier than back again
[08:36:20] <cehteh> so refine ... to my suggestion about round robin .. you want to set EESAVE and store some version number in eeprom
[08:36:31] <LeoNerd> So if you're doing simple counters, consider dedicating maybe 32bytes as a 256-bit tally counter
[08:37:03] <LeoNerd> (or even just 2 bytes as a 16bit one...)
[08:37:14] <cehteh> and there is a note in the datasheet that the first eeprom address might be trashed under some conditions
[08:37:31] <phinxy> LeoNerd aha so you write one bit each save
[08:37:38] <cehteh> if you dont need all eeprom, just start at the 2nd location
[08:38:09] <phinxy> cehteh, thats probably it. thats where its stored
[08:38:41] <cehteh> thats wrong initialization, undervoltage etc
[08:38:47] <cehteh> see datasheet
[08:40:41] <cehteh> http://git.pipapo.org/?p=battswitch.git;a=blob;f=src/battswitch.c#l141 thats how i define simple eeprom data (not round robin, stores calibration values which very rarely change)
[08:43:37] <phinxy> why did you make a struct
[08:44:22] <cehteh> for me just easier to handle this way, the struct is in ram too so i can just read/update it as block
[08:44:41] <LeoNerd> That's how I do it
[08:45:05] <LeoNerd> config in EEPROM, read to RAM on startup, any live edits can be made in RAM and flushed back to EEPROM later if required
[08:45:32] <cehteh> yeah, i prefer that as long there is enough ram
[08:46:34] <cehteh> also array (of struct) in eeprom with different configs .. and one struct in ram, then one loads selected config
[08:46:45] <cehteh> or the array is the base of the round robin thing
[08:47:29] <cehteh> note that programming eeprom takes ages, and reading isnt that fast either (6cycles iirc)
[08:48:41] <cehteh> 6cycles only for the read .. setting up the addresses, calling the read function etc has some more overhead
[12:48:29] <Emil> Hello
[12:49:02] <Emil> On programming an avr with an usbasp, does the data from usbasp come to the miso or mosi of the avr?
[12:56:30] <Jartza> miso = master in, slave out :)
[12:56:47] <julius> both are connected to the programmer
[12:58:09] <Jartza> Emil: AVR chip is always slave when programming and the usbasp (or any other programmer) acts as master
[12:58:24] <Jartza> so, mosi
[12:58:29] <Jartza> slave in
[13:16:39] <Emil> Jartza: thanks!
[13:49:09] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxWk1ycXljLWxzVkk/view
[13:49:17] <Jartza> that 7" vga monitor is pretty cute :)
[13:50:06] <LeoNerd> Mmmm
[13:50:25] <LeoNerd> Though I imagine if you did want a 7" display of some kind in a project, there are easier ones to interface :)
[13:51:43] <Jartza> might be
[13:51:48] <Jartza> got this for free, though
[13:51:55] <LeoNerd> Sure..
[13:52:53] <Jartza> this has nice frame tha allows the monitor to be embedded to multiple places
[13:53:01] <Jartza> like to the wall or so
[13:53:26] <Jartza> and actually octapentaveega font size is quite nice with this size of display :)
[15:06:31] <ub|k> i don't understand this. i'm sending 8 chunks of 1024 bytes from my computer to the atmega32. at some point some bytes are lost
[15:06:56] <ub|k> however, if i echo back the character from the avr to the computer, everything works fine
[15:07:06] <ub|k> maybe something to do with timing?
[15:11:37] <Tom_itx> you have a 1024byte buffer?
[15:12:30] <Tom_itx> A) baudrate has too high an error percentage
[15:12:41] <Tom_itx> B) too much delay between writes
[15:13:04] <ub|k> Tom_itx: the thing is that none of the error bits are set
[15:13:21] <Tom_itx> why would they be?
[15:13:21] <ub|k> Tom_itx: it's actually 256 byte
[15:13:34] <Tom_itx> SD?
[15:13:53] <Tom_itx> no those are 512byte
[15:14:17] <ub|k> what?
[15:14:23] <ub|k> i'm talking about my buffer size
[15:14:55] <Tom_itx> maybe it's lost between buffers
[15:15:05] <Tom_itx> 4 buffers full per chunk
[15:16:13] <ub|k> hm...
[15:16:49] <Tom_itx> what are you doing with the data once it's on the avr?
[15:17:47] <ub|k> actually, i've said it wrong
[15:17:53] <ub|k> 8 chunks of _128_ bytes
[15:17:55] <ub|k> not 1024
[15:18:02] <ub|k> the buffer shouldn't get full
[15:18:20] <ub|k> 8 * 128 = 1024
[15:18:21] <Tom_itx> i'm sending 8 chunks of 1024 bytes from my computer to the atmega32.
[15:18:26] <Tom_itx> which is it?
[15:18:41] <Tom_itx> so 128 bytes
[15:18:47] <ub|k> yeah
[15:20:10] <ub|k> hm... i'm loading the buffer through an interrups
[15:20:13] <ub|k> *interrupt
[15:20:49] <Tom_itx> that's a long time to be in an interrupt
[15:20:59] <ub|k> is it possible that at some point the buffer gets corrupted, with the interrupt being executed
[15:22:02] <ub|k> IIRC, peter fleury's UART lib also loads the buffer from an interrupt
[15:22:10] <julius> in this ws2812 code:
http://paste.pound-python.org/show/6JzSbfFLjvWsZ5eTU5aJ/ i was expecting all leds to go on "at once", sleep 1s, go out, sleep 1s...start
[15:22:18] <julius> but they just stay on...any ideas?
[15:23:42] <Tom_itx> ws2812_setleds(leds, NUM_LEDS);
[15:23:45] <Tom_itx> what's that do?
[15:25:10] <Tom_itx> .g .b don't change
[15:25:23] <julius> sets all the leds defined in "leds"
[15:25:35] <julius> they go on full red
[15:25:36] <Tom_itx> are you setting the whole port at once?
[15:25:39] <julius> yes
[15:25:42] <Tom_itx> .r = 255
[15:26:08] <julius> with ws2812 controllers, you have to send out the combination for all leds at once
[15:26:17] <Tom_itx> where's the setleds code?
[15:26:35] <Tom_itx> and how do you know it works?
[15:26:37] <julius> its from the ws2812 library, which works
[15:26:57] <julius> tested other examples, this is my own logic
[15:27:55] <julius> https://github.com/cpldcpu/light_ws2812
[15:28:32] <julius> thats the code that talks to the controller..but even my "larson" scanner works. so i would assume that the lib is working fine
[15:28:55] <ub|k> so, am i correct that an interrupt that i can run into race conditions if an interrupt and some code that runs in a loop manipulate the same data structure?
[15:29:16] <ub|k> (sorry, that didn't come out right)
[15:29:32] <Tom_itx> in the interrupt, the interrupt is executing
[15:29:41] <Tom_itx> the rest must wait
[15:29:56] <Tom_itx> if you change it again outside the interrupt then shame on you
[15:31:08] <Tom_itx> comment out the bottom code from 26 down and try this
[15:31:53] <Tom_itx> leds[i].r ^= 0xFF
[15:31:59] <Tom_itx> etc for the other 2
[15:32:11] <Tom_itx> try that in one loop by itself
[15:33:09] <Tom_itx> they should blink every 1000 ms
[15:34:57] <julius> for(i=NUM_LEDS; i > 0; i--) {
[15:35:09] <julius> the >= does not work in this case
[15:35:36] <julius> now they blink
[15:35:51] <Tom_itx> what is NUM_LEDS set to?
[15:35:59] <julius> 59
[15:36:11] <julius> because i disconnected one led from the strip, there are 59 leds
[15:36:45] <julius> add the end i added: leds[0].r = 0; to shut down the first led
[15:39:31] <ub|k> okkk... it seems like the problem was really a race condition, Tom_itx. I used ATOMIC_BLOCK(...) around buffer manipulation functions
[15:39:34] <ub|k> works like a charm ;)
[15:44:27] <julius> Tom_itx, i still dont get why the first for loop would work, the one with i=NUM_LEDS; i >= 0; i--
[15:44:43] <julius> i should be getting 0, and then the loop should stop
[16:27:27] <cehteh> julius: compiile with -Wall -Wextra
[16:27:39] <cehteh> i bet the compiler will point out the bug .. i see it :D
[16:29:04] <cehteh> err .. i should read all
[16:32:30] <Jartza> well
[16:32:37] <Jartza> looks like my 7" monitor didn't like my combined sync
[16:32:50] <Jartza> or it does, but I have to drive it in wrong polarity, so it doesn't like that
[16:33:03] <Jartza> added another led to my attiny5 so I can separate hsync and vsync again :)
[16:34:22] <cehteh> when do you do hdmi?
[16:34:40] <julius> uh, -wextra is evil
[16:35:03] <cehteh> -W
[16:35:08] <cehteh> why? i always use it
[16:35:12] <cehteh> often with -Werror
[16:38:17] <julius> it says my code is all fucked uo ;)
[16:39:28] <julius> uh, now i see it
[16:39:40] <julius> it complains that the library im using is not so good
[16:41:35] <julius> http://paste.pound-python.org/show/dA7q7qFBEXPJiAWbJbmg/
[16:41:42] <julius> it starts complaining at line 19
[16:41:53] <julius> Light_WS2812/light_ws2812.c:19:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
[16:42:17] <julius> is it "inline void" instead of "void inline" ?
[16:46:36] <nuxil> julius, i think so. inline void blah...
[16:50:13] <julius> ah nice, now it compiles cleanly
[16:51:08] <nuxil> hows your led experiment going?
[16:53:36] <julius> for(i=NUM_LEDS; i >= 0; i--) { now i get it, it will never go to -1 because of the data type and will loop endlessly
[16:54:04] <julius> nuxil, good
[16:54:17] <nuxil> :)
[16:55:00] <julius> but my "cheap" atmega32L can only do 8mhz, so i cant use a nice arduino library. the light_ws2812 does not support fading
[16:55:30] <julius> waiting for some parts out of china, including a arduino uno and a mega328
[16:55:41] <nuxil> cant you do fading with pwm ?
[16:56:10] <julius> for one "simple" led i got some code
[16:56:27] <julius> but im unsure how to combine pwm with the library
[16:59:24] <nuxil> pwm's should not be too hard. but i have no idea if its suted to use with the ledstip you are using.
[17:00:05] <julius> http://www.mikrocontroller.net/articles/LED-Fading#Das_Demoprogramm
[17:00:24] <julius> theres code, the 10bit pwm version looks really good for a single led
[17:04:19] <nuxil> i got 3 pwm's running on one of my at85, each pwm controlling the r,g and b colors. though im using ordenary rgb diodes. and the pwm's are controlling some driver transistors for the leds.
[17:28:42] <nuxil> how do i fix this code ?
http://pastebin.com/fRWweraz my macro is probably wrong.
[17:31:22] <Jartza> what's wrong with it is the first question :)
[17:32:33] <nuxil> error: ‘LEDi’ undeclared (first use in this function)
[17:32:34] <nuxil> #define MergeLeds(l) LED##l
[17:34:18] <lald> #define LED(n) 1<<n
[17:35:14] <nuxil> i want to know whats wrong with my tolkens paser
[17:35:22] <nuxil> ## thingy
[17:37:15] <lald> Seems pretty evident from the error message that it doesn't want to work with a token which hasn't been defined, but I only pretend to know C.
[17:38:05] <nuxil> lald, i dont even pretend to know it :p i dont know it. still in learing as the days go by :D
[17:38:17] <nuxil> <- tha C noob :p
[17:39:22] <lald> Mmhmm. I'm basically "read only" in C.
[17:40:09] <nuxil> ups.. had a typos.. uint16_t :D fixed that one. but still errors.
[17:40:28] <Jartza> nuxil: there's nothing wrong with your macro, except it doesn't do what you think it does :)
[17:40:34] <Jartza> ## concatenates, yes.
[17:40:35] <nuxil> http://pastebin.com/H0sz2VGk
[17:40:39] <nuxil> all error
[17:40:41] <nuxil> s
[17:40:42] <Jartza> which seems to be exactly what it does
[17:41:04] <Jartza> MergeLeds(i) -> LEDi
[17:41:10] <Jartza> works as expected ;)
[17:41:25] <nuxil> so i need to use -> LEDi ?
[17:41:30] <nuxil> and why ?
[17:41:46] <nuxil> is ## for strings only?
[17:41:47] <Jartza> because macros are for preprocessor, not compiler
[17:42:01] <nuxil> oh i think i get it
[17:42:04] <nuxil> thanks
[17:42:12] <Jartza> preprocessor have no way of knowing what i is. so it prints i. like you asked :)
[17:42:20] <nuxil> yea
[17:42:26] <Jartza> and concatenates the text LED, and tha argument "i"
[17:42:58] <Jartza> I would just replace the line 27
[17:43:09] <Jartza> res |= 1 << i;
[17:43:39] <lorenzo> is it possible to read directly into ihex with avrdude?
[17:43:41] <lorenzo> instead of .bin
[17:43:47] <Jartza> oh actually no, you want them in the other way it seems
[17:43:48] <cehteh> nuxil: you need some double expansion
[17:44:08] <Jartza> res |= (0b1000000000000000 >> i)
[17:44:09] <Jartza> :)
[17:44:20] <Jartza> and start i from 0 and count to 15
[17:44:32] <cehteh> #define MergeLeds(l) MergeLeds_2(l) #define MergeLeds_2(l) LED##l
[17:44:43] <nuxil> and that will next loop give 0b110000... and next 1110000... and so on ?
[17:45:06] <lald> lorenzo: -U <memtype>:<op>:<filename>:ihex
[17:45:33] <Jartza> nuxil: no, >> just shifts bits. and you only have single "1" there, it does not multiply
[17:45:50] <Jartza> 0b10000000 >> 1 becomes 0b01000000
[17:46:00] <lorenzo> thanks lald
[17:46:01] <Jartza> 0b01000000 >> 1 becomes 0b00100000
[17:46:06] <nuxil> well. i want to merge the bits so to speak. i need 1000..... to become 11..... and next 111.... so on.
[17:46:22] <Jartza> ah yea, that's what the |= will do
[17:46:36] <nuxil> cos .10000... is led1 .. 010000 is led 2 00100.. is led 3
[17:46:39] <cehteh> ## is for tokens not strings, strings are merged w/o any operator "foo" "bar" > "foobar"
[17:46:49] <Jartza> res |= ... equals res = res | ...
[17:47:26] <Jartza> cehteh: doesn't help inside loop anyway, not like that :)
[17:47:32] <Jartza> preprocessor still doesn't "unroll" loops
[17:47:47] <cehteh> yeah
[17:48:03] <nuxil> now i just got confused :D
[17:48:04] <nuxil> hehe
[17:48:27] <cehteh> and 0b ... is gcc only not standard C .. just a reminder :D
[17:48:57] <Jartza> nuxil: preprocessor only knows you have "i", it has no idea that "i" is variable or what value will it contain
[17:49:01] <cehteh> nuxil: just way to complicated code .. but dont worry you'll learn
[17:49:29] <nuxil> so.. how do i solve this then ?
[17:49:44] <Jartza> but also. in the end your compiler probably optimizes your code to much much simpler one :)
[17:49:59] <Jartza> even if you change that line to use << or >>
[17:50:29] <Jartza> in the end, it'll become "SendAsBits(res);
[17:50:32] <Jartza> oops
[17:50:40] <Jartza> SendAsBits(65535);
[17:50:44] <Jartza> :D
[17:50:45] <cehteh> for (uint16_t i = 0b1000000000000000; ~i: i |= i>>1) {SendAsBits(res); _delay_ms(10);}
[17:50:49] <cehteh> is all you need :D
[17:51:48] <Jartza> oh yeah, mm... SendAsBits was inside loop, mmkay
[17:51:55] <cehteh> err sendAsBits(i) of course
[17:52:01] <Jartza> yea
[17:52:09] <cehteh> copypasta
[17:52:12] <Jartza> though that code is confusing
[17:52:15] <cehteh> yeah
[17:52:20] <nuxil> indeed
[17:52:28] <nuxil> why do you invert i
[17:52:47] <cehteh> because ~0x1111111111111111 == 0
[17:53:28] <cehteh> ah that exits the loop one step too early :)
[17:55:03] <cehteh> so move the condition to the end of the loop do { ...} while( i != 0x1111111111111111)
[17:57:31] <Jartza> or just write readable C code ;)
[17:57:53] <cehteh> can still be readable, when you dont compress all on one line
[17:58:17] <cehteh> but saves the byte/register for the counter var
[17:59:00] <cehteh> this 0b.............. initializations are very verbose imo :D
[18:00:33] <cehteh> (already made the error using 0x above)
[18:06:16] <nuxil> im lost long time ago :p
[18:06:32] <nuxil> i just puted all my LED defines in a array and solved my problem :p
[18:06:49] <cehteh> enormous waste of memory
[18:06:52] <nuxil> this
[18:06:54] <nuxil> for (uint16_t i = 0b1000000000000000; ~i: i |= i>>1)
[18:06:57] <nuxil> is like Woooot..
[18:07:42] <cehteh> well .. the idea is that you just append one bit, and when all bits are set you exit the loop
[18:08:27] <cehteh> 0b1000000000000000 >> 1 is 0b0100000000000000 shifted one bit to the right, got that?
[18:08:48] <nuxil> yea. i see what youre doing now.
[18:09:03] <cehteh> 0b1000000000000000 | 0b010000000000000 (binary OR) gives 0b110000000000000
[18:09:18] <nuxil> yup
[18:09:25] <cehteh> |= is just syntactic sugar
[18:09:41] <Casper> foo >= 1;
[18:09:55] <cehteh> x = x | y is the same as x |= y
[18:10:24] * Casper discovered the >= and <= the other day
[18:12:25] <cehteh> thats something different
[18:12:42] <cehteh> btw there is <<= and >>= ... :)
[18:13:20] <cehteh> but C is not perl .. luky you
[18:13:20] <Emil> if only avrs had single instruction variable bit shifts
[18:16:06] <cehteh> huh
[18:16:09] <cehteh> iirc there are
[18:16:12] <cehteh> they
[18:16:36] <cehteh> sometimes i wish C had rotation operators
[18:16:58] <Casper> hardware bit swap!
[18:17:00] <cehteh> http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_LSR.html
[18:17:09] <cehteh> one cycle
[18:18:08] <Jartza> cehteh: that's not variable, it always shifts one position.
[18:18:22] <cehteh> oops
[18:19:04] <Jartza> Casper: umm... foo >= 1; is not very valid. or well, it is. but used like that, alone, it doesn't do anything.
[18:19:22] <Jartza> it just gives you comparison result which is unused
[18:19:44] <Casper> Jartza: foo >=1; == foo = foo >> 1
[18:19:54] <Jartza> no it's not
[18:19:58] <Jartza> foo >>= 1;
[18:20:16] <Jartza> foo >= 1; is comparison. foo equals or is larger than 1.
[18:20:39] * Casper checks his code
[18:20:45] <cehteh> hehe
[18:21:03] <Jartza> and if you just say foo >= 1; it doesn't do anything :)
[18:21:14] <Jartza> most probably compiler optimizes the whole line away.
[18:21:38] <Emil> well, there also are rol and ror commands
[18:21:53] <Jartza> yes. they also rotate only single position.
[18:22:07] <Jartza> difference being, the "extra" bit is dropped into carry flag
[18:22:09] <cehteh> Jartza: so left shift by more than one position can be optimized to a 2 cycle multiplication, interesting :D
[18:22:16] <Jartza> and carry flag is shifted to the other end
[18:22:18] <Emil> Jartza: I meant that there's a rotation thinft
[18:22:32] <Jartza> yes
[18:22:47] <Jartza> that's for example how you shift 16-bit variables ;)
[18:22:48] <cehteh> Emil: C has no rotation operators
[18:23:00] <Jartza> there's no "in-place-rotation", though
[18:23:17] <cehteh> only idioms and pray that the compiler optimize them into a single instruction
[18:23:22] <Emil> but like I said, its silly that avrs dont have strong bit manipulation istructions
[18:23:36] <Jartza> what's strong bit manipulation instruction?
[18:23:38] <Casper> Jartza: you're right, I used >>= hmmmm
[18:23:47] <Emil> cehteh: "C" has pretty much nothing
[18:23:54] <cehteh> multi position shift
[18:24:03] <Emil> Write a rotation operator and there it is
[18:24:26] <Emil> /function
[18:24:38] <cehteh> with inline asm .. then its not portable
[18:25:06] <Emil> "portable" is a questionable thing in this context
[18:25:22] <Jartza> I've never heard term strong bit manipulation before :)
[18:25:33] <cehteh> yes, but something as soimple as rotation could be in the stdlib or a C buildin operator already
[18:25:42] <Emil> Jartza: keep context in mind
[18:25:49] <Jartza> I've always been able to manipulate them with using only tiny amount of force :)
[18:25:53] <Emil> cehteh: that I agree with
[18:25:55] <Casper> but it's fun... I'll need to do uint64_t >> 48 in part of my code... I'm worried about that part :D
[18:26:12] <Jartza> why
[18:26:17] <Emil> Casper: why dont you just
[18:26:28] <cehteh> Casper: that could be optimized pretty well
[18:26:32] <Jartza> Casper: if you're worried, check what the compiler does.
[18:26:43] <Emil> why dont you just get that part of the data into another register?
[18:27:00] <Casper> Jartza: what I'm mostly worried about is all the 64 bits variables operation on a 8 bits micro
[18:27:01] <cehteh> but starting with uint64_t on a avr is already a bit irky
[18:27:14] <Jartza> most probably it only moves bytes, not bits.
[18:27:34] <cehteh> gcc is pretty good at some of such optimizations
[18:27:35] <Emil> 48 is divisible by 8
[18:27:42] <Jartza> that's why
[18:27:46] <cehteh> check the generated assembler
[18:27:49] <Casper> I say 48, but it may be anything close to that range
[18:27:59] <Casper> currently the code is on pc, so not bad
[18:27:59] <Jartza> most probably the asm is much better than you expect
[18:28:15] <cehteh> but not always
[18:28:16] <Jartza> at least on decently new compiler
[18:28:23] <Emil> Casper: the point is that you could also just get certain parts of the 64bit varianle
[18:28:27] <Jartza> of course not always.
[18:28:59] <Jartza> sometimes I've needed some union-magic to handle large variables.
[18:29:18] <Jartza> because compiler makes shitty code otherwise
[18:29:19] <Casper> https://bpaste.net/show/1349e1dd89a3 <=== pc version, will have to do most of that on the avr...
[18:29:22] <cehteh> on avr its best to avoid large vars as much as possible
[18:30:08] <Casper> but I think I will be able to drop to 32 bits instead of 64 due to some bits being always the same..
[18:30:11] <cehteh> this long foo=bar=baz=0 initialization doesnt do anything good but confusion
[18:30:17] <Casper> or appear to be
[18:30:42] <Casper> cehteh: does set all to 0
[18:31:03] <cehteh> yeah but having each on a single line would be more readable
[18:31:13] <cehteh> still generate the same code
[18:32:18] <cehteh> or in some cases even better code, ( maybe not here) but i learned that gcc optimizes expressions better when you do smaller multi line things than stuffing everything in one big formula
[18:32:31] <Jartza> not always
[18:32:36] <Casper> but gcc don't like switch
[18:32:47] <cehteh> why not?
[18:33:01] <cehteh> there are flags how switch will be compiled
[18:33:06] <Jartza> I had this single very stupid calculation in one program where stuffing everything into single line optimized almost 100 bytes shorter.
[18:33:09] <cehteh> (jump table vs ...)
[18:33:43] <cehteh> Jartza: ok, i had some opposite, gues one always needs to check this things
[18:34:11] <Casper> the switch base code is bigish
[18:34:32] <Jartza> font[j] = ((pgm_read_word(addr + ((((i > 3 ? j + 8 : j) + y_off) & 0x0F) << 1))) << (5 - x_off) >> (3 - (i & 0x03)) * 5) & 0x1F;
[18:34:44] <Jartza> that was first split into 4 lines
[18:34:52] <Jartza> and the code is like 80 bytes longer
[18:34:52] <cehteh> btw with -flto i get some impressive optimizations
[18:35:09] <Jartza> not really ;)
[18:35:18] <Jartza> I mean, not really impressive
[18:35:26] <cehteh> here i do
[18:35:41] <Jartza> it's basically same as copypasting your whole code into single .c file and then compiling as whole program
[18:35:51] <cehteh> yes of course
[18:35:54] <Jartza> sometimes that old trick still makes smaller code than -flto
[18:36:32] <cehteh> yes lto is somewhat new
[18:36:53] <cehteh> but at least its easier to optimize modular programs with that
[18:37:02] <cehteh> better than not having it
[18:37:19] <cehteh> while debug ouput is a mess :)
[18:37:32] <cehteh> generated assembler i mean
[18:37:52] <cehteh> patchwork of all your functions blended together
[18:40:13] <Jartza> true
[18:40:20] <Jartza> but that's what LTO does :)
[18:40:49] <Jartza> I still find it sad that IAR compiler makes 20-30% smaller code on ARM than gcc
[18:40:54] <Jartza> haven't ever tried on avr
[18:42:59] <cehteh> iar isnt free or?
[18:43:55] <cehteh> there was/is a llvm for avr .. but i never seen anyone using it
[18:46:47] <Jartza> no it's not free
[18:46:58] <Jartza> https://www.youtube.com/watch?v=hSOYJ8PkAkU
[18:47:05] <Jartza> well. now that works on this tiny 7" too
[18:47:06] <Jartza> coo
[18:47:08] <Jartza> cool
[18:47:30] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxWk1ycXljLWxzVkk/view
[18:47:33] <Jartza> cute little monitor :)
[18:50:21] <cehteh> hehe
[18:51:13] <cehteh> btw do you know how video composite signal is composed?
[18:54:15] <Jartza> yea
[18:55:12] <cehteh> guess thats impossible to generate with a avr .. mhm
[18:58:29] <Jartza> no it's not :)
[18:59:14] <Lambda_Aurigae> composite b&w is not difficult really.
[18:59:19] <Lambda_Aurigae> composite color a bit more but doable.
[19:00:24] <cehteh> ah ok
[19:01:56] <Lambda_Aurigae> composite is easier than vga I believe.
[19:02:08] <Lambda_Aurigae> and pal easier than ntsc
[19:02:51] <Jartza> haven't tried composite yet :
[19:08:36] <cehteh> needs only one i/o ... hey you could do multi-monitor with a tiny5 :D
[19:17:42] <Jartza> I can do that already
[19:17:45] <Jartza> 3 monitors
[19:17:46] <Jartza> :D
[19:50:06] <Lambda_Aurigae> Jartza, next project....2 steppers, an etch-a-sketch, and an attiny45....full graphic display.
[19:50:12] <Lambda_Aurigae> err..attiny85
[19:50:32] <Lambda_Aurigae> http://hackaday.com/2016/01/18/precision-cnc-drawing-with-etchabot/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[20:18:51] <nikomo> Got a teacher at school that uses PICs mostly, and he hasn't had luck with AVR. Asked him if he wants me to make a demoboard for the atmega328 so he can play around with it, he said yes. nailed it.