Back
[07:13:16] <ambro718> I've finally mastered how to deal with my compiler bug issue, lol. Poke it unti it works. That includes trivial changes in the program that preserve the semantics, and turning off various optimizations.
[07:14:47] <ambro718> it doesn't look like it's the optimizations actually being the problem, it just changes the behavior of the compiler in a way that the bug isn't triggered
[07:17:36] <specing> ambro718: yep
[07:18:41] <specing> If we all spent the time we used for forcing GCC into behaving, we could have both a new language and a compiler for it written.
[07:20:54] <Tom_itx> but we still trudge on
[09:22:23] <antto> i just updated the FW of my usbasp to the newest one, and it still acts like WTF on me
[09:22:27] <antto> grr ;]
[09:38:35] <tzanger> WTF mode is the default mode. you have to initiate a DAFUQ sequence to get it into OMG mode.
[09:40:05] <ambro718> hm so there's no eori
[09:40:52] <ambro718> I have a register like XXXX100 and I need to turn it into XXXX010 (for different numbers of X's)
[09:42:11] <ambro718> now I eor with a mask like 00001100 to turn the former into the letter, but rotating the mask for the next iteration takes a cycle
[09:42:26] <ambro718> is there a faster way?
[09:46:40] <ambro718> never mind. Subtract 100, obviously (subi).
[09:47:12] <ambro718> I mean 10
[10:49:05] <ambro718> hehe just optimized my 29-bit to 142 cycles, down from 156 cycles after this last optimization with subi.
https://github.com/ambrop72/avr-asm-ops/blob/master/sqrt_29_large.h
[10:49:13] <ambro718> * 29-bit sqrt
[10:52:24] <ambro718> due to this I can move the axes on my 3d printer 3% faster :D
[10:53:01] <antto> 3D printer O_o
[10:53:18] <antto> i wish i had a laser cutter
[10:57:31] <ambro718> yeah, it looks like this,
http://www.pasteall.org/pic/show.php?id=54251 . I'm writing my own firmware for it because what currently exists sucks.
[10:58:37] <ambro718> I need to solve a quadratic equation for every step of the stepper motors, so to do it fast enough I had to resort to coding sqrt and division in assembly
[11:00:50] <GuShH> ambro718: how much precision do you need?
[11:00:59] <GuShH> on the sqrt specially
[11:01:17] <GuShH> (you could try a fast sqrt if the loss of precision isn't an issue)
[11:01:25] <ambro718> nope I need to be precise
[11:01:32] <GuShH> carmack disagrees
[11:01:37] <ambro718> ;)
[11:01:54] <GuShH> it's more the accumulation of error that bites you, not the immediate error heh
[11:01:58] <ambro718> if it's wrong the steppers will move incorrectly and make noises
[11:02:08] <GuShH> hopefully good noises
[11:02:28] <ambro718> nope, it sounds like they're suffering when I drive them wrong ;)
[11:02:46] <GuShH> phase overlap?
[11:02:51] <ambro718> huh?
[11:02:56] * GuShH eyerolls
[11:03:15] <GuShH> this is why I can't have conversations
[11:03:23] * GuShH walks away
[11:03:40] <GuShH> ambro718: basically trying to drive two windings at the same time or "out of time"
[11:03:44] <ambro718> does this have to do something with the low-level control of the steppers? The driver chips take care of that.
[11:03:48] <GuShH> but not in a half stepping manner
[11:03:54] <ambro718> I just send step pulses to the chips
[11:03:56] <GuShH> ah yes, it's low level
[11:04:31] <ambro718> the drivers do 1/16 step microstepping
[11:04:55] <GuShH> it's either quadcopter or 3d printer these days
[11:04:59] <GuShH> nothing else to do?
[11:05:23] <ambro718> so do something :D
[11:05:40] <GuShH> I'll start a nuclear weapon hobby club.
[11:05:52] <ambro718> hehe let's see how long that lasts
[11:06:11] <GuShH> should last long enough
[11:06:18] <GuShH> until everyone has died off
[11:35:57] <Essobi> Derp.
[12:47:13] <cyber37> I everybody i come again about the communiction with the NRF24l01, jadew thanks for help
[12:47:24] <cyber37> i arrive to get the STATUS register :Happy:
[12:47:32] <cyber37> 0x0E
[12:48:13] <cyber37> Now i have another problem but maybe is around the NRF24L01 protocol, so i would like to know if someone already use it ?
[14:13:57] <jadew> hi cyber37, I'm glad you got that far but I can't help further, I never worked with that device
[14:19:59] <RikusW> I have some nrf's but not used it yet.
[15:32:11] <braincracker> hah, official distributor is summoned for a123 cells
http://www.buya123batteries.com/category_s/1825.htm
[15:35:12] <megal0maniac> Crazy times :)
[15:36:00] <megal0maniac> Haven't touched an AVR in a while. Instead I've been building a commercial radio studio on a silly deadline. Pretty interesting stuff
[15:37:24] <megal0maniac> Broadcast is a strange beast. They have such weird and interesting gear
[15:38:05] <megal0maniac> They even use ISDN
[15:46:42] <megal0maniac> More madness tomorrow. I am excited :)
[17:20:09] <timemage> ambro718, ping
[17:20:19] <ambro718> timemage: hey
[17:21:13] <timemage> ambro718, after much screwing about, i got jtag working on my mega board. though, i can't use it with my linux tool chain and as it sits i have 4.6.x as part of avr studio.
[17:21:56] <ambro718> about that bug I was suffering from, I stopped messing with it for the time being. When it doesn't work I just poke it in various ways until it works lol.
[17:22:10] <timemage> ambro718, heh, ok.
[17:22:30] <ambro718> I've managed to reduce the bug to something smaller, but it still involves quite some stuff, I can paste it somewhere if you want to play with it
[17:23:08] <timemage> ambro718, nah. unless get newer gcc working with studio it won't help much. unless you manage to make it build under 4.6.
[17:23:16] <ambro718> s/some stuff/my FixedPoint, BoundedInt class and a square root algorithm in C
[17:23:21] <ambro718> oh, it may just build in 4.6
[17:23:31] <ambro718> give me a min, I'll put it together
[17:24:39] <timemage> ambro718, i did try to build under linux and then cram that into a studio project and make it debug without doing a proper build. getting wierd results though that i don't get when i do a simple test project. incompatible debug info maybe. dunno.
[17:24:39] <ambro718> usually I was able to reduce compiler bugs to a few ten lines of codes but this one is proving elusive...
[17:28:06] <timemage> ambro718, the code was a bit hard for me to follow to try to reason it out. i was just hoping that maybe the debugger would show something telling. what i was trying yesterday was putting a small array on the stack, filling it with a know value and then periodically checking it at deeper levels of the stack.
[17:29:15] <timemage> ambro718, i got hoards of template errors while trying, which is very odd considering the code i was adding. anyway, you might give that idea a try.
[17:32:58] <ambro718> I bet you forgot to type "typename" or "template" somewhere ;)
[17:33:52] <timemage> ambro718, i wasn't using any templated code. just a static member pointer to unsigned char, an a small unsigned char array.
[18:17:21] <ambro718> timemage:
https://gist.github.com/ambrop72/5872531
[18:17:43] <ambro718> I've tested it compiles and crashes at -std=c++98 in g++-4.8.1
[18:18:15] <timemage> ambro718, hmm. ok. hang on.
[18:18:31] <ambro718> oh wait I forgot to add the uart frequency setup
[18:18:56] <timemage> ambro718, would the clone url by the same when you do?
[18:19:14] <ambro718> huh?
[18:19:35] <timemage> ambro718, isn't gist like a temporary thing?
[18:19:57] <ambro718> no, it's like a less formal git repo ;)
[18:20:02] <ambro718> you can commit to it
[18:21:34] <timemage> ambro718, i don't use github let alone gist, so i don't get the distinction.
[18:23:05] <braincracker> $9,000,000,000,000 MISSING From The Federal Reserve
http://www.youtube.com/watch?v=1QK4bblyfsc
[18:24:03] * antto hides teh money under the rug
[18:26:23] <Roklobsta> braincracker: i am not from the USA but it makes me cringe.
[18:26:54] <Roklobsta> too big to fail, eh?
[18:27:13] <ambro718> timemage: okay I've added the uart code, it crashes successfully on my real atmega1284p
[18:27:35] <ambro718> be sure to set MCU, F_CPU and BAUD env vars
[18:27:49] <Roklobsta> what are you using for uart code?
[18:29:00] <ambro718> Roklobsta: the avr-libc stdio hooks,
https://gist.github.com/ambrop72/5872531#file-main-cpp-L61
[18:29:34] <Roklobsta> braincracker: she's like "shit, they noticed the $9trill transaction. how'd he know about that?!?!"
[18:30:46] <Roklobsta> hmm, i did some uart code with with ISR's in 6.1SP1 just fine and it handles RTS/CTS too.
[18:30:49] <braincracker> it is a simple "don't want to answer the question"
[18:31:00] <braincracker> (knows shit)
[18:31:14] <Roklobsta> isn't the Fed a private company?
[18:31:25] <timemage> ambro718, it's complaining about your use of .template send_stepper_command()
[18:31:58] <Roklobsta> WTF C++? AVR? hmmm.
[18:32:18] <timemage> ambro718, "(as a disambiguator) is onnly allowed within templates"
[18:32:50] <timemage> Roklobsta, it happen sometimes =)
[18:32:55] <Roklobsta> hmm, i duuno about that. with embedded I really like NOT using a heap and statically allocating just about every bit of memory usage.
[18:33:19] <braincracker> http://www.youtube.com/watch?v=6p__MgUPUDQ
[18:33:31] <Roklobsta> it's too easy to run out of stack and so on when you have only 8K or even 64K of SRAM
[18:34:10] <timemage> Roklobsta, there's not a lot of dynamic allocation going at on in this code. c++ is reasonably controllable if you pay attention to what you're doing. that said, i don't use it that much myself. at least not for avrs.
[18:34:14] <Roklobsta> you need to keep tight control on memory use. I say this coming from an industry where a crashed embedded system can cost $1000's for someone to go to it and press reset.
[18:35:30] <Roklobsta> I am conservative but C++ adds unnecesary complexity. You should always have a good understanding of what's going on and why in your embedded system.
[18:35:39] <Roklobsta> KISS
[18:35:56] <Roklobsta> leave C++ etc for systems with an MMU and loads of ram
[18:37:28] <Horologium> like the rPI
[18:48:25] <ambro718> timemage: what's the error you're getting?
[18:49:34] <Vutral> hnm
[18:55:03] <timemage> ambro718, listed above, minus my typo. pointing to first use of .template in that function.
[18:55:21] <ambro718> timemage: you can just remove the .template
[18:55:56] <ambro718> timemage: I see gcc 4.6 doesn't support 24-bit integers which I'm using. I've tried removing them, but then the bug stops happening in gcc 4.8.1
[18:56:07] <ambro718> it also compiles in 4.6 but the bug isn't there
[18:57:20] <Casper> 24 bits integers? that sound so... inneficiant
[18:57:32] <Casper> good for tight memory, bad for code size and execution speed
[18:58:03] <ambro718> I pushed the changes to the gist to compile with 4.6, but without removing the uint24
[18:58:20] <ambro718> Casper: why do you believe that?
[18:58:35] <ambro718> compared to 32-bit integers, that is
[18:58:42] <ambro718> 24-bit integers are faster on AVR than 32-bit
[18:58:53] <Roklobsta> how much? 3/4 less time?
[18:59:02] <Roklobsta> 1/4 i mean
[18:59:10] <ambro718> depends on which operations you're doing
[18:59:18] <Casper> ambro718: are you sure about that?
[18:59:20] <ambro718> probably more than 1/4 for multiplication
[18:59:33] <Roklobsta> maybe
[18:59:53] <ambro718> they also save registers
[18:59:56] <Roklobsta> though i do think if you only need 24 bits dynamic range then that's fine
[19:00:22] <Roklobsta> like you say, save some resources
[19:00:24] <ambro718> I don't need to prove they're better in space and time, it's obvious.
[19:00:35] <ambro718> on 8-bit CPUs that is
[19:00:49] <Roklobsta> i haven't seen 24 bits in ages. last time was 56002 dsp
[19:01:04] <Roklobsta> where is was the native long int size
[19:01:15] <Tom_itx> odd
[19:01:23] <ambro718> actually I wish gcc also provided 40, 48 and 56 bit integers
[19:01:23] <Roklobsta> even
[19:01:45] <Tom_itx> i'd rather 63bit
[19:01:46] <Roklobsta> ambro718: it just needs someone to sit down and bang them out. no reason why it couldn't
[19:02:13] <ambro718> that's because the computational complexity of multiplication is quadratic with respect to number of bits
[19:02:31] <Roklobsta> i thought it was tridratic
[19:02:49] <Roklobsta> i went to a bad high school though
[19:03:16] <ambro718> maybe, I dont' care, basically the overhead you get from using unneeded bytes gets larger as you're dealing with larger integers
[19:03:27] <Roklobsta> brain
[19:03:49] <Roklobsta> braincracker: i think the $9trill might have fallen between some couch cushions
[19:03:51] <ambro718> 16bit instead of 8bit, probably not a problem, 64bit instead of 40 bit, very significant
[19:04:23] <Roklobsta> there is nothing stopping you from making your own 40bit types
[19:04:34] <Roklobsta> you'll just need to hand roll the functions to do the maths
[19:05:02] <Roklobsta> and deal with sign*sign and unsign*unsign and sign*unsign
[19:05:06] <Roklobsta> etc
[19:05:11] <Roklobsta> it's a bit of work
[19:06:04] <Roklobsta> you'd get away with inlie macros though which would be best, though a debugger like avrstudio might not be able to understand them
[19:06:39] <timemage> ambro718, well, this will be interesting just having to deal with avrstudio if for no other reason.
[19:06:43] <ambro718> I know, but it's a lot of work
[19:06:51] <Roklobsta> anyway, doing that stuff is a good exercise in relearning to do long hand multiplication with binary numbers.
[19:08:10] <Roklobsta> i've done it before. you learn that sign*sign give you two sign bits in the result!
[19:08:23] <Roklobsta> which you have to account for
[19:14:22] <ambro718> though it might not be and just needs some poking to crash lol
[19:14:28] <timemage> ambro718, yeah, i kind of picked up on that. but i just thought seeing as though i managed to get this far why not confirm it here.
[19:23:00] <timemage> ambro718, ok. same deal here. just went with -O3. i wouldn't surprise me to much about the 24bit ints. probably not the most well tested feature.
[19:34:55] <ambro718> it's just bothering me so much that I can't reduce it to something the gcc devs would bother looking at
[20:54:22] <Badaboom> Evening
[20:54:34] <Tom_itx> tis
[20:54:42] <Badaboom> tisit
[20:54:47] <Badaboom> lol
[20:55:02] <Badaboom> Ive een sick as ---- for over a week
[20:55:11] <Badaboom> been
[20:55:40] <Horologium> that's nice.
[20:55:57] <Tom_itx> don't share
[20:56:01] <Badaboom> lol
[20:56:41] <Badaboom> What i have is from working one of the oil spills
[20:57:10] <Horologium> not supposed to drink the stuff.
[20:57:26] <Badaboom> Thats what they told me but it looked like choclate
[23:49:08] <Roklobsta> any of youse use XRAM at all?
[23:54:10] <Isvara> Hi, #avr. I'm trying to add a command table for my CLI, and I want it to live in its own section so I can find it with __start_cli_cmdtable and __stop_cli_cmdtable. However, when I add __attribute__((section("cli_cmdtable"))), I get this error from ld: section cli_cmdtable loaded at [000000000000175a,0000000000001771] overlaps section .data loaded at [000000000000175a,000000000000193b]