Back
[05:53:47] <Santh> T‘es dispo ce soir ? :)
[05:56:32] <Lambda_Aurigae> oosh dra mon ma threva.
[05:58:00] <Lambda_Aurigae> however, English is the preferred language here.
[06:05:18] <Santh> Ooops wrong windows, sorry :)
[07:25:23] <MokoLokoToko> Okay, this is some C code and its compiled assembly product with -Os
http://pastebin.com/XFZqbj7a
[07:25:49] <MokoLokoToko> My question is why does the compiler do stuff with the stack and all that, when it can just do out 0x12 r24
[07:26:06] <MokoLokoToko> based on avr-gcc function call standards for passing an unsigned char
[07:26:20] <MokoLokoToko> Is there something I should be telling the compiler to guide it?
[07:29:37] <|DM|> I'm mokoloko, just nickswitch sorry
[07:29:43] <|DM|> Didnt see if anyone answered
[07:36:55] <cehteh> gcc is a bit ugly about saving the stack and optimizations thereof
[07:37:52] <cehteh> for some fast interrupt handlers i had to make them naked and use some asm/tinker with the code
[07:39:05] <|DM|> But my code doesnt even use the stack ;-;
[07:39:29] <|DM|> Oh well.
[07:39:41] <cehteh> what are the WaitLCBusy() and EnablePulse() then?
[07:39:43] <cehteh> macros?
[07:40:02] <cehteh> do you call functions there?
[07:40:20] <cehteh> rcall WaitLCDBusy ...
[07:40:41] <cehteh> just comment out this functioncalls and see if it generates better code :D
[07:41:27] <cehteh> i am working here with -flto havent checked the generated asm but it is much much smaller so i expect its miuch better
[07:41:52] <cehteh> (some test go from 800something bytes to 200bytes with -flto)
[07:47:42] <|DM|> passing -flto to the gcc ?
[07:48:00] <|DM|> waitlcd busy and enablepulse are both void func(void) functions yeah
[08:00:58] <cehteh> is that timing critical?
[08:01:11] <cehteh> if not .. just keep it as is
[08:03:11] <|DM|> not really, just wondering why the compiler does that
[08:04:58] <cehteh> because it doesnt do better
[08:05:31] <cehteh> also when calling functtions it has some restrictions on what it could optimitze
[08:05:45] <cehteh> hence try what happens when you comment this functionscalls out
[08:06:51] <cehteh> maybe it still saves way to much on the stack, i've noticed that long ago, thought eventually things get optimized and fixed
[10:16:01] <|DM|> Does the gcc-as assembler do optimization ?
[10:16:07] <|DM|> Because I think its fucking part of my code
[10:21:39] <DKordic> |DM|: I bet not. You said nothing about Your problem.
[10:41:00] <|DM|> DKordic, you're right it wasnt the assembler optimizing out part of my code
[10:41:30] <|DM|> It was that return takes 4/5 cycles, while I only have 3 cycles to get out. Inlining the function worked perfectly
[10:41:44] <|DM|> Now only to figure out how to force the compiler to inline a function
[10:42:42] <LeoNerd> Hah
[10:49:48] <|DM|> __attribute__ ((always_inline)) in case anyone was wondering.
[10:51:04] <LeoNerd> __attribute__((inline,really-inline,no-really-I-don't-care-what-you-think-inline-it-damnit))
[11:03:13] <cehteh> whatever you do .. optimize your code at first :)
[11:03:27] <|DM|> yeah. just inline by itself like "inline void f(void)" wont ensure inlined code
[11:04:03] <cehteh> have you tried -flto ?
[11:04:10] <|DM|> well, the function to be inlined is basically sbi ioport iopin, nop, nop, cbi ioport iopin
[11:04:16] <|DM|> no, let me give it a look
[11:06:30] <|DM|> 1- did not inline the function
[11:06:38] <|DM|> 2- wtf did that do to my beautifull code
[11:06:44] <|DM|> wtf are all these directives
[11:08:40] <|DM|> Oh. And that wouldnt help in this case since everything is already in a single .c, not libraries :)
[11:16:50] <cehteh> ah ok
[11:17:44] <cehteh> well .. premature optimization is the root of all evil, optimize it when there is a problem, function takes too long or flash space or ram exhausted or whatever. but not earlier
[11:44:04] <|DM|> In this case inlining was necessary for it to work at all
[11:44:09] <|DM|> so imo thats not too soon :D
[12:24:15] <|DM|> Why are lcd screen DDRAM (display ram) 80x8 when only 32 of those 80 are used?
[12:26:33] <LeoNerd> Perhaps some /are/ 80?
[12:26:47] <|DM|> yeah, reading more there are lcds with 80
[12:27:04] <|DM|> and making a manufacture line to safe the cost of 60 bytes of ram would be silly I guess
[12:27:47] <LeoNerd> Ofcourse those RAM cells are probably not even populated on the chpi
[12:28:02] <LeoNerd> It's trivially simple to make address decoders with holes in the virtual address mapping
[12:28:13] <LeoNerd> You might wonder why 80 as opposed to, say, 128 however.
[12:31:11] <|DM|> I think the bytes are being written it, just not displayed
[12:31:22] <|DM|> because there's a command to 'rotate' for lack of a better word, the ram
[12:31:47] <LeoNerd> Ahyes, maybe.. for scrolling purposes
[12:31:54] <|DM|> but yeah, why 80 not more. It'd be a trivial cost increase
[12:52:50] <cehteh> hey that gives you some free ram cells somewhere else :)
[13:04:53] <DexterLB> what's the operating voltage range of the comparator on attiny2313a? Is it rail<->rail?
[13:05:13] <Lambda_Aurigae> DexterLB probably...it's in the datasheet most likely.
[13:05:27] <Lambda_Aurigae> should be GND to VCC
[13:05:47] <DexterLB> Lambda_Aurigae: it's not, at least I didn't find it. The datasheet only states offset voltage etc
[13:05:48] <Lambda_Aurigae> or maybe GND to AVCC...would have to look in the datasheet to know for sure.
[13:06:02] <DexterLB> yeah, I thought so, just wanted to be sure
[13:06:20] <Lambda_Aurigae> if your AVCC and VCC are the same then you should be ok.
[13:08:36] <DexterLB> I'm more worried about the GND end: I want to use it for current protection, so I was thinking of using a reference of about 100mv
[13:20:38] <Lambda_Aurigae> not sure what the problem is there.
[13:21:03] <Lambda_Aurigae> if you have a common GND you should be ok so long as you don't exceed VCC
[13:21:31] <Lambda_Aurigae> according to the block diagram, the comparator runs on VCC
[13:22:38] <Lambda_Aurigae> it shows several different sources for both positive and negative(inverted) feeds.
[13:24:10] <Lambda_Aurigae> and it doesn't use the ADC at all..so AVCC is irrelevant.
[13:24:41] <Lambda_Aurigae> you can use the ADC mux for input from any of the ADC channels for the negative rail.
[13:24:48] <Lambda_Aurigae> but you have to have the actual ADC turned off.
[13:25:27] <Lambda_Aurigae> ok...coffee break's over...back on your heads..
[13:25:34] <Lambda_Aurigae> lunchy done so I gotta run.
[13:28:48] * SM0TVI would protect any inputs with resistors and diode clamps if there aren't reasonable guarantees the signals won't smash the rails.
[13:30:57] <SM0TVI> Speaking of the comparators, are there any ways to add hysteresis to the comparator?
[13:33:42] <cehteh> no
[13:34:33] <RikusW> there might be
[13:34:45] <RikusW> SM0TVI: which avr are you using ?
[13:34:56] <cehteh> ok no for the ones i know
[13:34:59] <LeoNerd> If you want a hysterical (lit.) comparator, do it externally in analog
[13:35:41] <cehteh> deadtimes in software may be useful in some cases
[13:36:23] <RikusW> on say mega32u2 use AIN0 as input and put two reference voltages on AIN1 + 2 and switch the mux in fw
[13:40:08] <SM0TVI> RikusW: I'm planning on using the 48 to 168 / 328 series.
[13:40:18] <SM0TVI> Mega.
[13:40:46] <RikusW> I assumed mega from the number 328 ;)
[13:41:10] * SM0TVI has to see what size of code his first project will be before deciding on the chip.
[13:42:21] <SM0TVI> Basically, I will be sensing a voltage scaled down 1:100 and biased to Vcc/2, and the 5 mV hysteresis is a little too close to confort form me.
[13:42:30] <RikusW> same applies as for the 32u2 comment above
[13:42:40] <DexterLB> Lambda_Aurigae: the attiny2313a doesn't even have an ADC :)
[13:42:50] <RikusW> use the mux to select the reference and ain0 as input
[13:43:43] <SM0TVI> RikusW: That's the one thing I /can't/ do as easily (unless I use the internal bandgap), as I plan on using the mux for the comparator input...
[13:43:56] <RikusW> ah
[13:44:11] <RikusW> use an external mux on ain0 then ?
[13:44:16] <cehteh> RikusW: i once did that, muxing reference voltage, basically emulating a ne555
[13:44:21] <RikusW> and control with a gpio pin
[13:44:55] <SM0TVI> RikusW: Basically, I will be using both the comparator and the adc (tho not at the same time) to sense a coupla voltages.
[13:45:00] <|DM|> data memeory is the flash, program memory is the sram right ?
[13:45:22] <cehteh> eh
[13:45:26] <RikusW> |DM|: wrong way around
[13:45:40] <|DM|> prog mem is flash, data mem is sram?
[13:45:46] <cehteh> yes
[13:45:50] <RikusW> data->sram code->flash
[13:45:54] <|DM|> Alright.
[13:46:13] <RikusW> btw AVR uses words for code, not bytes
[13:46:27] <RikusW> with some 2 word instructions as well
[13:46:54] <RikusW> so mega8 got 8kb of flash but only 4k instruction words
[13:47:02] <|DM|> Mhm, I noticed that when working with the assembly
[13:47:18] <|DM|> I was just confused by the clock cycle timing wording of the ldi instruction
[13:48:06] <RikusW> I know avr asm quite well, so feel free to ask
[13:48:28] <RikusW> (maybe jsut a bit rusty on it)
[13:48:57] <|DM|> well, can I paste some c code and learn what I should tell the compiler to optimize it correctly?
[13:49:36] <RikusW> gcc ?
[13:49:43] <|DM|> yeah
[13:49:48] <|DM|> http://pastebin.com/wWYYwA4e is the avr-gcc code
[13:49:55] <RikusW> gcc drove me nuts, so I wrote most of my stuf in asm :-P
[13:50:01] <|DM|> http://pastebin.com/rpKtxPNH is the assembled code
[13:50:09] <|DM|> Ahh, I agree. It does so many weird things :/
[13:50:25] <RikusW> it does...
[13:50:51] <|DM|> Right now Im wondering why it doesnt optimize the SendString("test") to ldi r24 't' , rcall SendCharacter etc
[13:51:04] <RikusW> gcc x86 seems better though
[13:51:21] <|DM|> and instead saves test into what I assume is flash, then passed it through indirect loading
[13:51:36] <|DM|> I thought gcc x86 was the standard most compilers are held to ?
[13:51:59] <cehteh> just clone avr-gcc an go hacking/fixing it
[13:52:19] <|DM|> The only C and below coding I do is for avr, everything else is high level
[13:52:22] <cehteh> anyone of you tried clang for avr?
[13:52:25] <|DM|> SO I doubt I'm good enough for that cehteh
[13:52:29] <|DM|> :D
[13:52:41] <|DM|> clang the scheme variant?
[13:52:51] <cehteh> .. and on another note: porting tcc to avr might be feasible
[13:53:07] <cehteh> no the C compiler from the llvm project
[13:53:59] <|DM|> woops.
[13:54:41] <RikusW> |DM|: read the avr-libc docs about loading strings from flash maybe
[13:55:07] <RikusW> you generally wants all stings stored in flash since there is limited ram on avr
[13:55:53] <cehteh> http://www.avrfreaks.net/forum/tcc-tiny-c-compiler-avr .. ok someone tried and failed :D
[13:56:53] <|DM|> RikusW, my point is that in this case, the string never needs to be saved anyways
[13:57:06] <|DM|> loading from flash takes 3(!) times as many cycles
[13:57:19] <|DM|> loading from sram would take 2 times as many
[13:57:45] <|DM|> I feel like there's some very basic I'm missing that I could tell the compiler that would let it do this better
[13:57:50] <|DM|> a static keyword somewhere
[13:58:26] <RikusW> avr-gcc is just weird imo
[13:58:47] <RikusW> which version are you using ?
[13:59:00] <RikusW> winavr ? or the newer one from atmel ?
[14:00:05] <cehteh> what other C compilers for atmels exist?
[14:00:24] <|DM|> Im using whatever sudo apt-get install avr-gcc on ubuntu gives me, gimme a sec to check
[14:00:42] <cehteh> $avr-gcc --version
[14:00:42] <cehteh> avr-gcc (GCC) 4.8.1
[14:00:48] <|DM|> yeah
[14:00:50] <cehteh> ..debian jessie here
[14:00:59] <|DM|> avr-gcc -v says that too
[14:01:59] <RikusW> I got 4.7.0
[14:06:22] <|DM|> I'm compiling for atmega8 with -Wall and -Os and -S to produce assembler for me to inspect
[14:06:29] <|DM|> if you meant you wanted to compare
[14:08:31] <cehteh> i'd rather disassemble the .elf here to show whats exacty got generated, even if the linker did some optimization
[14:08:36] <cehteh> (-flto)
[14:12:11] <|DM|> Ah man, adding that to my makefile will be a bugger
[14:13:25] <cehteh> %.asm: %.elf
[14:13:26] <cehteh> $(OBJDUMP) -S $< >$@
[14:15:10] <|DM|> avr-objdump ?
[14:15:14] <cehteh> yea
[14:15:16] <|DM|> alright
[14:15:27] <|DM|> I was thinking avr-objdump -m avr -D file.hex
[14:15:34] <|DM|> didnt know the -S switch worked here too
[14:16:11] <cehteh> i dont use that so much so maybe you need to tinker with it
[14:16:21] <|DM|> ok
[14:16:51] <cehteh> reminds me that i could push my project to the git server :D
[14:17:50] <|DM|> http://pastebin.com/pbMxbUdZ
[14:17:53] <|DM|> I'm using git locally
[14:18:01] <|DM|> its just too useful
[14:19:02] <cehteh> i dont care too much about the generated asm
[14:19:22] <cehteh> once this ne555 emulation need a very fast interrupt handler, that was handcoded
[14:19:32] <cehteh> but otherwise gcc is just ok for me
[14:20:14] <cehteh> http://git.pipapo.org/?p=muos;a=blob;f=src/Makefile maybe useful for you
[14:20:32] <cehteh> the project is just a big WIP :D
[14:21:24] <|DM|> I actually cant find where it puts "test2" in that disassembly
[14:21:39] <|DM|> but I do know its still in flash somewhere since its still doing indirect addressing to grab it
[14:22:25] <|DM|> are you written an os for avr O.o ?
[14:24:48] <RikusW> test2 is at .LC0 it seems to be in ram
[14:25:12] <RikusW> .L9 is the inlined sendstring
[14:25:46] <RikusW> r28+r29 = Y
[14:28:37] <|DM|> No no, I can see that in the avr-gcc assembly
[14:28:50] <|DM|> I meant in the avr-objdump I cant find where "test2" is
[14:29:19] <RikusW> ah
[14:29:31] <RikusW> grep the elf ?
[14:29:44] <|DM|> Though I did miss the .section .rodata , you'r right its in ram :)
[14:31:00] <|DM|> nope, cant find it
[14:33:01] <|DM|> _do_copy_data is doing it somehow I guess.
[14:34:26] <|DM|> yeah, its writting "test2" to the ram then calling main
[14:34:37] <|DM|> I guess that's how gcc initializes stuff
[15:20:13] <RikusW> yes, it loads the flash to ram to init
[16:09:40] <Steffanx> but you are here too roklobsta
[16:10:07] <Roklobsta> so i can laugh at the avr users
[16:10:21] <Steffanx> duh
[16:12:03] <RikusW> Roklobsta: so what do you use instead of avr ?
[16:12:41] <Roklobsta> nothing right now. embedded projects seem to be on the backburner. to busy with other crap.
[16:12:42] <Roklobsta> too
[16:13:32] <Roklobsta> I sold my AVR Raven kit to some guy for $20 the other day. At least it can gather dust on his shelf and I am $20 richer.
[16:14:00] <Roklobsta> I tried out Contiki on it and was really underwhelmed.
[16:14:46] <RikusW> I haven't done much avr stuff recently either
[16:26:10] <Steffanx> so what is rikusw up to lately?
[16:26:29] <RikusW> busy on the farm mostly
[16:26:52] <Roklobsta> what is your farm? how big is it? what animals?
[16:26:56] <RikusW> fighting runaway fires from time to time, almost no rain yet
[16:27:24] <RikusW> We have cattle, about 1400ha
[16:27:42] <RikusW> It is in South Africa
[16:28:49] <Roklobsta> 2000?
[16:29:38] * RikusW will send Roklobsta to catch a week old calf and watch as its mother chases him :-D
[16:30:13] <Roklobsta> i live in dairy country. the cows here are very very tame
[16:30:27] <Roklobsta> they are very afraid of short bursts on the car horn.
[16:30:27] <RikusW> Some cows are excessively protective
[16:31:11] <RikusW> We have mainly Nguni and some other hybrids
[16:31:45] <Roklobsta> oh. yeah those horns mean business.
[16:31:55] <RikusW> They aren't afraid of a car horn at all, though we do use it to get them moving, along with some border collies
[16:32:20] <RikusW> some of them don't have horns at all
[16:32:26] <Roklobsta> dehorn dopey fresians aren't much of a threat
[16:33:07] <RikusW> we do sometimes cut the horns, especially problem cows
[16:33:35] <RikusW> Jerseys are quite calm as well
[16:33:55] <RikusW> Though Jersey bulls are known to be unpredictable.
[16:41:57] <Roklobsta> I ran into a farmer at a trade convention recently who conceived and funded this.
http://pasturereader.com.au/ Nifty device. I think it uses an AVR
[16:43:30] <Roklobsta> RikusW: but i don't think you need it to tell you how much bare dirt you have.
[16:56:28] <tecdroid> hi
[16:56:57] <tecdroid> is there any way to get unistd without installing avr-libc-1.8.1?
[17:00:06] <apo_> Why?
[20:00:58] <fruxo> how do I prevent this: "loop_until_bit_is_set(UCSR0A, UDRE0);" from getting optimized away by the compiler? I am using the avr-libc macro.
[20:02:40] <fruxo> it's turned into a single 'in' instruction, and all following code is also discarded
[22:55:06] <rue_shop3> whats the macro loop_until_bit_is_set
[22:58:31] <Xark> rue_shop3: It is part of avr-libc and it is not obvious to me why it would be optimized out...
[22:59:06] <Xark> (maybe newer toolchain with older headers?)
[22:59:12] <Tom_itx> http://www.8051projects.net/files/public/1242392126_2569_FT22383_avr_tutorial.pdf
[22:59:15] <Tom_itx> P.25
[22:59:33] <Tom_itx> loop_until_bit_is_set
[22:59:33] <Tom_itx> (
[22:59:33] <Tom_itx> WARTEPIN, WARTEBIT
[22:59:33] <Tom_itx> )
[22:59:33] <Tom_itx> ;
[22:59:44] <Tom_itx> While
[22:59:44] <Tom_itx> (
[22:59:44] <Tom_itx> !
[22:59:44] <Tom_itx> (
[22:59:44] <Tom_itx> WaitingPin &
[22:59:44] <Tom_itx> (
[22:59:45] <Tom_itx> 1
[22:59:45] <Tom_itx> << WaitingBit
[22:59:46] <Tom_itx> ))
[22:59:46] <Tom_itx> )
[22:59:47] <Tom_itx> ;
[22:59:54] <Tom_itx> damn tabs
[22:59:59] * Xark notes "needs more CR/LF". :)