Back
[09:44:14] <Getty> its btw not onyl the changing syntax, thats a cherry on top which is just unique, the option to have several ways to write the same code is another advantage (and also very unique)
[09:44:17] <Getty> hups, sorry
[09:44:50] <Getty> holy shit, i was really even the last one saying something in here before.....
[09:45:06] <twnqx> that was just 15h ago
[09:45:12] <Getty> "just"
[09:45:16] <twnqx> 14.5 even!
[09:45:20] <Getty> 165 people
[09:45:24] <Getty> a bit of drive could happen
[09:51:09] <Getty> i got a null terminated buffer from itoa but i need it like ' '-padded, is there some function that helps?
[09:58:39] <Getty> oh yeah right... i should have sprintf, that would make it easy
[09:59:26] <Getty> and then i dont need the other one, doh 8-) damn forest
[10:00:28] <Getty> wow that was expansive now, directly 4k flash
[10:16:23] <gorroth> i only see trees
[10:17:51] <Getty> i dont get it, my device reboots now, and i dont know what it is, and the sprintf somehow also doesnt behave as i expect..
[10:20:30] <gorroth> i don't know what you're doing, but you probably have garbage data input somewhere
[10:21:37] <Getty> the output shows that the data is as expect, but "% 4d" of 1000 seems to be 100 and not 1000 ;) (990 goes fine to 990)
[10:22:06] <gorroth> are you printing this on your computer or on a tiny lcd screen connected to the avr?
[10:22:26] <Getty> tiny lcd :-/ but the output check that the data is as expected i can do in this case with the LED
[10:22:40] <Getty> and the brightness is correct, so all values flow correctly just the sprintf value displayed is... wrong
[10:22:56] <gorroth> and the LCD is large enough to display that many chars? i assume it is
[10:23:01] <Getty> lol ;)
[10:23:04] <Getty> it was before all fine
[10:23:07] <Getty> i just switched to sprintf
[10:23:16] <Getty> where i did before hand-bit-shifting shit for display
[10:23:20] <Getty> i regret it already
[10:23:50] <gorroth> and your char[] is large enough?
[10:24:14] <Getty> yeah i already made it one bigger to be sure the \n doesnt go somewhere where it shouldnt go ;)
[10:24:27] <gorroth> what if you make it 10 bigger? :-)
[10:24:28] <Getty> char buffer[5]; sprintf(buffer, "% 4d", num);
[10:24:32] <gorroth> just to be safe until you've tested
[10:24:39] <Getty> lol ok i can do
[10:25:04] <Getty> just need to pick the right ones out then again
[10:25:39] <Getty> no wait, then i also need to fill up the thing before
[10:25:52] <gorroth> fill up?
[10:26:15] <Getty> yeah i mean if i give it a 10 buffer then it would put them \n somewhere if the string is "% 4d"
[10:26:21] <Getty> so i have to change a bit more logic as "just make it a bigger buffer"
[10:26:31] <gorroth> oh i see
[10:26:37] <Getty> oh wait no, you are right.. if i just .... yeah right i can just ignore that
[10:26:47] <Getty> i make the buffer bigger, and have "% 4d" then i KNOW they are 0,1,2,3
[10:26:51] <gorroth> so sprintf will put a '\0' at the end
[10:26:52] <Getty> right right i think too much ;)
[10:27:04] <gorroth> but looks like your code _should_ work
[10:27:46] <gorroth> oh
[10:27:50] <Getty> yeah bigger bufer is not changing anything
[10:27:52] <gorroth> oh, lol
[10:27:57] <gorroth> is that the code as you have it?
[10:27:57] <Getty> oh what?
[10:28:01] <Getty> why????
[10:28:06] <gorroth> int snprintf(char *str, size_t size, const char *format, ...);
[10:28:14] <gorroth> you put
[10:28:20] <gorroth> sprintf(buffer, "% 4d", num);
[10:28:27] <gorroth> you forgot "size"
[10:28:37] <Getty> yeah cause i use sprintf and not snprintf ?
[10:28:47] <Getty> ;)
[10:28:52] <Getty> say oh again
[10:28:52] <gorroth> derp derp
[10:28:55] <gorroth> my dumb
[10:29:00] <Getty> ;)
[10:29:06] <Getty> no problem, this topic is pure madness
[10:29:10] <Getty> fighting with fucking bits and bytes
[10:29:25] <Getty> we discuss here putting some fucking numbers on a display and its 2015
[10:29:34] <gorroth> i don't know why you'd have a problem making a bigger buffer, however
[10:29:42] <gorroth> are you using the same buffer for multiple things?
[10:29:46] <Getty> no no as said, if i just ignore it logical works
[10:29:47] <Getty> and it does
[10:29:50] <Getty> but it doesnt remove the problem
[10:29:52] <gorroth> if you are, could something else just be lopping it off from bad pointer math?
[10:29:55] <gorroth> oh
[10:29:55] <Getty> no
[10:30:15] <Getty> 1000 is stll " 100"
[10:30:30] <Getty> 990 goes " 990" i go 1 higher, the value is 1000 and the display shows " 100"
[10:30:31] <gorroth> and you have something printed out right after that last "0" ?
[10:30:32] <Getty> its totally weird
[10:30:49] <gorroth> how about this...
[10:30:49] <Getty> no, it could be at the last position
[10:30:56] <Getty> that my buffer is " 1000"
[10:31:02] <Getty> but... why that? same problem ;)
[10:31:03] <gorroth> create a temp buffer containing everything you expect to be in the buffer you're building
[10:31:16] <gorroth> then on the LCD, only print "1" or "0" if the two buffers match
[10:31:21] <gorroth> then you know whether or not your buffer is correct
[10:31:28] <gorroth> if it is, you've just got a problem printing to the LCD
[10:31:31] <Getty> well i SEE that the buffer is not correct ;)
[10:31:37] <Getty> no i dont have problems printing on the LCD
[10:31:45] <gorroth> unless you're printing to the LCD wrongly
[10:31:49] <Getty> as said, we have a complete working menu here i have 1000< of lines of already working things
[10:31:53] <gorroth> i'd just rather do that check
[10:32:04] <gorroth> okay
[10:32:05] <Getty> yeah but what to check if i have thousnads of lines showing working stuff?
[10:32:11] <Getty> its REALLY ONLY through sprintf now popping up
[10:32:32] <Getty> i dont deny that it could be still something outside, but all is so straight forward simple, i have no idea
[10:32:43] <Getty> i take the chars out of the buffer i showed you and put them on display
[10:32:51] <Getty> and till 990 its all fine ;)
[10:33:19] <Getty> let me doublecheck all the details around again
[10:34:02] <gorroth> do you have a debugger hooked up?
[10:34:09] <gorroth> then you could look at the memory
[10:35:57] <Getty> no sadly, but i must say, didnt tried so far to make it work on debugging
[10:36:03] <Getty> it was so totally not necessary till now
[10:36:51] <Getty> i will try for the fun snprintf
[10:37:07] <Getty> and reduce hte buffer to 4 again
[10:37:45] <gorroth> when i put char buf[5]; int x = 1000; sprintf(buf, "% 4d", x);
[10:37:55] <gorroth> my debugger shows that buf[5] has the null-term char
[10:38:02] <gorroth> even though i only make buf 5 long
[10:38:08] <gorroth> so i think memory is leaking over
[10:39:00] <Getty> where? how? i mean the joke is i call that thing like 327642432 times per second in that loop its not like a one time thing
[10:39:10] <Getty> so if it would be a memory leaking it shoud be at least a bit changing, or?
[10:39:20] <Getty> snprintf makes it evn more wird
[10:39:42] <Getty> but makes the same result, 99 to 10
[10:40:38] <gorroth> it is changing 99 to 10?
[10:41:08] <Getty> no its like that it misse the 0 at the end
[10:41:10] <Getty> no idea why
[10:41:22] <Getty> so it does the same as ebfore 99 to 10 instead of 990 to 100
[10:41:30] <gorroth> what does your print method look like?
[10:41:56] <Getty> print method?
[10:42:05] <gorroth> you have something pushing data to the LCD
[10:42:07] <Getty> i use i2c to deliver to the display
[10:42:10] <Getty> yeah but that works
[10:42:21] <gorroth> maybe it's not going far enough in the buffer
[10:42:26] <Getty> no
[10:42:36] <Getty> its totally using the complete buffer of 2 displaylines which i have as arrays
[10:42:40] <Getty> it doesnt put on specific chars
[10:42:41] <gorroth> i don't know. because my system displays " 1000" on my system finely
[10:42:43] <Getty> that snot possible at all
[10:42:49] <Getty> " 1000" ????
[10:43:07] <gorroth> yup, "% 4d" is putting " 1000" in my buffer
[10:43:08] <Getty> you know if you have "% 4d" it should be "1000" right?
[10:43:10] <Getty> yes
[10:43:10] <gorroth> which i think is wrong
[10:43:13] <Getty> then you have my bug
[10:43:13] <gorroth> but that's what it is
[10:43:14] <Getty> thats my bug
[10:43:27] <Getty> awesome
[10:43:30] <Getty> so fuck sprintf
[10:43:30] <gorroth> that's what i think. the format specififer is wrong
[10:45:00] <Getty> zero padded it works
[10:45:25] <Getty> so it cant do that, awesome ;)
[10:46:23] <gorroth> i know what you want
[10:46:30] <gorroth> sprintf(buf, "%*d", 4, x);
[10:46:56] <Getty> hu, ok, lets test this
[10:47:59] <Getty> AEHM
[10:47:59] <Getty> garbage
[10:48:15] <gorroth> works great in standard C
[10:48:23] <gorroth> it's the "field width" specifier
[10:48:25] <Getty> yeah i jus tget garbage and the garbage even doesnt change if you change the value
[10:48:27] <Getty> yeah
[10:50:36] <gorroth> one second
[10:50:39] <gorroth> i'll try it on my avr
[10:50:41] <gorroth> minus the lcd output
[10:50:55] <Getty> yeah i have an atmega64 just as sideinfo
[10:51:21] <Getty> yeah i tricked it now
[10:51:43] <Getty> like i replaced the leading 0 with ' ' thats actually the most easy way here to go
[10:51:56] <Getty> so my situation is safe now, just as another sideinfo, but still curious about your results
[10:53:26] <Getty> hui! crashing....
[10:56:43] <gorroth> i think sprintf is broken on avr libc
[10:56:46] <gorroth> so don't use it
[10:56:49] <Getty> yeah
[10:56:58] <Getty> the crashing clearly warns me for that ;)
[10:57:12] <gorroth> the results i got indicated sprintf is shit on avr
[10:59:57] * Getty gets a headache
[11:18:53] <twnqx> Getty: why are you even using %<space>4d?
[11:19:22] <Getty> mh? why not? thought it works, pretty sure it works in higher sprintf implementations
[11:19:23] <twnqx> you require the use of the space this way
[11:19:50] <twnqx> and it seems to work, true
[11:19:54] <Getty> well its a visual, i want that the user doesnt get zero padded numbers which are not zero padded by context (like time)
[11:20:00] <twnqx> BUT
[11:20:09] <twnqx> the %4 includes the space
[11:20:14] <twnqx> or - sign for negative numbers
[11:20:16] <Getty> yeah its wird
[11:20:21] <twnqx> if you want " 1000"
[11:20:23] <twnqx> you need %5d
[11:20:23] <Getty> its like he interprets it as: " %4d"
[11:20:25] <twnqx> you need % 5d
[11:20:28] <twnqx> no
[11:20:30] <Getty> hu?
[11:20:31] <twnqx> it is spec compliant
[11:20:36] <Getty> ah....
[11:20:49] <Getty> but then it displays wrong, i mean it still would then do: " 990 "
[11:20:52] <twnqx> the space, or the minus sign in its place for negative numbers, is part of the total length
[11:21:02] <twnqx> no
[11:21:08] <twnqx> the length is never fully used
[11:21:25] <twnqx> it is uses as much as needed
[11:21:35] <Getty> well i had: "100" for 1000 "990" for 990 and " 9" for 90
[11:21:45] <Getty> aehm
[11:21:59] <Getty> " 90" so
[11:22:00] <twnqx> are you sure?
[11:22:02] <Getty> yes
[11:22:03] <Getty> saw it
[11:22:07] <Getty> life in front of me
[11:22:16] <Getty> 0-990 display 100% fine as wanted
[11:23:17] <twnqx> if it was " %4d" it should work, what you are writing, to me, indicates that "% 4d" is correctly implemented as well. you have 4 digits declared you get " 100" - which is 4 characters.
[11:23:47] <Getty> ? you wanna tell me that 100 is correct for displaying 1000 with % 4d ? ;)
[11:23:52] <twnqx> yes.
[11:23:57] <twnqx> " 1000" is 5 characters.
[11:23:58] <twnqx> not 4.
[11:24:26] <Getty> i am confused
[11:24:29] <twnqx> and you explicitly requested printing of the leading space
[11:24:39] <Getty> well leading space is always just if needed
[11:24:41] <twnqx> space, one, zero, zero, zero. count them. i count 5.
[11:24:45] <twnqx> no.
[11:24:45] <Getty> enforcing one up front was not what i meant ;)
[11:24:55] <twnqx> it is reserved where the - would be printed.
[11:25:01] <twnqx> but what you wrote.
[11:25:12] <twnqx> what you meant is probably %-4d
[11:25:31] <twnqx> or " %4d"
[11:25:33] <twnqx> dunno
[11:25:47] <twnqx> but you told it to print 4 characters, with a leading space if the number is positive
[11:25:49] <Getty> yeah %-4d is it!
[11:26:26] <Getty> i just tested on perl and saw that it really also makes 5 on 1000 with % 4d, but %-4d does it proper, so its just this "-" adding behaviour that irritates me
[11:26:40] <Getty> thanks for the clearup, but now i must say, i do hate sprintf much more ;)
[11:27:52] <LeoNerd> sprintf is fun. It's one of the mini dynamic languages embedded inside the "static" language of C
[11:28:18] <twnqx> for varying definitions of "fun"
[11:28:31] <LeoNerd> Quite ;)
[11:28:43] <Getty> all the fun you can get! ;)
[11:30:51] <twnqx> i always fail on floating point numbers
[11:31:10] <twnqx> keep forgetting that the first number is the total length, not the number of digits before the .
[11:33:48] <gorroth> twnqx: is right, just use "%4d"; that works
[11:33:52] <gorroth> i just tested it
[11:34:03] <twnqx> of course i am!
[11:34:07] <gorroth> yeah
[11:34:09] <gorroth> i forgot
[11:34:11] <twnqx> :)
[11:34:15] <Getty> <facepalm> oh yeah....
[11:34:25] <Getty> forest... fucking forest
[11:34:43] <gorroth> i should have noticed that
[11:34:57] <gorroth> then again, i don't use sprintf much... sstream baby
[11:35:02] <gorroth> except that isn't on the avr, afaik
[11:35:39] <twnqx> if that's the horrible, horrible, and then far worse, C++ formatting stuff...
[11:36:23] <gorroth> it's not worse though
[11:36:34] <twnqx> it is horrib
[11:36:36] <twnqx> le
[11:36:40] <twnqx> or horrid
[11:36:48] <twnqx> depending on the typo i just made
[11:37:05] <gorroth> sstream is much more flexible
[11:37:46] <Getty> btw that all still wouldnt have explained the crash i had.... sadly
[11:37:47] <twnqx> well, you are trying to convince someone with an utter hate of OOP
[11:38:32] <twnqx> Getty: maybe because your char[] was still too small?
[11:38:41] <LeoNerd> C++ is at least an entirely static language in this regard
[11:38:42] <LeoNerd> :)
[11:38:43] <Getty> no, that was what i excluded first
[11:39:29] <twnqx> LeoNerd: Except if you use inheritence, because then you never truly know beforehand which code will be executed with dynamic input
[11:39:59] <LeoNerd> Huhh.. ohyeah
[11:40:01] <LeoNerd> :/
[11:42:07] <gorroth> twnqx: oh, well, i cna't fix your OOP hate. there are laws against that, you know
[11:42:19] <gorroth> in the USA, you have to treat all paradigms with the respect they deserve
[11:42:32] <gorroth> otherwise the social justice warriors will be after you
[11:45:04] <LeoNerd> And make sure none of your paradigms look like a clock
[11:45:24] <LeoNerd> Or the TX police will arrest you
[11:46:31] <twnqx> luckily, oop does not deserve any respect
[11:46:51] <twnqx> (and even more luckily, the US are about the only country i refuse to travel to)
[11:47:40] <LeoNerd> C++'s style of OO is just the worst, though. It's really hard to explain all the subtleness of single-dynamic multiple-static dispatch with class-based inheritence except it's sortof dual-dynamic dispatch in the case of overloaded operators
[11:47:45] <gorroth> oh don't owrry, the USA has treaties with every civilized nation out there
[11:47:47] <gorroth> we'll get to you somehow
[11:47:49] <twnqx> no, it's not
[11:47:56] <twnqx> it was delphi's way of oop that broke me
[11:48:10] <gorroth> c++ oop is just fine; java is what's terrible
[11:48:20] <gorroth> and i have to do java all day at my latest gig
[11:48:25] <twnqx> "no more c&p, just inherit"
[11:48:33] <twnqx> the first thing i had to do with delphi
[11:48:35] <LeoNerd> What does Delphi do OOish? I thought it was basically Turbo Pascal v2
[11:48:39] <twnqx> was c&p a whole source file
[11:48:49] <twnqx> to edit a function like 5 levels up the inheritence tree
[11:48:57] <gorroth> lol
[11:49:02] <gorroth> that was just bad oop design
[11:49:06] <gorroth> they should have componentized
[11:49:07] <twnqx> then rebuild the whole multiple inheritance tree
[11:49:21] <twnqx> to get a GUI element that only accepted numbers
[11:49:23] <gorroth> yeah, what you're saying already says a lot about how they ddin't do it correctly
[11:49:58] <twnqx> there's a lot of things i like about c++
[11:50:03] <twnqx> just, oop is not among them.
[11:51:24] <gorroth> well, at least you don't have to write oop
[11:51:52] <twnqx> the use of vtables might be excusable on cpus that have large enough caches, long enough pipelines and enough prediction to temper over calling every second function indirectly
[11:52:08] <gorroth> so you use templates to create OOP
[11:52:12] <gorroth> but without vtables
[11:52:20] <twnqx> i prefer manual oop
[11:52:29] <gorroth> that's basically templates
[11:52:32] <twnqx> with the case of very selective funtion pointers exactly where needed
[11:52:33] <gorroth> except you'll get syntactic sugar
[11:52:43] <twnqx> and excessive compile times
[11:53:05] <gorroth> not so excesssive if things are in their own modules
[11:53:24] <twnqx> tell that to boost...
[11:53:31] <gorroth> you don't have to use boost
[11:53:36] <twnqx> of course not
[11:53:44] <gorroth> but in C, it's just too easy to screw around with memory pointers and corrupt the whole system
[11:53:54] <gorroth> since you're just encouraged to do it unsafely
[11:53:59] <twnqx> yeah, if you don't know what you're doing, it's easy...
[11:54:06] <gorroth> i do know what i'm doing
[11:54:08] <gorroth> it's still easy
[11:55:27] <twnqx> i... obviously disagree on that part and think that pointers are among the best thing a language can offer
[11:55:41] <twnqx> because otherwise you can never be sure that the compiler does the best possible thing
[11:56:02] <gorroth> compilers have less information with pointers
[11:56:09] <twnqx> exactly
[11:56:12] <twnqx> less ways to fuck up
[11:56:23] <twnqx> or do the wrong thing
[11:56:23] <gorroth> but anyway, you can do stuff with pointers. i think they're fine. i just dont think unsafe uses of them should be encouraged in the language
[11:56:35] <gorroth> less optimized code, you mean
[11:56:41] <gorroth> anyway, i'm gonna go
[11:56:45] <gorroth> got some things to do
[11:56:57] <twnqx> yeah... time to play some games :)
[11:57:01] <gorroth> :)
[11:57:07] <gorroth> ttyl
[11:57:14] <twnqx> still can't decide whether to use a small ARM or an AVR for this project :X
[11:57:23] * twnqx procrastinates the decision
[12:23:31] <osteri> btw. if you use floats in sprintf with AVR, you have to link some library (i think it was -lm)
[12:23:44] <osteri> i almost lost my mind trying to figure that out
[12:24:50] <LeoNerd> There's a multitude of choice of sprintf for AVR
[12:24:58] <LeoNerd> I'm not really sure I'd use any of it... I never seem to get a lot of success
[12:52:45] <gorroth> sprintf is fine
[12:52:54] <gorroth> i just forgot that one particular format specifier being default
[12:53:12] <gorroth> in C, you don't have a lot of options withotu rolling your own or using some other lib which is doing the same thing for no reason, being unstandard
[12:53:39] <LeoNerd> Ooh.. in C *generally* I use all manner of sprintfs all the time
[12:53:46] <gorroth> oh
[12:53:50] <LeoNerd> But on AVR.. I've never had any success with one that didn't just reset the CPU almost instantly
[12:53:57] <gorroth> ah, okay
[12:54:06] <gorroth> i thought you got it working
[12:54:16] <gorroth> and if it resets the CPU, probably there was a buffer overflow
[12:54:20] <LeoNerd> I had one that was working possibly by accident, for a few days..
[12:54:28] <LeoNerd> No, it wasn't that. Really.
[12:54:36] <gorroth> then again, AVR uses separate code/data sections on the hardware
[12:54:37] <gorroth> so don't know
[12:54:38] <LeoNerd> char buf[64]; sprintf(buf, "%d", 123); would crash the CPU
[12:55:08] <LeoNerd> So in the end I gave up and rolled my own set of string-formatting functions; the inclusion of which instead of sprintf actually made my program smaller anyway
[12:55:25] <gorroth> that's good
[12:55:31] <LeoNerd> The problem with sprintf on AVR is that it is dynamic. The compiler can't work out what features you are or aren't using, so it has to include the lot
[12:55:36] <gorroth> maybe your CPU was bugged?
[12:56:01] <LeoNerd> On desktops, what's a few more KiB of program code if your libc is 6MiB anyway and that's one of the smaller application libraries?
[12:56:06] <LeoNerd> On AVR, those bytes matter
[12:56:23] <gorroth> i don't know the internals of avr-libc
[12:56:26] <gorroth> i haven't looked into it
[12:56:31] <gorroth> i thought they rewrote it with the AVR in mind
[12:56:40] <LeoNerd> Hrm? This has nothing to do with avr-libc.
[12:56:53] <LeoNerd> The fundamental design of sprintf() makes it hard to handle on tiny-code places like microcontrollers
[12:56:56] <gorroth> thought you were talking about sprintf and how much size it uses
[12:57:29] <gorroth> well, anyway, doing very much in the way of stdio on the AVR seems odd anyway
[12:57:32] <LeoNerd> You can't statically determine, for example, whether the code to handle all the flags in "%-*.*d" is required or not. So you'd better just bundle it in anyway even if it isn't used
[12:57:40] <gorroth> i do want to do some eventually
[12:57:50] <gorroth> for this little LCD i've got that i think is like 4x25
[12:57:54] <LeoNerd> Even if nobody ever does anything more than %d, that code has to sit there because it couldn't be determined not to be necessary
[12:58:20] <gorroth> if this was c++, it could be determined :-P
[12:58:45] <LeoNerd> Well, if it was C++ using the >>-style of stream IO, yes. I believe that's one of the reasons why C++ did it that way
[12:59:05] <LeoNerd> 17:15 <LeoNerd> C++ is at least an entirely static language in this regard
[12:59:10] <gorroth> yes, or via templates, which is what i was thinking
[12:59:10] <LeoNerd> As I remarked an hour ago
[12:59:18] <gorroth> i didn't see you say that
[12:59:19] <gorroth> sorry
[12:59:59] <gorroth> anyway, your case is pretty easy to handle. you could just do a few if-else comparisons and make a funciton out of it
[13:00:04] <gorroth> then use itoa or something
[13:00:08] <gorroth> i think you said you did that
[13:01:08] <gorroth> or
[13:01:12] <gorroth> be even more clever
[13:01:36] <gorroth> have a 4 byte buffer with 4 spaces in it, then "shift" in your numbers as you calculate what they are
[13:01:41] <gorroth> like a "baws'
[13:01:53] <LeoNerd> I have stringy IO functions working quite nicely, thanks. :)
[13:01:57] <gorroth> but branching might be cheaper... not sure without detailed analysis, hehe
[13:02:05] <gorroth> cool
[13:03:43] <gorroth> for some reason, my rpi is taking a long time to upload code to the avr now
[13:03:51] <gorroth> i wonder if i need to let the avr "cool down"
[13:03:56] <gorroth> it's been plugged in for like 90 hours
[13:04:02] <LeoNerd> I don't expect that's a thing
[13:04:03] <gorroth> probably more
[13:04:14] <Getty> could it be that eeprom_write_block can take a long time? <waitingforever>
[13:04:20] <gorroth> well, it sure started going slowly when i pushed data to it today
[13:04:31] <gorroth> but a few days ago it wasn't slow
[13:04:51] <gorroth> Getty: i'm not sure... it could just be that while i was screwing around with the rpi, i screwed up a gpio setting
[13:05:36] <Getty> aehm independent case
[13:05:37] <Getty> ;)
[13:06:17] <Getty> ah i think my code just hangs, yeah i see why...
[13:07:12] <gorroth> :)
[13:08:30] <Getty> yeah ok still takes "some time" but not those minutes i waited for it ;)
[13:08:51] <gorroth> i'm rebooting the rpi to see if i can get it to behave better... there is a small possibility that me bringing up the bluetooth on the rpi caused it due to lower power available maybe
[13:09:10] <gorroth> rpi is pretty ghetto in its power
[13:12:35] <gorroth> well, a reboot made it upload quickly to the avr again, and i think bt is on
[13:12:43] <gorroth> hard to tell since i'm not next to the system right now
[13:16:35] <Getty> gorroth: wait, didnt followed your stuff, are you doing i2c/spi on the RPi?
[13:17:22] <gorroth> yes, but atm i'm just using SPI to program the avr
[13:17:52] <gorroth> tonight i'm going to start getting the code in order to have the rpi talk to the avr's code via spi
[13:17:54] <Getty> just prewarning, i remember hearing from several sources that both are "a bit bugged"
[13:17:59] <gorroth> nah
[13:18:01] <gorroth> they're fine
[13:18:26] <gorroth> they only mess up if you send bad commands
[13:18:41] <gorroth> and when that happens, the state gets permanently messed up, and you have to reboot the rpi
[13:18:51] <gorroth> reboot the avr
[13:18:53] <gorroth> whicever one
[13:23:47] <Getty> ah ok
[13:23:49] <Getty> good to know the details
[13:23:58] <gorroth> lol, it's not much in the way of details
[13:24:06] <gorroth> it's more like, "meh, don't know... uh, reboot"
[13:24:17] <Getty> generally i started to distrust raspberry for the hardware stuff, as in generally that thing is pretty unstable if something happens outside it doesnt like
[13:24:35] <gorroth> i just had a problem because i was doing something incorrectly with avrdude over linuxgpio
[13:24:43] <gorroth> and if you go in the wrong order, the state gets messed up
[13:25:01] <gorroth> you're talking about the 3.3v requirement, i think?
[13:25:07] <gorroth> you just have to use a voltage level translator to protect it
[13:25:14] <gorroth> or, do like me, and power the avr with the rpi itself
[13:27:30] <Getty> its generally more a computer as it is a hardware piece, thats the general tedency, its just to understand that its not a replacement for a chip, i dont speak of specific big problems, but alone that the power must be "even more stable" cause its a more complex system, is something people underestimate
[13:28:01] <Getty> if you care for all that, its fine, but the cost of the raspberry are already astronomic for hookup usage in a product, sadly sometimes no alternative ;)
[13:28:27] <gorroth> i am, however, planning to add a pwm lib to avr-libc, but it may not belong there and i'll release a separate libpwm
[13:28:32] <Getty> but its really good that it works fine with powering the raspberry from whatever input, that wasnt that good in the first versions
[13:28:38] <gorroth> libavrpwm, maybe
[13:28:45] <Getty> well i sell pwm products ;)
[13:28:52] <gorroth> that's good
[13:28:59] <Getty> the only thing i might need a lib for is this annoying mapping shit
[13:29:10] <gorroth> mapping the registers and output pins?
[13:29:12] <Getty> you know what i mean? looking up the cheat sheet for finding what register to kick
[13:29:13] <Getty> yeah
[13:29:16] <gorroth> yeah
[13:29:18] <Getty> its like its clearly defined what you can only use
[13:29:19] <gorroth> that's why i'm building it
[13:29:21] <gorroth> it's a PITA
[13:29:23] <Getty> but there is noone helping you how todo it
[13:29:24] <Getty> yeah
[13:29:25] <Getty> i thought about it
[13:29:30] <Getty> didnt had any good plan that make it less chaotic
[13:29:33] <gorroth> i've already got a lot of code written
[13:29:34] <Getty> beside delivering tons of defines
[13:29:36] <gorroth> and by a lot, it's not a lot
[13:29:43] <gorroth> it's only for t/c1 right now
[13:29:45] <gorroth> the 16-bit one
[13:29:57] <gorroth> and only for the PWMs that support ICR1
[13:30:00] <gorroth> to set TOP
[13:30:32] <gorroth> but it's a start, and people can contribute since i have it on github
[13:30:47] <Getty> if you want "mathematical extremly overinsane perfect" gamma correction, i can give you some stuff
[13:30:50] <gorroth> but too early for me to accept much, since i want to rewrite a lot of it to be smaller and ore efficient
[13:31:02] <Getty> but i bet you dont ;)
[13:31:06] <gorroth> i don't think i do right now, since i'm just using it for servo signals
[13:32:28] <Getty> its an annoying topic, as its 100% subjective, its not really a "perfect" result there
[13:32:40] <Getty> but i took the math to the extreme, just for the sake of ;)
[13:33:27] <Getty> even tho what i do add is a concept for doing it "by time" which most dont care about, they do gamma correction by the steps
[13:33:49] <Getty> so the fade is not gamma corrected but the points are, which is normally, subjective, not noticed as "failure"
[13:39:37] <gorroth> i'm not sure what you mean really, unless you're saying that you use the pwms to darken/brighten some lamps of some sort
[13:45:44] <Getty> yes
[13:45:56] <Getty> gamma correction == light ;) thought that was clear
[13:47:19] <gorroth> yes, i don't know what the adv. math part has to do with it is all
[13:47:30] <gorroth> since people just adjust the PWMs up/down until it's where they like it
[13:47:58] <Getty> yeah no.... gamma correction is a special problem, as the "brightness" is no linear relation to the power you give in, its logarithmic
[13:48:19] <Getty> so if you really wnat "a perfect fade" over time, then you cant just put the values higher step by step
[13:48:42] <Getty> else it would go very bright very fast and then it seems to go very slowly till its totally bright
[13:48:57] <Getty> most LED devices totally ignore that topic
[13:49:13] <Getty> which leads to customer building up "mountains" of points to compensate the problem
[14:38:28] <gorroth> oh, i haven't looked into it
[14:39:39] <Getty> i had used an awesome article as base but its in german ;) but it includes a Excel, i think this shows you what the problem is about
[14:40:02] <gorroth> that's okay
[14:40:05] <Getty> http://www.mikrocontroller.net/articles/LED-Fading //
http://www.mikrocontroller.net/wikifiles/a/af/Pwm_table-r101.pdf (this also exist as excel with variable)
[14:40:09] <gorroth> i'm not working in that right now
[14:40:27] <gorroth> if i ever do gamma correction, i'll look at it
[14:40:34] <Getty> hey, i take any chance to show off this totally useless knowledge
[14:41:23] <Getty> ;)
[14:47:51] <gorroth> it's not useless
[14:47:56] <gorroth> i just don't have a use for it atm :)
[14:48:45] <Getty> no i meant in the bigger context ;) it is a very useless knowledge
[14:49:01] <Getty> as its a subjective solution, in the end we have also 3-4 customers who complain about this correction
[14:49:33] <Getty> and the others could complain that they subjective thing its not really a good fade, noone knows, they might not care ;)
[14:52:22] <gorroth> tell them "this is the correct phase, b.i.t.c.h."
[14:52:23] <gorroth> lol
[14:52:28] <gorroth> s/phase/fade/
[14:52:29] <Getty> haha ;)
[14:52:35] <Getty> that IS actually what i do
[14:52:42] <gorroth> yeah
[14:52:48] <gorroth> a GPU mfg would tell us the same thing
[14:52:58] <gorroth> well, unless we proved them wrongly
[14:53:10] <Getty> http://srdemo.ledaquaristik.de/faq.html#gamma much text ;)
[14:53:35] <Getty> yeah i told the customers that at some point they can switch off the gamma, but it has no priority at all which i also tell them
[14:54:11] <Getty> the big big argument on this is always: "its better for beginners"
[14:54:25] <Getty> this is actually a pretty epic argument, as people just stop complaining if they believe they are expert
[14:54:29] <Getty> "yeah i am expert, thats why it annoys me"
[14:54:39] <Getty> so they dont complain towards you, as you have made your point clear
[14:54:50] <Getty> (and its a very valid point, every expert was a beginner)
[14:55:16] <Getty> important is always that you know more about the topic as the customer
[14:55:23] <gorroth> i don't know; i started as an expert
[14:55:25] <gorroth> j/k
[14:55:28] <Getty> ha ha
[14:55:28] <Getty> ;)
[14:55:41] <Getty> i was born badass ;-)
[14:57:14] <gorroth> hehe
[14:57:18] <gorroth> alrgiht, i have to do some work
[14:57:22] <gorroth> i'll ttyl
[15:47:26] <hetii> Hi :)
[15:48:29] <hetii> Is there some idea to have some virtual io port that is build from phisical bits from other ports?
[15:49:21] <hetii> I have a bit mess in wire on my board and wonder if its possible to have some macro that will play with my ports in handy way.
[15:50:17] <RikusW> you mean bitbanging ?
[15:50:34] <RikusW> using gpio to emulate a serial port etc ?
[15:52:28] <hetii> no, I have a 4x7-segment led display and will drive it by multiplexing, but the point is that this 7 segments are not connected to one port
[15:52:38] <hetii> but to different bits of 3 ports
[15:53:04] <RikusW> ah
[15:53:05] <hetii> and wonder how I can define data for this 3 ports
[15:53:10] <hetii> in nice way
[15:53:35] <RikusW> make a function like Set7Segment(....)
[15:54:05] <RikusW> its messy unfortunately, bitshifting/masking
[15:54:15] <hetii> sure but what then? huge switch statement ?
[15:55:07] <RikusW> are you using asm or C ?
[15:55:15] <hetii> C
[15:56:10] <RikusW> use bitmasking
[15:57:04] <hetii> but still will need do this for 3 ports
[15:57:04] <RikusW> read all 3 ports into variables
[15:57:09] <RikusW> yes
[15:58:04] <RikusW> then have 8 if(inbit & 1) set portx else clear portx for 1 to 0x80
[15:58:35] <RikusW> then save variables back to port
[15:59:21] <hetii> my crazy idea was to get address of this bits that I use for display and then keep then in some array and then play with them
[16:01:13] <RikusW> in asm I use BST / BLD
[16:01:44] <RikusW> Are you using mega328 perhaps ?
[16:01:52] <hetii> atmega8
[16:02:44] <RikusW> about the same messedup pinout...
[16:02:55] <RikusW> mega324 is much nicer
[16:03:04] <RikusW> 40pin dip
[16:03:47] <RikusW> if you are still prototyping, wire it in such a way that you can easily bitshift/mask
[16:04:17] <RikusW> the lookup table can also be modified to help with this
[16:04:28] <hetii> ye, I belive but its a small project ( 4 digit clock, that use v-usb to synchronize time with PC and react on infared remote controler to switch on HTPC when shutdown)
[16:05:18] <osteri> you could use BCD to 7SEG chip
[16:05:41] <hetii> its already build so will not change hardware now
[16:06:13] <hetii> just thought its some nice trick to build own PORTx
[16:11:05] <RikusW> call the function void PORTX(x) :-P
[16:11:25] <RikusW> or use C++ operator overloading
[17:00:59] <hetii> I end up with this function:
http://pastebin.ca/3163144
[21:12:12] <rue_mohr> bcd to 7 secment is 7447 and 7448
[21:12:34] <rue_mohr> common anode and cathode maybe not respectivly
[21:12:57] <rue_mohr> but there is that maxim chip that speaks serial and can run up to 8 displays
[21:14:41] <rue_mohr> het....
[21:14:42] <rue_mohr> meh