Back
[03:52:11] <Tom_itx> in studio 6.1 now, you have to reselect the programmer every time you change the device. not an improved feature from previous versions
[06:14:04] <Roklobsta> curios, does avrgcc produce much the same code if you do a big switch/case vs if/elseif?
[06:15:42] <Grievre> Roklobsta: Probably depends on the optimization level
[06:18:06] <Roklobsta> i had a quick scan of lufa and saw some big elseifs and pondered using that vs switch
[06:18:19] <Roklobsta> i guess in the end what is more readable?
[06:19:14] <theBear> if it's a straight switch case statements always make more sense, if it's got some degree of multi-level ness ifs are more sensible
[06:19:56] <Horologium> case is good for one comparison and multiple selections....if/elseif is good if you have to check different things at different points in your comparison...
[06:20:02] <Horologium> what theBear said too..yeah, that.
[06:21:14] <Roklobsta> right of course
[06:21:43] <Roklobsta> i do recall seeing a few of the lufa elseif occasionally evaluate more than one common term.
[06:23:45] <Horologium> I've been known to use if/else inside case too.
[06:50:02] <twnqx> and jumptables > *
[09:23:33] <megal0maniac> Tom_itx: Does your programmer work in AS6.1?
[09:24:22] <megal0maniac> And if so, what did you change? Because the latest stable LUFA release won't work due to outdated "firmware"
[09:35:34] <megal0maniac> Well so much for cloaking :/
[09:48:19] <Essobi> lol
[09:56:08] <RikusW> megal0maniac_afk: using afrihost too ?
[09:56:55] <RikusW> megal0maniac_afk: I think the mkii worked in AS6.0 and AS4 on a plain XP box
[09:57:11] <RikusW> you could modify the fw version in the LUFA source
[09:57:20] <RikusW> just find out what the new AS expects
[09:57:34] <RikusW> it should be in hte mkii docs that came with AS
[09:57:45] <RikusW> or maybe the update box mentions it
[10:07:03] <RikusW> chips anyone ?
https://lh5.googleusercontent.com/-cmRQPdNxvZI/UcgWRnBQ47I/AAAAAAAAx-E/VUwO5Qi59Mo/w506-h487-o/Via_gra.jpg
[10:44:20] <Gumboot> ambro718: Had a bit of a fiddle on paper with mulitplication and I figure that really the biggest gain mightn't come from n*n+n+n opportunities, but in flattening the results of the multiplies into four 32-bit words and summing those at appropriate offsets.
[10:44:54] <Gumboot> Shoud be about 12 adds for 32x16 unsigned. Maybe 14 for signed.
[10:45:51] <ambro718> Gumboot: yeah
[10:45:52] <Gumboot> If you look at all the 16-bit results of multiplies in a multi-byte multiply, and just move them around so they don't overlap, and then do the sums with the resulting words.
[10:46:20] <ambro718> I looked a bit and the thing is, you never add just 8 bits, always 16 bits
[10:46:23] <Gumboot> To make an UxU multiply UxS, you can test the sign bit and conditionally subtract the other operand from the top.
[10:46:48] <ambro718> Gumboot: write the assembly :P
[10:46:58] <Gumboot> Need to getmyself set up with a simulator.
[10:47:20] <Gumboot> That and I just idly scribble notes on bits of paper between builds. If I actually wrote code in that time I'd feel like I was goofing off.
[10:48:20] <Gumboot> I could see something obviousy, but becuase MUL touches the carry flag it broke.
[10:48:28] <Gumboot> s/obviousy/obvious/
[10:52:24] <Gumboot> That is, I saw two adc x, #0 operations in a row, and thought I could just slip another mul in between and make them adc x, r0 / adc x, r1 and delete a whole row out of the code, but ..yeah. More temp registers, more movw cycles.
[10:55:01] <ambro718> Gumboot: oh by the way, I was able to optimize the division for my use case significantly. The biggest speedup was when I realized I only needed the last 14 or so bits of the result, and if the result happens to be bigger due to rounding it should be saturated. The thing is, appropeiately removing the division iterations for those high bits achieves just that :D
[10:56:53] <ambro718> my division of (13bit<<16)/16bit saturated to 15 bits now takes 174 cycles hehe
[10:56:53] <braincracker> h
[10:58:51] <braincracker> Roklobsta_ <= if is if...
[10:59:44] <braincracker> if is a compare and jump if false
[11:00:03] <braincracker> case can be cased with a translafte table
[11:13:48] <Gumboot> ambro718: It's almost always the case that people need only a tiny fraction of the arithmetic they start out with.
[11:14:03] <Gumboot> Hence the not-dead-yet C64 demo scene.
[11:44:03] <braincracker> hey guys, what is this shit?
http://www.datasheetarchive.com/TP8452AP-datasheet.html i picked up a dozen ball mouses for $5
[11:44:16] <braincracker> i'd guess it is an OTP PIC
[11:44:32] <braincracker> it has a PR header on board
[12:05:44] <Casper> braincracker: it's a mouse IC
[12:06:14] <braincracker> yes i think it is a pic with a mouse ic program sold as mouse ic
[12:06:40] <Casper> 3 button ball type mouse with ps/2 interface
[12:06:54] <Casper> what make you think it's a pic?
[12:09:45] <Casper> btw braincracker, datasheetarchive suck imo, try
http://www.alldatasheet.com/view.jsp?Searchword=TP8452AP
[14:16:34] <ambro718> What is the fastest way to increment a 16-bit integer by one? This works: "subi A,-1; sbci B,-1" but it needs an upper register.
[14:16:43] <ambro718> can it be done in 2 instructions on any register?
[14:17:13] <specing> uhm increment?
[14:17:25] <specing> Why sub?
[14:17:31] <ambro718> I need to increment it
[14:17:41] <ambro718> there's no adi but there is subi
[14:17:46] <specing> inc A, adc B,_zero_reg_?
[14:18:22] <ambro718> nope, inc doesn't set carry flag
[14:19:09] <specing> It doesen't? :O
[14:21:53] <specing> Looking at gcc's output:
[14:21:57] <specing> ++ big;
[14:21:57] <specing> 60: 89 81 ldd r24, Y+1 ; 0x01
[14:21:57] <specing> 62: 9a 81 ldd r25, Y+2 ; 0x02
[14:21:57] <specing> 64: 01 96 adiw r24, 0x01 ; 1
[14:21:57] <specing> 66: 9a 83 std Y+2, r25 ; 0x02
[14:21:58] <specing> 68: 89 83 std Y+1, r24 ; 0x01
[14:22:26] <specing> adiw reg,0x01 is what you want
[14:22:30] <specing> one instruction! :D
[14:22:43] <ambro718> two cycles though
[14:23:26] <specing> Still better than your "optimization"
[14:23:29] <specing> :D
[14:23:36] <ambro718> and it limited to upper register pairs, so it's really worse than my code
[14:24:18] <ambro718> my subi+sbci is 2 cycles and works with r16-r31, adiw is 2 cycles and works with r24-r30 ;)
[14:24:31] <specing> well that sucks
[14:24:41] * specing hugs his ARM
[14:27:03] <ambro718> ah, I was able to make gcc happy with my asm by turning "=&a" into "=&w"
[14:27:55] <ambro718> but I probably should have been using "=&d" all along, lol
[14:29:33] <ambro718> or could using "=&d" have unintended consequences?
[14:29:40] <ambro718> I don't use pointers in my asm code
[14:29:53] <specing> Got 3 instructions...
[14:29:56] <specing> ++ big;
[14:29:57] <specing> ca: ff ef ldi r31, 0xFF ; 255
[14:29:57] <specing> cc: af 1a sub r10, r31
[14:29:57] <specing> ce: bf 0a sbc r11, r31
[14:30:10] <specing> Took a while to trick gcc into not using ldd/std
[14:30:34] <specing> dc: 0f 5f subi r16, 0xFF ; 255
[14:30:34] <specing> de: 1f 4f sbci r17, 0xFF ; 255
[14:30:38] <ambro718> specing: you can also just do: sec; adc A,__zero_reg__; adc B,__zero_reg__
[14:30:41] <specing> 2 instructions
[14:30:49] <specing> for upper regs
[14:31:08] <ambro718> did gcc produce subi+sbci?
[14:31:11] <specing> yes
[14:31:19] <ambro718> interesting :D
[14:31:41] <specing> http://sprunge.us/UhdU
[14:34:29] <ambro718> avr-gcc has __uint24 but no __uint40/48/56
[14:34:33] <ambro718> stupid
[14:35:21] <specing> yes
[14:35:29] <specing> (to both)
[14:36:04] <specing> It is retarded to have specialized types at all
[14:36:25] <ambro718> I find __uint24 very useful
[14:36:27] <specing> since the algorithms for (basic) arithmetic are the same no matter the bit size
[14:36:40] <specing> it could just dinamically generate that code
[14:36:49] <ambro718> they are not, multiplication of 24-bit is faster than of 32-bit
[14:36:55] <specing> __uint123215 included
[14:36:57] <ambro718> at least on avr
[14:37:14] <specing> I said *algorithms* are the same
[14:37:31] <ambro718> yes, ideally you'd have parametrized types
[14:37:31] <specing> sure they take longer to process longer inputs
[14:37:36] <ambro718> like __uint(N)
[14:37:44] <specing> indeed
[14:38:34] <specing> or just u<digits> and the compiler would give you what you want
[14:38:41] <specing> or s<digits>
[14:39:17] <specing> (I have typedefs to u8,u16,u32,u64 and their signed counterparts)
[14:39:32] <ambro718> I'm essentially doing this with C++ templates,
https://github.com/ambrop72/aprinter/blob/master/aprinter/meta/ChooseInt.h
[14:39:57] <ambro718> and the actual type you use,
https://github.com/ambrop72/aprinter/blob/master/aprinter/meta/BoundedInt.h
[14:40:19] <ambro718> it's smart so that N-bit*M-bit results in (N+M)-bit
[14:40:39] <ambro718> but you can use the BoundedModule*() functions if you want modular
[14:40:46] <specing> The problem with this is that *all* programming languages I've come across in life are either:
[14:41:01] <specing> 1) Not meant to do this/ too inflexible (C/C++)
[14:41:09] <specing> 2) Slow as hell (Python)
[14:41:25] <ambro718> exactly
[14:41:44] <specing> We should create a special language for embedded! :D
[14:42:02] <ambro718> but C++ is probably the best, especially the template metaprogramming, even though it's a giant pain
[14:42:08] <ambro718> yeah, we should
[14:42:17] <specing> yes, C++ is the best one can use today
[14:42:25] <specing> but it does have its drawbacks
[14:42:37] <specing> namely the implied constructors/destructors
[14:42:52] <ambro718> the question is what to start with? an existing language like C or C++, and remove unneeded stuff and add useful stuff, or just invent something completely new
[14:42:57] <specing> an empty C++ program is going to occupy more space than an empty C one
[14:43:08] <ambro718> hm, I don't see why it would
[14:43:16] <specing> ambro718: try it
[14:43:35] <ambro718> constructors/destructors don't matter if you don't define them
[14:44:26] <specing> some are implied even if you don't define any classes
[14:44:32] <specing> try it
[14:45:06] <ambro718> tried this on x86-64: int main (int argc, char *argv[]) {}
[14:45:14] <ambro718> C 5.6K, C++ 5.7K
[14:46:10] <specing> ... see?
[14:46:24] <specing> As for the " the question is what to start with?"
[14:46:57] <specing> A good programming language is modeled around solving the problems that are present in its field
[14:47:29] <specing> atleast that is my opinion (I haven't yet taken compiler/comp lang classes)
[14:48:08] <specing> C and C++ were not meant to solve any problems we face on microcontrollers
[14:48:08] <ambro718> to make a language useful you need to do so much more than implement it
[14:48:24] <specing> they were made to be used on multi-user machines
[14:48:25] <ambro718> you probably want to interoperate with C or C++ code for example, to some degree
[14:49:05] <specing> Probably the biggest concern would be making an actually sane inline assembler
[14:49:08] <ambro718> which would mean your implementation essentially has to include a C or C++ implementation, I think
[14:49:27] <specing> no
[14:50:03] <ambro718> how are you going to use a library written in C? You'd have to parse C headers to get the declarations
[14:50:58] <specing> You won't
[14:50:59] <ambro718> but why do you think you need to fiddle with the low level stuff like assembler, couldn't you make a frontend for an existing compiler?
[14:51:41] <specing> making a frontend would imply generating C code, which has proven too inflexible for microcontrollers
[14:52:02] <ambro718> why would it imply generating C code?
[14:52:10] <specing> because it is a frontend
[14:52:20] <specing> a frontend implies having a backend
[14:52:33] <ambro718> but the backend is not C, it's whatever the abstractions are in gcc/llvm/etc
[14:53:02] <ambro718> gcc and llvm have many frontends, C and C++ being two of them
[14:53:29] <specing> actually the work needed to provide an assembly backend is minimal compared to inventing/implementing a new language compiler
[14:53:42] <specing> assembly/machine code
[14:54:05] <specing> I really, *really* hate writing parsers
[14:54:17] <ambro718> you're already implementing a new language, the question is if you're going to reuse the low-level machine-specific code in gcc or llvm
[14:54:37] <ambro718> I wouldn't dream of writing an entire compiler on my own
[14:54:52] <specing> I do
[14:54:55] <ambro718> gcc already has an avr code generator for example
[14:55:17] <specing> (which sucks, but ok)
[14:56:01] <ambro718> there's a LOT of value in what gcc already provides, lots of optimizations on the IR
[14:56:42] <specing> Yeah, I've seen those "optimizations"
[14:56:57] <ambro718> plus, by writing a frontend for gcc, your language is almost automatically implemented for any machine gcc supports
[14:58:56] <specing> And it also means I have to write a GCC backend if one of my targets is not supported by it
[14:59:02] <vectory> specing: how did you achieve those different asm instructions. from the link i cant tell what caused "subi; sbci"
[14:59:05] <specing> Look at PIC for example
[14:59:27] <specing> vectory: gcc placed that variable in upper registers
[14:59:44] <specing> that is what caused such output
[14:59:58] <vectory> O_o
[15:00:08] <specing> ambro718: a GCC PIC port was actually attempted
[15:00:21] <vectory> but, its supposed to work on lower rgs, too?
[15:00:25] <specing> but it turned out GCC assumed too much about the target machine
[15:00:30] <specing> vectory: no
[15:00:32] <ambro718> the solution is to not use PIC or other fucked up instructions sets :D
[15:00:46] <specing> there is nothing fucked up about PIC
[15:01:17] <specing> the only thing preventing me from working with PICs is a) NO FUCKING PROGRAMMER ACTUALLY WORKS
[15:01:28] <specing> b) look at (a) c) same
[15:01:50] <specing> anyway to continue
[15:01:55] <specing> < specing> but it turned out GCC assumed too much about the target machine
[15:02:04] <specing> thus it was impossible to make a backend
[15:02:30] <specing> AVR provides a more microprocessor-like (if we can talk like this) model
[15:02:35] <ambro718> yes, that's kind of what I meant by "fucked up"
[15:02:39] <specing> that GCC assumes
[15:03:16] <specing> ambro718: That is like saying all architectures that do not implement a microprocessor-like model are fucked up
[15:03:19] <specing> because they are not
[15:03:39] <specing> PIC was meant to solve micro-controlling needs, and to do it *CHEAPLY*
[15:03:56] <specing> last time I looked, PIC are generally twice cheaper than AVRs
[15:04:18] <ambro718> and they did it by not taking into consideration how compilers would be implemented, and it's their own fault
[15:04:30] <specing> because they don't have to privide 200 instructions or 32 registers (and several 128* bytes ram
[15:04:59] <vectory> so you are bound to asm? sounds good to me :D
[15:05:16] <ambro718> I'm not saying PICs are valid targets for compilers, just that I care much more about easier targets like AVR and ARM
[15:05:20] <specing> vectory: there is a SDCC compiler (small device C compiler), which I used
[15:05:31] <ambro718> * are not
[15:05:33] <vectory> which is totally buggy, i heard
[15:05:38] <specing> vectory: yes
[15:05:47] <specing> that was the (d) reason
[15:06:22] <specing> The problem with supporting PIC is that C *is* just so fucking *retarded* of a language
[15:06:35] <vectory> but i didnt hear that the pic programmers where generally bad. vice versa, my prof advertised a china made one
[15:06:55] <ambro718> specing: what in particular do you find retarded in C?
[15:07:00] <specing> vectory: I tried both a serial DIY one and a store-bought $30 one
[15:07:12] <specing> the DIY one plainly didn't work
[15:07:35] <specing> the store one didn't work (a lot of errors) as soon as I tried in-system-programming
[15:08:01] <specing> ambro718: It was never meant to be used on microcontrollers
[15:08:11] <vectory> oh, yeah i saw the zif on the their programmer *shudder*
[15:08:18] <ambro718> specing: so, what exactly?
[15:08:48] <specing> ambro718: 1) not defining an inline assembler
[15:09:15] <vectory> implementation dependent. thats actually a good thing, maybe
[15:09:29] <vectory> -actually, for what do i know
[15:09:32] <specing> ambro718: 2) not being able to make templates (C++ solves this, but adds other cruft)
[15:09:35] <ambro718> does it really bother you that much the C *standard* doesn't define an inline assembler?
[15:10:34] <ambro718> C++ solves this, and you're free to not use other cruft with no cost
[15:10:37] <specing> vectory: yes, that is another problem with C: everything is implementation-dependent
[15:11:02] <specing> ambro718: < ambro718> C 5.6K, C++ 5.7K
[15:11:06] <specing> *shrug*
[15:11:17] <vectory> -ffreestanding?
[15:11:26] <ambro718> specing: that's not a problem with the language, file a bug for gcc if it bothers you so much
[15:11:30] <specing> vectory: try it on AVR, really
[15:12:25] <specing> ambro718: there is no bug in gcc, it really is a problem with the language
[15:13:52] <ambro718> specing: I just did the same test with avr-g{cc,++} and the resulting .hex is 128B in both cases
[15:14:00] <specing> really?
[15:14:04] <ambro718> yes
[15:14:09] <specing> It was different the last time I tried...
[15:14:46] <ambro718> this is with avr-gcc 4.8.2
[15:14:47] <ambro718> .1
[15:15:16] <ambro718> it's also possible you forgot -fno-rtti -fno-exceptions but in my case it doesn't matter
[15:16:24] <vectory> still i read warnings for avr-g++, too often to consider it amywho
[15:16:28] <vectory> *anyhow
[15:18:00] <ambro718> avr-g++ if wonderful as long as you only use templates and no other c++ cruft like constructors and exceptions
[15:19:33] <vectory> so, you want structs and compiler visible macros, really :)
[15:19:52] <vectory> is that it?
[15:20:21] <ambro718> I also want it in a manner where half of the code isn't boilerplate ;)
[15:22:55] <ambro718> for example, I would find the addition of static_if very useful in C++
[15:23:22] <vectory> so, i need a new computer. in between pageloads i can go get a new coffee -_-
[15:23:33] <vectory> or at least some ram, i dont know
[15:24:26] <ambro718> similarly, a feature I'd call "class namespaces", so you won't have to write this: template<typename A, typename B> typename A<A,B>::ResultType A<A, B>::myFunction(int) {}
[15:24:42] <specing> vectory: reddit.com/r/buildapc
[15:29:47] <vectory> more like /r/financial
[15:30:05] <vectory> power vs cost :/
[15:31:15] <specing> sure, get an intel i5
[15:31:23] <specing> and use integrated graphics
[15:31:28] <specing> that is what Im doing
[15:32:04] <vectory> thats way passed my budget
[15:32:51] <vectory> nvm
[15:47:01] <RikusW> vectory: have a look at the Intel G2020 cpu
[15:47:14] <RikusW> mine runs at room temperature
[15:47:55] <vectory> will do, thx. was looking at amd apus. i.e. e350
[15:48:08] <RikusW> its half the price of i3 3220
[15:48:25] <megal0maniac> My ARMv5te doesn't even run at room temperature :/
[15:48:26] <RikusW> should be around 50-60Euro
[15:48:35] <vectory> e35m is 100$ for mobo with cpu and spu
[15:48:59] <RikusW> its running at 16C now
[15:49:09] <vectory> cool indeed
[15:49:14] <RikusW> very :)
[15:49:18] <RikusW> ark.intel.com
[15:49:26] <RikusW> search there
[15:49:49] <RikusW> I put it on a MSI Z77-G43 motherboard
[15:49:59] <RikusW> and put on 8GB of ram
[15:50:16] <RikusW> ram cost about the same as the CPU and its gaming ram too :-D
[15:50:34] <vectory> and suddenly its 200+ :<
[15:50:34] <RikusW> DDR3 1600
[15:50:44] <megal0maniac> Eh
[15:50:50] <megal0maniac> Mine is a 44C
[15:50:58] <RikusW> gaming ram was cheaper than normal apacer
[15:51:01] <megal0maniac> And it's a laptop CPu :)
[15:51:29] <RikusW> megal0maniac: whats your room temperature now ?
[15:51:33] <RikusW> 16C here
[15:52:42] <megal0maniac> I have no clue
[15:52:51] <megal0maniac> Probably around 18
[15:54:05] <RikusW> vectory:
http://www.comx-computers.co.za/BX80623G2020-Intel-Pentium-G2020-2-90GHz-Dual-Core-Buy-p-71904.php
[15:54:24] <RikusW> /13 == 50 Euro
[15:56:50] <megal0maniac> Hmmm... I can get those for R600
[15:57:06] <RikusW> Direct from the dealer ?
[15:57:18] <RikusW> mine was about R600
[15:57:24] <megal0maniac> Yip
[15:58:00] <megal0maniac> SSD is going back into the laptop when I get it back
[16:07:05] <specing> RAM is hellish expensive right now
[16:07:13] <specing> 90E for 16 GB :(
[16:07:24] <specing> thats how much I paid two months ago
[16:07:32] <specing> probably costs more now
[16:13:25] <RikusW> go type about:memory inside firefox address bar
[16:13:57] <megal0maniac> go type about:robots inside firefox address bar
[16:14:17] <RikusW> heh saw that :-P
[16:14:29] <RikusW> about:config
[16:19:25] <vectory> looks neat. but the next pain: choosing a mobo
[16:20:21] <vectory> e.g. the one i was looking at has a faulty pci chip, that requires a hackish workaround on linux :X
[16:20:57] <vectory> now, i dont need pci and it has 1x pci express, even.
[16:22:27] <vectory> and the apu has like 15 tpd ... but still, if your g2020 works at room temperature, it surely doesnt dissipate 55W
[16:32:45] <megal0maniac> vectory: I have a board I don't need. Pity you're so far :P
[16:36:05] <vectory> he :>
[17:13:53] <RikusW> vectory: 55W max
[17:14:30] <RikusW> when idle it underclocks to 1.6GHz
[17:15:32] <specing> wait till Haswell
[17:15:43] <specing> those can underclock to 800 MHz
[17:16:41] <RikusW> seems AVR is best, they can go to 0Hz :-P
[17:17:33] <vectory> with acmp, x86 can, too
[17:17:44] <vectory> *apmc(?)
[17:19:52] <vectory> *acpi m(
[17:21:11] <vectory> thought about waiting for haswell, yeah
[17:21:17] <vectory> but no pricetag, yet
[17:24:39] <specing> vectory: should be the same price
[17:24:51] <specing> celerons/pentiums are coming in Q4 2013
[17:25:04] <specing> i3,5,7 are already out
[17:25:20] <Casper> i3 is the celeron...
[17:25:32] <Casper> so under performing :(
[17:26:02] <specing> Casper: technically, i3 is pentium+hyperthreading
[17:26:12] <specing> and pentium is just celeron + couple 100 MHz
[17:26:26] <Casper> specing: and more cache
[17:26:31] <specing> and that
[17:26:37] <Casper> celeron is mainly cut cache
[17:26:48] <Casper> i3 is mainly i5 with less cache
[17:32:41] <twnqx> i3 is dual core + HT, i5 is quadcore
[17:32:59] <twnqx> that's imho the main difference, the cachesize is tied to core count
[18:07:51] <braincracker> h
[18:24:01] <Casper> twnqx: not all i3 are HT
[18:24:20] <twnqx> not? hm
[18:24:33] <twnqx> Linux golf 3.9.5-gentoo #2 SMP PREEMPT Thu Jun 13 01:26:09 CEST 2013 x86_64 Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz GenuineIntel GNU/Linux well.
[18:24:47] <twnqx> i won't buy a new comp before end of 2014
[18:25:58] <Casper> in fact, I think most I3 are not HT
[18:26:08] <twnqx> the only i3 i have i think is...
[18:26:20] <twnqx> i3-2100
[18:26:54] <damjan> depends. also some i5 are dual-core some are quad-core
[18:27:01] <Casper> my next one may be the 6 core i7
[18:27:07] <twnqx> aren't the dual core i5s all mobile?
[18:27:27] <twnqx> Casper: mine too... but only of the haswell kind :P
[18:27:48] <Casper> depending on the board price, I may get a double 6 cores :D
[18:28:03] <twnqx> cpus will be pretty expensive
[18:28:09] <Casper> yeah
[18:28:12] <damjan> according to
http://en.wikipedia.org/wiki/List_of_Intel_Core_i3_microprocessors all i3 have hperthreading
[18:28:17] <Casper> but currently those board are over 600$
[18:28:34] <twnqx> thenormal -ep do not support dual cpu, right? has to be xeon-dp?
[18:29:17] <Casper> no
[18:29:27] <Casper> not as I know of atleast
[18:29:47] <twnqx> i want the good old days back
[18:29:57] <twnqx> when intel wouldn't randomly cut out features
[18:30:10] <twnqx> and charge ridiculous amounts of money for turning them on
[18:30:21] <damjan> that's very old old days :)
[18:31:55] <twnqx> yeah... pIII was the last that would allow dual cpu without xeon
[18:31:58] <braincracker> will linux 4 be cool stuff?
[18:32:17] <twnqx> a) noone's even talking about it
[18:32:29] <twnqx> b) likely not, just a different number increased
[18:32:46] <braincracker> or there will never be 4.0 :)
[18:32:55] * twnqx didn't notice any relevant changes from 2 to 3
[18:32:57] <Casper> braincracker: what do you mean by linux 4.0?
[18:33:07] <Casper> linux is just a kernel
[18:33:20] <twnqx> yeah, i guess he was referring to kernel major.
[18:33:20] <braincracker> <twnqx> Linux golf 3.9.5-gento...
[18:33:29] <braincracker> you see it is close
[18:33:34] <twnqx> hm?
[18:33:54] <twnqx> nah
[18:33:54] <twnqx> next is 3.10
[18:33:54] <twnqx> 2.x went up into the far 30s
[18:34:05] <braincracker> hm ok
[18:34:28] <braincracker> so i guess 3.x will go up to 40 then
[18:34:37] <twnqx> who knows
[18:34:50] <twnqx> maybe 4.x for the 25th anniversary or so :P
[18:35:00] <braincracker> but that should be a clean thing
[18:35:40] * Casper wishes they had stayed with the old naming
[18:35:50] <twnqx> pentium 15?
[18:35:54] <braincracker> hm, i never know how to number my firmware
[18:35:55] <Casper> odd for developpement, even for release
[18:35:56] <braincracker> ...
[18:36:06] <twnqx> ah, linux versions
[18:36:10] <Casper> ya
[18:36:27] <twnqx> MaulUndKlauenSeu: vor allem klauen, bei den permanenten nickchanges :P
[18:36:39] <damjan> Casper: now it's better. a number for release. a rc? or -git for development
[18:37:08] * Casper wonders how ati will names their next generation of video card... radeon... radeon hd... radeon xhd?
[18:37:11] <braincracker> i think parallel branches cause problems
[18:37:31] <braincracker> there are numberless different solutions for the same problem
[18:37:39] <Casper> true
[18:38:00] <braincracker> radeon xd
[18:38:01] <braincracker> :)
[18:38:16] <braincracker> radeon msn
[18:39:21] <damjan> radeon one
[18:39:24] <braincracker> but i think nvidia will come up with an ad like "optimized for microsoft msn and skype" first
[18:40:04] <braincracker> everybody wants a video card that is optimized for skype
[18:41:01] <antto> then i must _not_ be part of "everybody"
[18:45:42] <braincracker> they sell the "DSC PC 4010H" alarm system with "ADDRESSABLE!" feature for 2x price ($300)
[18:47:10] <Casper> adressable features?
[18:49:31] <braincracker> no, only the feature addressable
[18:49:53] <braincracker> totally worth it for $150+
[18:50:50] <braincracker> what are you building?
[19:56:46] <ambro718> what would cause my AVR to restart, for no obvious reason?
[19:57:26] <Honeyclaw> its tired
[19:57:33] <Tom_itx> wdt
[19:57:52] <Tom_itx> some have the reset pin tied to an io pin
[19:57:53] <Roklobsta|2> bad stack or run out of stack
[19:57:56] <seldon> floating rst?
[19:58:19] <ambro718> I'm not doing anything with the wdt, a small seemingly irrelevant change in my program causes it
[19:59:14] <Tom_itx> seemingly :)
[19:59:21] <seldon> Is it a large program or can you paste the code somewhere?
[19:59:32] <ambro718> can't paste, it's huge
[19:59:39] <Roklobsta|2> i bet it's stack
[20:00:01] <ambro718> funny thing is it works fine when I enable debug/assertions
[20:00:24] <seldon> I'm betting 5 internet points on buffer overflow.
[20:01:34] <Roklobsta|2> stack overflow
[20:01:57] <Roklobsta|2> you have too many local vars/arrays being pushed on perhaps
[20:02:10] <seldon> Could be that, but if it doesn't happen in debug mode smashing the return address seems more likely.
[20:02:50] <seldon> stack frames don't usually get smaller in debug builds.
[20:03:18] <Roklobsta|2> well it may not hppen in debug. if thew stack is almost full then an irq now and then can push it over. it can be hard to cath
[20:03:21] <Roklobsta|2> catch
[20:04:50] <seldon> what is the seemingly irrelevant change, ambro718?
[20:05:16] <Roklobsta|2> i've been caught in random stack overflow hell in the past.
[20:05:43] <ambro718> indeed, it happens just before returning from a function
[20:05:53] <seldon> Haven't we all. There are a large number of UB hells.
[20:06:08] <seldon> \o/ I win!
[20:06:11] <Roklobsta|2> you may not realise it but you may end up 8 nested functions deep all with various local stack requrements then an IRQ pushes it over and the retturn address is clobbered and then it resets
[20:06:33] <Horologium> need more sram!
[20:06:43] <ambro718> seldon: the change is a larger value in a command which should cause the command to be split into multiple smaller commands; the function that is failing to return is the one doing this (rather complex) computation
[20:07:01] <Roklobsta|2> or worse it doesnt' reset but starts behaviing weird
[20:07:22] <ambro718> but the funny thing is that it crashes when first calling the function, *when it isn't doing the complex computation in the first place* (only the second invocation would do it)
[20:08:49] <ambro718> in other words, a single change of a value causes the crash, even though the program never reaches a point where this value would matter
[20:09:07] <ambro718> so how can I check if it's stack overflow?
[20:10:49] <Roklobsta|2> fille the stack with somethign liek 0xDEADBEEF and see if it all gets chnaged
[20:11:15] <ambro718> see? how do I do that?
[20:11:23] <ambro718> I don't have jtag or anything
[20:11:33] <Roklobsta|2> oh
[20:11:34] <Roklobsta|2> poo
[20:11:39] <seldon> simulavr?
[20:11:56] <seldon> Or the other, better one, wossname.
[20:12:28] <Roklobsta|2> i have to run... look at the map file and see how much space in bss you have in the region from the top of ram down to the end of the last statically allocated thing in ram.
[20:12:30] <seldon> https://gitorious.org/simavr
[20:12:40] <seldon> It exports a gdbserver interface.
[20:14:19] <ambro718> ok I'll try simavr, I don't have any special peripherals so it should be easy
[20:17:22] <Vutral> hm
[20:20:21] <ambro718> how do I compile simavr? It wants to use the native gcc to compile for avr...
[20:20:44] <ambro718> and if I say CC=avr-gcc to make, it will try to use avr-gcc to compile the native code too
[20:23:07] <seldon> Why would the simulator need to be compiled with avr-gcc?
[20:23:33] <ambro718> I don't know, ask the developer of simavr
[20:23:55] <ambro718> there are parts which need to be compiler for avr
[20:24:10] <seldon> In the "examples" directory, i see.
[20:24:13] <ambro718> but the developer seems to assume we have a single compiler which compiles both native and avr
[20:24:42] <seldon> Works for me. Anyway, make build-simulavr
[20:24:53] <seldon> make build-simavr
[20:24:54] <seldon> I mean
[20:24:56] <Tom_itx> maybe it uses the elf file to sim
[20:25:58] <ambro718> I get this
http://ideone.com/n9rWjf
[20:30:34] <seldon> Odd.
[20:36:18] <seldon> Check what /tmp/simavr_conf.log says
[20:36:45] <seldon> Oh, wait. You have to build with make V=1 for that.
[20:37:04] <seldon> So make clean; make V=1 build-simavr; , then check /tmp/simavr_conf.log
[20:37:22] <ambro718> ah, I just needed AVR_ROOT=/usr/avr
[20:39:40] <ambro718> meh it doesn't support atmega1284p which I'm using
[20:41:26] <ambro718> is does any of the supported MCUs have 16k SRAM?
[20:41:51] <seldon> The atmega1284p has jtag.
[20:42:13] <ambro718> but I don't have a jtag adapter
[20:43:46] <seldon> I suspect that problem can be solved by throwing money at it.
[20:46:17] <ambro718> how can I see how much ram my static variables consume?
[20:46:24] <ambro718> objdump or readelf ?
[20:47:56] <seldon> avr-size
[20:48:22] <ambro718> text data bss dec hex filename
[20:48:26] <ambro718> 28182 728 1080 29990 7526 test4.elf
[20:49:00] <ambro718> basically just 1K of RAM. Somehow I find it unlikely I could overflow the stack if it was 15K large
[20:49:13] <ambro718> or is there some artificial limit to stack size?
[20:49:32] <seldon> I don't think so. Do you malloc a lot?
[20:49:37] <ambro718> I never malloc
[20:49:45] <seldon> recursion?
[20:49:51] <ambro718> nope
[20:50:02] <seldon> Then I suspect a buffer overflow.
[20:51:37] <seldon> Unless you're playing with uninitialised function pointers or something else that's strange.
[20:54:10] <ambro718> here's the code
https://github.com/ambrop72/aprinter/blob/master/aprinter/driver/AxisController.h#L316
[20:54:18] <ambro718> it crashes when returning from send_stepper_command()
[20:54:50] * Horologium must learn to read.....saw that as "send_crapper_command()"
[20:54:57] <ambro718> ;)
[20:57:50] <andresjk> hi
[20:58:24] <andresjk> is there a way to reset all fuses configuration with a mkII?
[21:03:24] <Tom_itx> yes
[21:04:28] <Tom_itx> http://www.engbedded.com/fusecalc/
[21:24:30] <braincracker> so atmel mcus will reset on executing an invalid instruction?
[21:40:35] <ambro718> what's the semantic of printing pointers via printf("%p",...) ?
[21:40:46] <ambro718> I'm getting pointers way above 16k
[21:41:02] <ambro718> like 0xc523
[21:58:50] <ambro718> ok so I see that when I compile with debug stuff, the address of a non-stack variable is printed as 0xd123 instead of 0x76c
[21:59:57] <ambro718> * when I compile it without debug stuff
[22:00:32] <ambro718> for the good case avr-readelf indicates the same address (well really 0080074c but I can't verify the offsets within the structs)
[22:00:53] <ambro718> but for the broken case it indicates 008005d1 - but 0xd123 is way off here
[22:01:13] <ambro718> so the address as printed really is wrong right?
[22:01:43] <ambro718> what does 0xd123 even refer to?
[22:31:36] <timemage> ambro718, just out of curiosity, are you casting your pointer to (void *) in the call to printf ?
[22:32:27] <ambro718> nope
[22:32:44] <ambro718> but now I've changed something and the pointer is fine but the crash persists
[22:32:59] <ambro718> -Os removes the issue
[22:34:17] <timemage> ambro718, i haven't been following the whole thing.
[22:34:47] <ambro718> returning from a function causes the mcu to reset for no apparent reason
[22:34:55] <ambro718> and stack overflow seems very unlikely
[22:36:02] <ambro718> buffer overflow too, since I wrap the types used as indices into c++ templates which automatically make sure the values are always in range for the arrays
[22:37:47] <timemage> ambro718, if i could reproduce the problem here,i'd look into it.
[22:38:40] <timemage> ambro718, dunno that i've ever used printf on an avr. the only reason for the question about casting to void * is just that printf excepts the %p arg to be in that representation. it probably won't matter though.
[22:40:10] <ziph> ambro718: Corrupted return address loaded from the stack?
[22:42:54] <ambro718> timemage: check out
https://github.com/ambrop72/aprinter.git and run ./compile.sh, the result test4.hex will run on an atmega1284p
[22:43:10] <ambro718> or you can use MCU=atmega644p, that one compiles too
[22:43:25] <ambro718> the program prints to serial at baud 115200
[22:43:59] <ambro718> for example, I get this
http://ideone.com/eQUs0S
[22:44:23] <ambro718> when you see "Crashing now..." but no "Survived!" it means it reset
[22:45:26] <timemage> heh. i've forgotten how disorienting template error messages can be.
[22:45:55] <ambro718> you need new g++, I'm using 4.8.1
[22:46:39] <timemage> yeah. i'm on 4.7.0
[22:47:02] <ambro718> I can compile if for you if you tell me the mcu
[22:49:58] <timemage> ambro718, well, you could try for a 2560. i'd be running it on an arduino board. most of my avr projects use variants like the tiny85 or 2313.
[22:51:49] <timemage> ambro718, looking at the scope of things thing i'm just guessing it won't like running on a 2313 =)
[22:53:52] <ambro718> ok which pin can you use as a button
[22:56:32] <timemage> ambro718, PE5 i guess.
[23:05:18] <ambro718> timemage: do you have one on PORTA/B/C?
[23:05:30] <ambro718> portE doesn't have pin change interrupts on your mcu
[23:06:03] <ambro718> meh never mind, I'll just remove the need for a button
[23:06:19] <timemage> ambro718, i just discovered that i have a linux distro in a vm that has 4.8.0, going to give that a try.
[23:06:56] <ambro718> you'll still have to wait for me to fix the code for your mcu
[23:14:42] <ambro718> here's the compiled thing for 2560, pastelink.me/dl/9a30c8#sthash.dLuZxfvs.dpuf pastelink.me/dl/79de40#sthash.b45SZcCU.dpuf
[23:14:45] <ambro718> hex and elf
[23:15:37] <ambro718> it should start printing something to serial usart0 (115200), if not something's not right
[23:16:51] <ambro718> (I've disabled all outputs so something doesn't get fried)
[23:20:15] <timemage> ambro718, just burned it. getting things sorted here. also successfully built your original on the vm.
[23:22:31] <ambro718> ok I pushed these changes to git
[23:28:21] <timemage> Amadiro, PB7
[23:28:46] <timemage> err, ambro718
[23:29:05] <timemage> ambro718, heh, it's probably going to be more work to get me on board than it's worth.
[23:32:01] <ambro718> timemage: another hex,
http://pastelink.me/dl/9a30c8#sthash.XPHXd5Rq.dpuf
[23:32:10] <ambro718> if you could try this please,
[23:32:31] <ambro718> removed some unneeded code that could cause trouble, and added a toggle od PB7
[23:33:13] <ambro718> well meh no I messed up the toggle but still the serial should print
[23:33:54] <timemage> just burn it. i don't notice anything different.
[23:34:29] <ambro718> ok thanks anyway, I guess I'll have to play with avrsim then
[23:34:46] <timemage> ambro718, i think i'm on a 16mhz clock though.
[23:35:18] <ambro718> aah that's it
[23:35:47] <timemage> ambro718, yup. it is 16. i noticed you had 2 or so in the file, but didn't know what you were doing on your end to produce the newer hex files.
[23:36:24] <timemage> i could also be doing something stupid on top of that.
[23:36:41] <ambro718> timemage: here,
http://pastelink.me/dl/9a30c8#sthash.KRZWYicR.dpuf
[23:39:56] <timemage> ambro718, ugh. no difference. well, maybe i'll try tomorrow. the funny thing is, i have a 1284 somewhere, in dip even. i'd need to switch it over to internal osc to test. finding the necessary stuff and clearing space will take long enough that i'll be asleep by then.
[23:40:13] <ambro718> okay thanks :)
[23:54:18] <ambro718> timemage: ooops I'm pretty sure I've sent you the wrong files before which would not work. you can try the right one now if you wish
http://pastelink.me/dl/1ab19e#sthash.gzt9ZMkE.dpuf
[23:54:23] <ambro718> :(
[23:54:33] <timemage> heh. ok.
