Back
[00:06:09] <julmuri> Thanks Xark. I still get the error, but I guess it should be safe to just define it empty
[00:06:38] <Xark> julmuri: Yep.
[01:50:18] <darsie> hi
[01:51:19] <darsie> Why does changing a variable from uint32_t to long long add 11 kb?
[01:52:30] <darsie> I use * and / with it.
[01:52:38] <darsie> is it really that complicated?
[01:53:01] <Richard_Cavell> Hi megalo
[01:53:08] <Richard_Cavell> darsie: *shrug*
[02:37:18] <darsie> I reported it to avr-libc-dev@nongnu.org, but if anyone wants to take a look:
http://pastebin.com/ENT4RiMk
[02:38:38] <darsie> ohh, yeah, so I use avr libc.
[02:43:22] <OndraSter_> there is nothing wrong on avr libc
[02:43:29] <OndraSter_> on using*
[02:44:13] <darsie> This should be optimized.
[02:46:48] <darsie> Or is this an avr-gcc issue? Or is avr-gcc a part of avr libc?
[02:49:28] <hackvana> darsie: long long is 64 bit, not surprised to hear more stuff's pulled in. Checking your link map will show you what got included.
[02:50:48] <darsie> hackvana: It's ok to be longer than 32 bit arithmetik. But 7974 vs. 314 byte is far from optimal.
[02:52:43] <darsie> I don't understand the .map file.
[02:53:32] <OndraSter_> But 7974 vs. 314 byte is far from optimal.
[02:53:33] <OndraSter_> holy cow
[02:53:42] <OndraSter_> do you have enabled --gc-sections?
[02:53:49] <darsie> dunno
[02:53:50] <OndraSter_> and -ffunction-something
[02:54:39] <darsie> OndraSter_: Can you compile the program and tell me your binary size?
[02:54:47] <OndraSter_> let me see
[02:57:57] <OndraSter_> even with the highest compilation options i thas got over 7.3kB
[02:58:22] <darsie> thx
[02:58:42] <OndraSter_> 0000019a <__udivdi3>:
[02:58:44] <OndraSter_> this is the prblem
[02:58:45] <OndraSter_> problem
[02:59:08] <OndraSter_> removing %10 it drops to 4.5kB
[03:02:07] <CapnKernel1> See if you can do the same sum with left shifts, additions and right shifts.
[03:04:16] <darsie> CapnKernel1: atm it fit's in my mega168. I hope this will be fixed by the avrlibc/avrgcc people. But if I need the space I'll try that.
[03:04:29] <OndraSter_> fixed?
[03:04:33] <OndraSter_> a) modulo division is awfuly long on avr
[03:04:37] <darsie> My calculation is actually total*1000*60/ai/k%10
[03:04:58] <darsie> OndraSter_: So it has to be that long?
[03:05:17] <OndraSter_> unless you want to go asm and repimplement it yourself, yes
[03:05:49] <darsie> And 32 bit arithmetic is so much shorter?
[03:05:58] <OndraSter_> unless you do modulo, yes
[03:06:24] <darsie> I do the same thing, just uint32_t --> 314 byte.
[03:06:30] <OndraSter_> hmm
[03:06:41] <OndraSter_> one has to ask why is modulo on 64bit so much longer
[03:06:46] <darsie> yes
[03:10:51] <specing> darsie: go check the instruction set reference and you will see:
[03:11:12] <specing> a) AVR is an 8-bit architecture (That means using 8-bit integers will be the fastest)
[03:11:37] <specing> b) It has no division or modulo instructions (Therefore the compiler has to EMULATE them)
[03:12:49] <OndraSter_> http://i.imgur.com/zjEG6.jpg
[03:12:49] <OndraSter_> yay
[03:13:00] <specing> if you want it "fixed" then go take an ARM and do it on there
[03:13:58] <specing> < darsie> I reported it to avr-libc-dev@nongnu.org, but if anyone wants to take a look:
http://pastebin.com/ENT4RiMk
[03:14:07] <specing> Enyoj being laughed at/ignored
[03:14:14] <specing> Enjoy*
[03:14:40] <hackvana> darsie: Don't worry about specing. I think it's a fair question.
[03:14:52] <darsie> specing: Very well. it emulates 32 bit integer arithmetic in 314 bytes. I can't believe 64 bit emulation needs to be 7974 byte.
[03:17:00] <specing> Why? The thing should grow exponentially in size
[03:17:34] <OndraSter_> why?
[03:17:51] <darsie> I can do 20 digit divisions on paper with the same algorithm I use for 10 digit divisions.
[03:20:47] <darsie> bc(1) does arbitrary size arithmetic with less than exponential complexity.
[03:21:30] <specing> darsie: the algorithm is the same, yes; but the number of steps in it grows exponentially
[03:21:59] <darsie> Then the execution time should grow exponentially, not the code size.
[03:22:21] <darsie> maybe my statement about bc was wrong, then.
[03:24:13] <specing> Maybe the loops are unrolled
[03:24:22] <specing> Do you use -O3 or -funroll-loops?
[03:24:48] <darsie> -Os it seems
[03:24:53] <OndraSter_> I tried it with -Os
[03:29:47] <specing> 32 bit arith is 274 bytes here
[03:30:03] <OndraSter_> that's fairly a lot
[03:30:20] <OndraSter_> considering it has got division. multiplication, 32bit registers natively
[03:30:33] <specing> what?
[03:30:38] <CapnKernel> What is an "it"?
[03:30:38] <OndraSter_> ARM
[03:30:43] <specing> atmega8
[03:30:47] <OndraSter_> oh
[03:30:51] <OndraSter_> I thought you had it on your stellaris
[03:31:04] <specing> Wooh 7206 bytes
[03:33:31] <specing> 2ce: a9 86 std Y+9, r10 ; 0x09
[03:33:34] <specing> 2de: e9 84 ldd r14, Y+9 ; 0x09
[03:33:42] <specing> Yup its gcc being a dick again
[03:34:13] <OndraSter_> heh
[03:34:17] <OndraSter_> it must have run out of regisers :D
[03:34:19] <OndraSter_> registers
[03:34:20] <OndraSter_> what is in Y?
[03:34:34] <specing> yup I think so too
[03:34:54] <specing> 8bytes / 8bytes takes up all the upper registers
[03:35:05] <specing> Now what about pointers? :)
[03:35:17] <specing> GCC should use lower registers more often
[03:35:50] <specing> gotta love 18 ldd's in a row
[03:36:03] <OndraSter_> :P
[03:36:04] <OndraSter_> yes
[03:36:14] <specing> well atleast it progressed away from using lds!
[03:36:15] <specing> :)
[03:36:37] <OndraSter_> not always
[03:36:40] <OndraSter_> I had 50 sts in a row
[03:36:43] <OndraSter_> aka 50x4 bytes :D
[03:36:46] <specing> 0.o
[03:36:54] <OndraSter_> with -O3 that is
[03:37:01] <specing> did you force it into using std with assembly?
[03:37:29] <OndraSter_> o
[03:37:30] <OndraSter_> no
[03:37:41] <OndraSter_> I will be rewriting parts of it in assembly once I finish it
[03:37:42] <specing> //force the compiler into using relative addressing:
[03:37:43] <specing> asm volatile ("" :: "z" (pdata));
[03:37:46] <OndraSter_> to fit all the code in 4kB
[03:37:55] <specing> where pdata is a C pointer
[03:38:56] <specing> I think you should just drop C and write a high level assembler
[03:39:01] <specing> :)
[03:39:11] <OndraSter_> ;D
[03:39:14] <OndraSter_> high level assembler?
[03:39:17] <specing> yes
[03:39:43] <CapnKernel> C is high level assembler.
[03:39:47] <OndraSter_> :D
[03:39:50] <specing> well something with the performance of pure assembly and ease of use equalling that of a C compiler
[03:39:56] <CapnKernel> Portable high level assembler.
[03:39:56] <specing> CapnKernel: not even close
[03:40:16] <CapnKernel> It is when you write in Python :-)
[03:40:22] <specing> haha
[03:40:34] <darsie> I got a reply:
https://lists.nongnu.org/archive/html/avr-libc-dev/2012-11/msg00013.html
[03:41:02] <specing> darsie: Already?!
[03:41:13] <darsie> specing: yes
[03:41:29] <OndraSter_> what
[03:41:31] <OndraSter_> is he
[03:41:32] <OndraSter_> talking about?
[03:41:38] <specing> Maybe we should all upgrade to GCC 4.9!!!
[03:41:48] <specing> gcc version 4.5.3 (GCC)
[03:41:51] <darsie> about my report to the avr-libc-dev list.
[03:41:54] <specing> Time for upgrade ;P
[03:41:59] <OndraSter_> how can he be using gcc 4.7.2 when Atmel has not released that?
[03:42:07] <OndraSter_> because not all patches are usable on 4.7.2 directly
[03:42:11] <OndraSter_> I tried :P
[03:42:46] <OndraSter_> and without those patches you do not get almost any newer chip
[03:43:01] <OndraSter_> nor DES instructions I think either
[03:44:17] <specing> OndraSter_: I think my puny atmega8s will still work
[03:44:23] <specing> lol
[03:44:24] <OndraSter_> those will
[03:44:35] <OndraSter_> btw, arduino is stuck with old gcc (4.5.3 I think?) because newer gcc does not compile their code :P
[03:44:40] <OndraSter_> because their code is buggered
[03:44:43] <specing> Haha
[03:44:44] <specing> :)
[03:44:54] <OndraSter_> that's why I can not use arduino base for my xboard
[03:44:55] <specing> Now...
[03:45:10] <specing> Should I use 4.7.2 or just compile gcc from trunk?
[03:45:15] <OndraSter_> I will rewrite SPI, .. libs and use regular SD drivers etc
[03:45:19] <OndraSter_> well
[03:45:22] <OndraSter_> what distribution?
[03:45:27] <specing> Gentoo :)
[03:45:28] <OndraSter_> gentoo maybe updated those patches
[03:45:37] <OndraSter_> http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1/avr/
[03:45:39] <OndraSter_> check avr-patches
[03:46:05] <OndraSter_> if I were to use linux I would probably use gentoo
[03:46:25] <OndraSter_> I think that my gentoo's VM has got avr tools from portage
[03:46:34] <specing> yes
[03:46:40] <specing> and gcc is from crossdev
[03:46:47] <OndraSter_> ye
[03:46:51] <specing> Though I have my avr-gcc built off-tree
[03:47:38] <OndraSter_> hmm why my gentoo vm is stuck on grub..
[03:47:45] <OndraSter_> like if there was no boot list
[03:48:02] <OndraSter_> meh school today, not going there
[03:48:22] <specing> hehe
[03:48:27] <specing> No uni for me today
[03:48:28] <specing> :)
[03:49:56] <specing> So, should I trunk or 4.7.2?
[03:50:32] <OndraSter_> go with crossdev I'd say, easier to maintain :P
[03:50:39] <darsie> can I upgrade avr-gcc without upgrading gcc?
[03:50:48] <OndraSter_> they are separate gccs
[03:50:52] <OndraSter_> what OS, darsie ?
[03:50:56] <darsie> debian
[03:51:01] <OndraSter_> hmm
[03:51:24] <hackvana1> apt-get walking-frame
[03:51:24] <specing> Im wondering how long will git-svn checkout of gcc take... lol
[03:51:39] <darsie> 4.7.2 is not yet in debian. I would have to install it from upstream.
[03:51:40] <OndraSter_> specing, it was fast for me
[03:51:40] <specing> apt-get walk-the-plank
[03:52:10] <darsie> Maybe 4.7.0 work's too. It's in debian.
[03:52:23] <specing> o.0 debian is getting updated
[03:52:29] <specing> What is the world coming to?
[03:52:42] <specing> OndraSter_: how many GB?
[03:52:56] <darsie> It's in debian/testing ... so maybe I need to compile it or so.
[03:52:57] <specing> OndraSter_: going to checkout it to RAM and then do a squashfs from it and mount it
[03:53:01] <specing> it'll be FAST
[03:53:24] <OndraSter_> :D
[03:53:30] <OndraSter_> debian stable has 4.3.5 WTF
[03:53:36] <specing> OndraSter_: What is its size?
[03:53:44] <OndraSter_> of what?
[03:53:44] <specing> of the git-svn checkout?
[03:53:48] <OndraSter_> duh
[03:53:51] <OndraSter_> I have it in another VM
[03:53:53] <OndraSter_> which is not booted
[03:53:57] <specing> \o/
[03:54:04] <specing> BOOTZ ALL ZEE VMS!
[03:54:11] <OndraSter_> I have got only 16GB RAM
[03:54:14] <specing> lol
[03:54:22] <specing> 4GB here
[03:54:24] <OndraSter_> when I start both debian and w7 x64 I am done with VMs
[03:54:26] <specing> I'll mount zram
[03:54:32] <OndraSter_> that's 2x4GB for them
[03:54:37] <specing> How much did you give to debian?
[03:54:40] <OndraSter_> and I usually occupy about 6GB RAM
[03:54:42] <OndraSter_> 4GB to debian
[03:54:45] <specing> I have debian running on 64 MB
[03:54:45] <OndraSter_> 4GB to w7
[03:54:47] <specing> LOL
[03:54:57] <OndraSter_> I will be upgrading to 24GB RAM soon
[03:55:19] <OndraSter_> and my host OS has got the remaining 8GB (w7 x64 it is)
[03:55:30] <specing> What are you running on that debian that it needs 4GB ram?
[03:55:38] <OndraSter_> I just don't like limiting them
[03:55:39] <OndraSter_> :D
[03:55:50] <specing> lowest I've got debian to is 20MB
[03:56:27] <OndraSter_> I lied, I don't have gcc from git or svn or anything, I downloaded standalone gcc-4.7.2.tar.bz2 archive
[03:56:33] <OndraSter_> unpacked sources have got 840MB
[03:56:42] <OndraSter_> tar bz2 is 81MB
[03:56:47] <specing> http://en.gentoo-wiki.com/wiki/Zram_disks
[04:25:59] <amee2woof> specing: i tried to install deb 4 on a 128M CF card last summer and it didn't have enough space
[04:26:25] <specing> 0.o git svn is at r80
[04:26:29] <amee2woof> and 24GB of RAM is almost enough to run firefox \o/
[04:26:32] <specing> only 600000 revisions to go! :D
[04:26:57] <specing> amee2woof: Tried voyage?
[04:27:06] <amee2woof> is that edible?
[04:27:14] <specing> firefox runs fine in my 256M debian VM
[04:28:56] <amee2woof> then you're not running much else besides ff on that :P
[04:29:44] <specing> true
[04:29:54] <specing> other than java
[04:30:04] <specing> since my uni forces that hell upon me
[04:30:06] <day> my firefox alone eats 250mb+
[04:31:16] <specing> /dev/zram0 4.0G 29M 4.0G 1% /mnt/test
[04:31:24] <specing> Here we go, gcc clone on zram
[04:40:50] <OndraSter_> lol, Dave from EEVBlog uploaded a video about delay line teardown. Mike, few hours after that, uploaded video about using it as a memory :D
[04:41:01] <OndraSter_> Mike ftw
[04:47:58] <RLa> figured out the nixie tubes i have, are in12-b, quite popular and still available at low prices
[04:48:31] <RLa> i have 7 of them, soldered to some sort of pcb i'm going to reuse
[04:54:05] <specing> Oh nice they have a git mirror too
[04:54:22] <specing> This will be like a gazillion times faster than svn
[04:54:58] <specing> I wonder how long it took for Linus to thrash SVN after they couldn't use perforce anymore
[04:55:07] <specing> I think it was under a minute
[04:55:25] <OndraSter_> I should write code for my reflow oven
[04:55:30] <OndraSter_> and order parts for it already damnit
[04:56:44] <specing> I though your mom's oven was good enaugh ;)
[04:56:54] <specing> gotta love leaded cakes :D
[04:56:58] <specing> mmm
[04:57:03] <OndraSter_> heh
[04:57:18] <specing> heheeh
[05:04:03] <OndraSter_> PORTC.OUTCLR = 1 << 1 | 1 << 4 | 1 << 5 | 1 << 6 | 1 << 7;
[05:04:05] <OndraSter_> PORTC.OUTSET = (Data & (1 << 0)) << 1 | (Data & (1 << 1)) << 4 | (Data & (1 << 2)) << 5 | (Data & (1 << 3)) << 6 | (Data & (1 << 4)) << 7;
[05:04:06] <OndraSter_> yay
[05:04:07] <OndraSter_> :D
[05:04:17] <OndraSter_> I do wonder how it will look compiled
[05:04:26] <specing> ldi
[05:04:27] <specing> out
[05:04:29] <specing> ldi
[05:04:30] <specing> out
[05:04:33] <specing> Simple, eh?
[05:04:42] <hackvana1> specing: Linus never used Perforce, or not for Linux at least.
[05:05:21] <OndraSter_> specing, :P
[05:06:03] <hackvana1> For a time, Linus used BitKeeper, by BitMover Corp.
[05:06:57] <specing> hackvana1: Ah no, it was bitkeeper, yes
[05:07:11] <specing> not sure where I got perforce
[05:08:29] <hackvana1> I was in the audience when we watched Andrew Tridgell "crack" BitKeeper:
http://lwn.net/Articles/132938/
[05:27:25] <karlp> hmm, integer to float conversion is not fixed time, it seems to depend on the input integer.
[05:27:28] <karlp> that was unexpected.
[05:31:25] <specing> float on AVR?
[05:31:32] * specing abandon ship
[05:33:36] <RLa> are there any floting point instructions at all?
[05:34:15] <karlp> well, I have huundreds of milliseconds, and it gives the correct results, I just assumed it would stay consistent time wise.
[05:34:42] <karlp> RLa: I generally don't care too much what instructions are in the processor, but what operations the language I'm compiling offers.
[05:35:25] <RLa> those operations could add loads of code to the resulting machine code
[05:35:40] <karlp> which I'm well aware of, and am not concerned by.
[05:35:44] <karlp> I have time and space,
[05:35:53] <karlp> I was just expecting consistently "slow"
[05:36:49] <specing> RLa: no fpu
[05:40:55] * RikusW just got a at32uc3b0512 for free
[05:41:03] <RikusW> without a VDDIN pin :-|
[05:41:11] <Richard_Cavell> RikusW: How big are they compared to AVR8?
[05:41:14] <Richard_Cavell> I mean, physically
[05:41:19] <RikusW> tiny
[05:41:28] <RikusW> 64pin tqfp with 0.5mm spacing
[05:41:34] <Richard_Cavell> oh ok
[05:41:44] <OndraSter_> same size as regular AVR
[05:46:12] <Richard_Cavell> RikusW: Man I'm so excited about my present project
[05:46:15] <Richard_Cavell> I've been building it for weeks
[05:46:17] <Richard_Cavell> taking ages
[05:46:31] <Richard_Cavell> I'm using Mum's side of the dining table so she's had to have her dinner on a tray
[05:46:38] <RikusW> yeah, this stuff can take a lot of time
[05:46:51] <RikusW> and she's happy with that ? ;)
[05:47:00] <Richard_Cavell> she says she's okay with it
[06:04:10] <day> is the only difference between 8/16/32/64bit systems the register size?
[06:05:53] <Horologium> registers, commands, bus width, etc.
[06:07:15] <Horologium> you might want to study the 4004, 8008, 8088, 8086, 80186, 80286, 80386, then jump to the 64bit x86 compatible chips
[06:12:56] <day> Horologium: thanks
[06:15:45] <RikusW> AVR would be simpler to learn
[06:16:04] <RikusW> though 4004 is pretty simple
[06:16:30] <Horologium> 4004 was simple.
[06:16:38] <Horologium> 4bit processor,,gotta love it.
[06:17:25] <Horologium> but the question was more to the point of the difference in 8/16/32/64 bit architectures.
[06:17:36] <Horologium> the 4004 goes back even farther to 4bit.
[06:18:20] <specing> My calculator is 4-bit
[06:18:20] <Horologium> with each new architecture they have added not just bigger registers but commands to handle the bigger registers as well along with wider address and data busses and reverse compatibility modes as well.
[06:19:36] <day> RikusW: im already familiar with avr 8bit uCs. i just wondered how much different the architectures are.
[06:20:24] <Horologium> if you are in for some light reading, there are datasheets out there for each of the series from intel.
[06:20:43] <Horologium> some of them make avr datasheets look like fairy tales.
[06:21:22] <Horologium> as the x86 architecture in general is,,,well,,,just mindboggling in its complexity sometimes.
[06:21:31] <day> Horologium: to be fair avr datasheets are pretty awesome..its not hard to write something worse :P
[06:21:48] <Horologium> true.
[06:21:51] <Horologium> I love them.
[06:22:07] <Horologium> that was one major reason I switched from pic to avr in the first place years back.
[06:22:38] <Horologium> that and the fact that my pic programmer wouldn't work with new pic chips and I was going to be forced to build or buy a new one.
[06:22:54] <day> Horologium: do you work with uCs or is it just a hobby?
[06:23:08] <Horologium> hobby level.
[06:23:50] <Horologium> electronics as a hobby for 30ish years and microcontrollers for about 10.
[06:23:52] <day> Horologium: y same here. im just wondering about how someone thinks about PIC from an industrialy point of view
[06:24:02] <day> Horologium: economy wise
[06:24:09] <Horologium> not sure on that.
[06:24:10] <RikusW> AVR is cheaper afaik
[06:24:32] <RikusW> day: AVR32 is more like ARM than AVR8
[06:24:34] <Horologium> I know microchip is awesome for free samples while it is almost like pulling teeth to get them out of atmel sometimes.
[06:24:40] <RikusW> the arch anyways
[06:24:49] <RikusW> it seems to share some AVR8 instructions
[06:24:50] <day> RikusW: wut? cheaper too? i mean they have far better marketing. far better toolchain (afair)
[06:25:08] <RikusW> AVR is much cheaper than equivalent PIC
[06:25:21] <Horologium> clock for clock, avr is generally cheaper than pic.
[06:25:23] <RikusW> 20MHz AVR == 80MHz PIC too
[06:25:40] <RikusW> PIC takes 4 clocks per instruction
[06:25:56] <Horologium> the new pic32 chips are rocking though.
[06:25:58] <RikusW> there are some AVR instructions taking 2 clocks, but most only 1
[06:26:11] <day> RikusW: but what is PIC thinking. they will be gone in notime at this pace :/. every student works with avr because toolchain is free. easy obtainable and so on
[06:26:14] <Horologium> RikusW, some take even more but they go by the bulk of the instructions.
[06:26:30] <Horologium> pic is very deep in the embedded market.
[06:27:02] <day> Horologium: that good and all, but if every new developer is an atmel expert and doesnt even know pic.... what is going to happen? :P
[06:27:04] <Horologium> I was curious one day a few years back and found 8 pic chips in devices I could easily take apart and no avr..but there were a lot of atmel chips of other kinds.
[06:27:33] <Horologium> there are still a lot of people out there using chips other than avr.
[06:27:42] <Horologium> including the old standby 8051/8052 series chips.
[06:28:21] <Horologium> I would bet a dollar that the 8051/2 is still the most popular embedded microcontroller for small devices across the board.
[06:28:36] <Horologium> ok, must go drain some blood and see how much rat poison is in my system!
[06:31:03] <day> Horologium: hf or better gl
[06:36:25] <specing> RikusW: 20MHz AVR != 80MHz PIC
[06:36:36] <RikusW> why not ?
[06:36:49] <specing> How can a banked architecture with a single working register compare to an AVR?
[06:37:16] <specing> its more like 20MHz AVR = 300MHz PIC
[06:37:27] <RikusW> lol
[06:37:39] <RikusW> I meant mips only
[06:37:58] <RikusW> AVR != PIC ever :-P
[06:40:33] <OndraSter_> :P
[06:41:20] <OndraSter_> I found probably atmega8 in HTC HD2
[06:41:27] <OndraSter_> it was from atmel and ended with "ga8"
[06:41:39] <OndraSter_> the rest was under a shielded can's edge
[06:41:53] <OndraSter_> just as some wireless chips
[06:42:00] <OndraSter_> they are often atmel too
[07:09:16] <day> ive got a question regarding program/data allocation (neumann/harvard architecture)
[07:10:13] <day> if i declare a variable "i". lets say int i; and during the program i calculate something that get saved in this variable i =a+b; for example
[07:10:31] <day> the value will be saved in the data section right?
[07:11:09] <RikusW> in RAM yes
[07:11:14] <day> but what happens if i invoke the same variable this way int i=0xff;
[07:11:24] <day> basically a constant
[07:11:27] <RikusW> in a function it will be on stack not .data
[07:11:49] <specing> 0.o my hexdump code finaly works
[07:11:49] <day> but where is it in the first place?
[07:11:58] <RikusW> gcc will copy the default values from flash to ram as part of init
[07:12:20] <day> specing: this happens during the uC bootup?
[07:12:21] <RikusW> the actual variable will be in RAM not flash
[07:12:33] <RikusW> yep
[07:12:33] <specing> day: .bss is for constants
[07:12:46] <specing> though technically, your i isn't constant
[07:13:06] <specing> though the compiler will usually optimize it away if you do not store anything else past that in it
[07:13:26] <specing> and just make it into one single andi rX, 0xFF instruction
[07:13:32] <specing> day: try it
[07:13:37] <specing> day: make a testcase
[07:13:44] <Tom_itx> a constant would be declared as #define I 0xFF
[07:13:51] <specing> compile with -Os, -O0, -O2 and see what happens
[07:13:51] <Tom_itx> not int i=0xFF
[07:14:11] <RikusW> day if you do say x &= 0xFF;
[07:14:21] <RikusW> that fill be part of the instruction itself
[07:14:28] <RikusW> andi r16,0xFF
[07:14:43] <RikusW> immediate value in instruction
[07:15:40] <day> specing: right now im invoking a small array int array[10] with 10 predefined values. this function gets called a lot which means the declaration happens often too. and this just looks like a bad idea :/
[07:16:14] <RikusW> its all on stack
[07:16:27] <RikusW> well, it gets copied from flash...
[07:16:33] <specing> day: we can't help if you don't provide a testcase...
[07:16:33] <day> RikusW: but only once?
[07:16:45] <RikusW> each time the function is called i'd say
[07:16:53] <day> specing: its less a test case than a i want to understand case ioi
[07:17:58] <RikusW> day, you could always look at the disassembly to see whats actually going on
[07:19:50] <Tom_itx> declare it globally
[07:20:01] <Tom_itx> then it's initialized once
[07:21:06] <RikusW> and maybe do const int array ?
[07:22:55] <Tom_itx> external global atomic volatile const int array
[07:22:57] <Tom_itx> pick one
[07:23:06] <day> can i take all?
[07:23:13] <day> just kidding
[07:24:12] <specing> lulz
[07:29:02] <day> does anyone know a good information source about ram handling? i dont quite get this atm :/ i understand that the uC has a Ram which gets used by the stack (top to bottom) and what else does use it? its probably chopped in 8bit fragments(register) do i can access each of them indipendently? additionally to these Ram (registers?) ive a few more or less multi purpse registers r0-r31.
[07:29:35] <day> is that basically right?
[07:30:39] <OndraSter_> RAM is used also for .data section
[07:30:40] <OndraSter_> and heap
[07:31:16] <RikusW> day: the registers r0-r31 IO and extended IO are memory mapped into "RAM"
[07:31:25] <RikusW> r0 at address 0
[07:31:31] <RikusW> IO at 0x20
[07:31:47] <RikusW> extended IO at 0x60
[07:31:50] <RikusW> and RAM at 0x100
[07:31:57] <OndraSter_> http://thepraguething.wordpress.com/2012/11/08/33-things-ive-learnt-from-prague/
[07:31:58] <RikusW> or 0x60 if no ext IO is present
[07:32:04] <day> RikusW: means they are basically part of the ram. they are just better wired -> more functions
[07:32:17] <RikusW> its memory mapped
[07:32:25] <karlp> specing: bss isn't for constants, its for things that need zeroing.
[07:32:38] <OndraSter_> .data is for constants
[07:32:42] <RikusW> IO can be accessed with a memory pointer or IN/OUT instructions
[07:33:52] <day> RikusW: memory mapped means the memory is basically a pointer to the register which is physically somewhere else?
[07:34:08] <RikusW> yes
[07:34:22] <RikusW> do you know how address decoding works ?
[07:34:59] <RikusW> something like 74LS138 can be used to do it for 3 bits
[07:35:13] <day> RikusW: you mean this
http://en.wikipedia.org/w/index.php?title=File:2to4demux.svg&page=1 ?
[07:35:33] <RikusW> that too
[07:35:46] <day> RikusW: then yea
[07:36:23] <RikusW> AVR flash is accessed using SPM andLPM
[07:36:39] <RikusW> normal ram with LD/ST
[07:37:00] <Tom_itx> day, not exactly what you're looking for but you should read these articles:
http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/progmem_basics_index.php
[07:37:01] <RikusW> did you read it AVR instruction set doc yet ?
[07:37:16] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_eeprom_index.php
[07:37:40] <day> RikusW: yes i did read it
[07:39:32] <specing> karlp: yep
[07:39:53] <RikusW> good
[07:42:02] <day> variables get saved on the stack if they are invoked inside of a subfunction? if its in main/global/etc. they will be in the "basic ram"?
[08:47:54] <day> thanks for your help guys :)
[08:57:17] <RikusW> yes
[08:57:42] <rue_mohr> it depends, you can stop the compiler at the assembler stage to find out
[08:58:28] <rue_mohr> if you do chat temp = 4; for(i = temp; i<8; i++) { ...
[08:58:38] <rue_mohr> it'll just skip existance of the variable all togethor
[09:20:24] <RikusW> http://dvice.com/archives/2012/10/ethiopian-kids.php
[09:22:39] <hackvana> Mission successful I'd say.
[09:23:16] <hackvana> LOL that he makes a point of saying "neighborhood" is correctly spelled. The majority of the world's English speakers would disagree.
[09:32:22] * RikusW wonders why the little black boxes in vehicles are so crazily expensive....
[09:32:40] <RikusW> a traction control unit is like 400 euro
[09:32:54] <RikusW> and contains only like 2 or 3 E worth of parts
[09:33:12] <hackvana> Because they can?
[09:33:16] <hackvana> Because of supply and demand?
[09:33:29] <RikusW> 4011 4081 4x 2A transistors, C277c opamp a few caps a few resistors
[09:33:36] <RikusW> still crazy
[09:33:37] <hackvana> Because of the insurance they have to pay for to cover themselves in case a unit fails and kills someone?
[09:33:39] <OndraSter_> hehe
[09:33:57] <RikusW> I replaced a single burnt transistor using one from my pile of scrap
[09:34:12] <RikusW> no 2A replaced by 8A darlington
[09:34:20] <RikusW> *now
[09:34:52] <RLa> repairing self-driving cars from future will be fun
[09:35:29] <RikusW> if the computer in that car crash.......
[09:35:39] * RikusW don't want M$ OS on such a car
[09:36:33] <RLa> you would periodically have to close all windows and restart it :)
[09:36:53] <RLa> but i do not want imagine the blue screen of death
[09:38:51] <RikusW> closed windows leads to a hot interior :-P
[09:57:06] <konsgn_pi> greetings
[09:57:44] <OndraSter_> eloooo
[10:45:09] <OndraSter_> Arduino, y u so suck!
[10:45:33] <OndraSter_> when I am writing PWM value to a pin and then want to change it back, I have to disconnect the PWM output. That means on EVERY pin change I have to check PWM.. :/
[10:55:57] <OndraSter_> at least that on xmega *any* pin is PWM capable
