Back
[00:00:27] <Casper> mystery solved I guess?
[00:01:30] <markm_> no
[00:01:44] <markm_> i dont think the xmega opcodes are encoded different
[00:24:37] <markm_> ok so i dont trust this disassembler and i need to disassemble this code, theres not enough example ASM code for me to figure out how to perform certain operations
[00:25:04] <markm_> what i really need is something like IDA pro for avr
[00:25:22] <markm_> i know ida supports avr but it does not support xmega
[00:25:35] <markm_> only the opcodes, not the devices
[00:32:41] <markm_> online disassembler seems to be utterly freeking useless.
[00:32:49] <markm_> first data you come to screws up the disassembly
[00:33:06] <markm_> and you cant seem to tell it "this is data (of some type)"
[00:44:23] <markm_> does avr putlish the source code for their XPLD boards?
[00:57:44] <markm_> this is freekig rediculous. they dont have any examples at all. they only have "Examples" showing you THEIR api. thats no good to me :/
[00:58:20] <markm_> doing some API calls to some closed source library doesnt tell me a damned thing about how to actually DO it
[01:02:12] <markm_> i need a resource giving examples of how to code the peripherals on an xmega, i dont care if the code is C or asm or whatever as long as the entire source is there not some "do this for me" api call
[01:44:39] <markm_> when a device has a 24 bit return address push for calls i assume its pushed low first mid then high byte?
[02:12:12] <markm_> err this is going to be a PITA. how do you specify a 24 bit address in c :/ lol
[02:15:32] <markm_> i REALLY dont want to be storing 32 bit addresses :/
[02:19:21] <mark4> does the avr HAVE a 24 bit data type already?
[02:22:35] <Xark> mark4: For program addresses (needed for >128KB flash chips).
[02:24:02] <mark4> xark how do i make use of that 24 bit data type
[02:24:39] <mark4> i need to do somerhing like .short blah or .int blah but short would truncate and int would waste 1/4 of my flash space
[02:25:15] <Xark> mark4: I believe the only opcodes that use it are EICALL and EIJMP.
[02:25:35] <mark4> nope. elpm espm too
[02:26:04] <Xark> Yeah, that makes sense.
[02:26:16] <mark4> im writing a forth. in forth every "Call" is simply a pointer to where to go
[02:26:30] <mark4> im not going to store these as .ints and waste 1/4 of my code space
[02:26:47] <mark4> i need a .short_24_bit this_address
[02:27:15] <mark4> and i cant do something like .byte foo >> 16 followed by .byte foo >> 8 & ff etc etc
[02:27:30] <mark4> because foo is not known till link time and the linker wont fixup those references
[02:29:08] <Xark> I am not sure about AVR linker restrictions, but GNU ld can certainly do fixup just like that on other platforms (common for RISC to have to separate fulll address into two opcodes).
[02:29:08] <mark4> in asm how would you create an array of 24 bit addreses is the question basically
[02:29:19] <mark4> using 32 bit addresses would be utterly unacceptable
[02:29:50] <mark4> xark ive had gcc fsck all over things where i do .byte (foo & 0xff) where foo is not known till link time
[02:30:02] <Xark> mark4: If they are absolute and the linker doesn't support 24 bit (or partial) fixup, then you sound like you have a problem.
[02:30:43] <mark4> they are absolute and im using gnu assembler in atmen studio 6.2
[02:30:44] <Xark> Yeah, that won't work, but if the assembler emits the proper fixup references it can work (as it does on other platforms). Probably not something that is open to you though, I suspect...
[02:31:31] <Xark> mark4: You can make them all 16-bit and then have a "jump table' for ones that are out range, perhaps?
[02:31:48] <Xark> (i.e., intermediate jmp)
[02:32:22] <mark4> xark no i cant
[02:32:47] <Xark> Yeah, would also require a bit of linker smarts...
[02:32:48] <mark4> because EVERY "Execution Token" or XT needs to be of a constant size
[02:33:13] <Xark> mark4: It would be, just not constant time for the jump (for ones that had to jump to a far jump)
[02:33:46] <mark4> xark no how would my virtual machine know when it had to look up an extended address?
[02:34:07] <Xark> The linker would know when a 16-bit fixup wasn't enough.
[02:34:19] <mark4> i could have an address compiled as 0x1234 and have to words. one at address 0x001234 and one at address 0x101234
[02:34:42] <mark4> that would not work for this
[02:35:06] <mark4> how can there NOT be a 24 bit data type? does the c compiler WASTE memory for addresses compiled into flash?
[02:35:12] <Xark> More like the linker sees a 16-bit "hole" and a 24-bit address to stick in it, so it puts a 16-bit address of a jmp to 24-bit address (and adds that code).
[02:35:14] <mark4> i mean. does it store addresses as 32 bits?
[02:35:39] <mark4> no. the linker will not be adding ANY code to my project
[02:35:50] <Xark> Fine.
[02:36:03] <mark4> the only object code added to my executable will be that which was generated from my sources. any injections would bugger up the entire thing
[02:36:45] <mark4> no external libs. no libc no libgcc no linker injecting anything... it would break my code
[02:36:58] <mark4> no optimizations either
[02:37:10] <mark4> tho im not sure there are any "optimizations" for the assembler
[02:37:52] <mark4> i really do not want to have to start over and make this subroutine threaded but if i cant write 24 bit addresses into 24 bits of space i dont think i have a choice
[02:37:53] <Xark> mark4: Ok, just checked and the 16-bit jump to a "trampoline" is the technique GCC uses (BTW).
[02:38:00] <mark4> sub threading will complicate things enormously
[02:38:54] <mark4> xark that would make my code CRAWL because the trampoline would be required to be referenced for every ijmp
[02:39:11] <Xark> mark4: No, only ones where destination > 128KB
[02:39:22] <mark4> forth high level code is basically an array of addresses. you have a pointer to the current position in that array and you fetch the next XT and eijmp to it
[02:39:23] <Xark> (at least that is how it is for GCC)
[02:39:44] <mark4> xark and i would have no way of determining at run time which ones those were
[02:39:59] <mark4> and the determination would absolutely have to be done at RUN time not compile time
[02:40:09] <Xark> mark4: You would if you had well defined entry points.
[02:40:30] <Xark> (but it does require "linker cooperation" and you have already ruled that out).
[02:41:03] <mark4> linker cooperation would be fine except where the linker injects b0rkage into my object code.
[02:41:18] <mark4> guess ill start over and make this subroutine threaded. i really did not want to do that
[02:41:53] <Xark> Hmm, the CALL instruction does write 3 bytes to the stack (and presumably RET pops and jumps to those three bytes). I wonder if you can use that...
[02:42:18] <mark4> yes. and i make use of that. call foo where foo pops the retun address off the stack. does something and MAYBE returns it to the stack
[02:42:22] <mark4> but not guaranteed to do so
[02:44:05] <mark4> wasted an entire 2 days writing this as direct threaded. will cost me a day to convert it to sub threaded :/
[02:44:12] <mark4> wanted this WORKING by monday lol
[02:44:21] <mark4> who needs sleep anyway lol
[02:45:11] <mark4> blargh im still going to be wasting some space because i need to .int addresses still
[02:45:31] <mark4> i hate wasting space in an embedded system
[02:46:02] <mark4> erm. lol what a dope. i dont CARE if i waste a little space with this version, even with direct threaded
[02:46:23] <mark4> lol. all i carea bout is... does it work!. ill make every XT 32 bits
[02:46:48] <mark4> eventaully ill be assembling and compiling this with my already written avr assembler and avr forth compiler
[02:47:10] <mark4> only readon im using AS6 is so i can do symbolic debugging of the object code.
[02:47:43] <Xark> Hmm, according to some AVR docs, if you .word some_pointer and some_pointer > 16-bits, the linker with automatically generate a jmp to the target address (and fixup to that jmp).
[02:48:06] <mark4> what if its .word q, w, e, r, t, y
[02:48:15] <Xark> I assume that doesn't matter
[02:48:23] <mark4> will it fixp all of those to 24 bits even if some of them would fit in 16 bits?
[02:48:31] <Xark> I would add 6 jmps if needed.
[02:48:45] <mark4> no jmp thats a .word not a jmp opcode
[02:49:00] <Xark> The linker doesn't know or care how many .words you used in the assembler (AFAIK).
[02:49:07] <Xark> [per line]
[02:49:18] <mark4> xark make it one .word per line. that wasnt the point
[02:49:34] <mark4> the point was, will the linker fixup all those .words to 24 bits even if some of them would fit in 16 bits
[02:49:36] <Xark> "In case of 24 bit "program memory type" addresses, you could simply use 16 bit addresses. The linker will generate jump stubs. The 16 bit address will then point to the jump instruction in the first 128k of the memory."
[02:49:42] <mark4> or will it "optimize" the ones it can
[02:49:55] <Xark> From someone with basically the exact same concern as you (and doesn't want to use 32-bit addresses)
[02:50:19] <mark4> FORGET jumps. all i care about is the addresses not how they will be used. some of these addresses will not be Jjumped to but EVER address has to be exactly the same size
[02:50:31] <mark4> uniform throughout the entire system. no special cases
[02:51:02] <mark4> if .word x can be either a 16 bit .word or a 24 bit .word depending on the mood of the linker or the current planetary alignment it doesnt help
[02:51:17] <Xark> If you do not know if you will be executing the code (but instead it may be data), then this won't work.
[02:51:48] <mark4> they are addresses. they may well be pointers to code or to data. whats important is taht all pointers are of equal size
[02:52:15] <mark4> .word should not care WHAT its compiling. just "what value" and "how much space"
[02:52:42] <mark4> i.e i can do .word 'q' and it should assemble to the same size as .word my_function
[02:52:45] <Xark> Yes, the pointers would always be equal size, but some would point to a "detour" jmp. I suspect this is not what you want (and will only work if you know you will jump to 16-bit address - vs load etc.)
[02:53:44] <mark4> no. that would not work at all. .word or .wordfoo need to assemble a "value" of a specific size. i need a .word24
[02:54:10] <mark4> ill just make everything a .int for now
[02:54:23] <mark4> when my forth avr assembler is assembling this i can restore sanity.
[02:54:29] <Xark> Okay.
[02:54:35] <mark4> ty tho
[02:55:10] <Xark> BTW, looks like GCC people are/were working on true 24-bit support ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50931
[02:55:24] <mark4> lol actually SOME pointers can be 16 bits but i always know when that is.. like when its a ptr into RAM :)
[02:56:01] <mark4> lol
[02:56:05] <Xark> The *pointer* is always 16-bit. The only thing is it may point to an "extra" jmp, you get that right?
[02:56:12] <mark4> wonder what the 24 bit data types will be :)
[02:56:31] <mark4> i understand it, i just know it wont work here
[02:56:51] <mark4> it........ would........ make my entier project cral even at its full 32mhz
[02:57:07] <Xark> Okay, just checking (you keep talking about different sized pointers -other than to RAM). :)
[02:57:45] <mark4> no ive said all along that every pointer has to be exactly the same size :)
[02:57:50] <mark4> and 16 bits wont do lol
[03:06:43] <mark4> erm ok so im a little confused about exactly how .int will write the bytes. as i only actually want 24 bits of the 32 i need to discard one... i THINK if i read x+, x+, x+, x+ its the first byte i discard yes?
[03:07:00] <mark4> so i read discard. high, mid, low yes?
[03:07:07] <Xark> mark4: I would imagine normal little endian
[03:07:34] <Xark> So, low med high discard
[03:08:21] <mark4> then why does PUSH store low then decremen sp then store hi ?
[03:09:10] <mark4> or maybe it was some screwed up asm code i got that from
[03:09:11] <mark4> erm
[03:09:27] <mark4> ya probably lol
[03:09:59] <Xark> Yeah. AFAIK, AVR acts little endian.
[03:10:29] <mark4> you know where big endian and little endian terms come from? :)
[03:10:43] <Xark> (sometimes it is arbitrary, but GCC/GAS tread pointers as little endian too, IME)
[03:10:48] <Xark> treat*
[03:10:53] <Xark> Of course. :)
[03:10:59] <mark4> i didnt till the other day lol
[03:11:05] <mark4> gullivers travels
[03:11:11] <mark4> which end of the EGG you start at :P
[03:11:13] <mark4> lol
[03:11:15] <Xark> Yep, perfect analogy. :)
[03:11:27] <mark4> tho it sounds stupid real wars have been started over less :/
[03:11:39] <Xark> Indeed.
[03:12:42] <Xark> mark4: If you haven't you should read the original IETF paper "ON HOLY WARS AND A PLEA FOR PEACE" ->
https://www.ietf.org/rfc/ien/ien137.txt (A great read and piece of computing history)
[03:13:00] <mark4> i probably have not read that. ill bookmark
[03:13:08] <mark4> i dont remember having read it lol
[03:13:52] <mark4> there is no correct endianness but afik only arm does it right... it can be either :P
[03:14:34] <mark4> x86 asm totally screwed me up when i started it in the 80's i had just come from 68k asm lol
[03:15:16] <Xark> Yeah. Endianness is a simple concept, but makes a confusing mess. :)
[03:15:23] <mark4> err i just thought of something
[03:15:36] <Xark> (along with alignment...)
[03:16:17] <mark4> if i set RAMPZ = 0 and then do a elpm from some addresses does the RAMPZ register get incremented if Z increments past 0?
[03:16:27] <mark4> to zero i mean
[03:16:39] <Xark> mark4: Good question. I would bet not...
[03:16:43] <mark4> if not then i consider that a MAJOR silicone bug
[03:17:19] <mark4> akin to the 6502 indirect jmp bug
[03:17:34] <Xark> Right
[03:17:45] <mark4> i assume your familiar with that bug :)
[03:18:53] <Xark> Sure, I have used it in copy protection schemes I have written for 8-bit games etc. (to throw off the unwary). It was fixed in 65C02 IIRC.
[03:19:09] <mark4> a jmp [01ff] would fetch the target address from 01ff (lo) and 0100 (hi)
[03:19:16] <mark4> instead of 0200
[03:19:52] <mark4> EA used it in some of their copy protection too
[03:20:02] <mark4> and if the copy protection failed they woulde X2 crash the core
[03:20:18] <Xark> It was pretty common, however, only tripped up the noob pirates. :)
[03:20:31] <mark4> i cracked a bunch of my own games. never published any cracks tho
[03:21:03] <mark4> and tbh i was VERY noob back then, i just knew every single 6502 opcode by heart and i mean i could pretty much read a DUMP of memory lol
[03:21:10] <mark4> 19 02 85 02 .. . ..
[03:21:17] <mark4> a9 not 19 i cant type
[03:21:43] <Xark> Yeah, I did a lot of work in Apple ][ monitor and knew most opcodes for patching.
[03:21:47] <mark4> i only remember 3 or 4 opcodes now
[03:21:53] <Xark> Same here.
[03:22:16] <Xark> I try to remember NOP on most architectures, that is the most useful. :)
[03:22:53] <mark4> EA and 90 and 00 for 6502, x86 and avr :P
[03:23:06] <mark4> erm i think 00 is for 8051 too but not sure
[03:23:07] <Xark> Indeed. :)
[03:23:30] <Xark> 00 is a good choice (works out to SLL R0,R0,#0 on MIPS, but same deal). :)
[03:23:33] <mark4> my fave one was always EA
[03:24:15] <mark4> 90 is actually not a "nop" perse till quite recently
[03:24:40] <Xark> Yeah, like OR ax,ax or something...
[03:25:10] <mark4> ya i ferget which it is tho. on modern cores it is actually a NOP
[03:25:26] <Xark> Yes, treated specially
[03:25:32] <mark4> yes.
[03:26:11] * Xark is shocked by how many NOPs are in AMD64 console code (to make loops aligned etc.). Plus if you add redundant prefixes, you can make N byte NOPs...
[03:26:20] <mark4> i like the little tricks x86 has like the formerlly undocumented immediate on the BCD opcodes :)
[03:26:40] <mark4> yea thats kinda funky
[03:27:05] <mark4> but aligning like that makes a HUGE difference im told
[03:27:11] <mark4> not only to object size :)
[03:27:53] <Xark> Yeah. I find it painful to see all the 10 byte opcodes and stuff on x64 (like add eax,0x0000000000000001)
[03:28:03] <Xark> Er, rax...
[03:28:36] <Xark> However, the fetch unit eats them up like crazy (so just bloat, not too slow)
[03:28:43] <mark4> im an embedded developer. im also diametriaclly opposed to ALL forms of compiler optimization.
[03:29:07] <Xark> mark4: Well, I am also an embedded (game) developer, but I want moar optimization. :)
[03:29:54] <mark4> if my isforth site registration were active i would direct you to my linux x86 forth compiler, written in 100% pure assembler, no external libs used... a true game coder like you would look at it and it would give you nightmares for a month lol
[03:30:24] <mark4> specifically because im doing things that would stall the CPU and be so highly inefficient that you could never use it in a real game lol
[03:30:34] <mark4> yet my compiler still compiles over 4 megabytes of source code per second
[03:30:37] <Xark> Heh, I doubt it. I wrote some pretty crazy big apps in 100% asm. :)
[03:31:04] <mark4> xark its not the size that would give you nightmares but my complete and utter disregard to the cache lines :)
[03:31:23] <mark4> data code data code data code... constantly having to reload cache lines.
[03:31:36] <mark4> and i mean 3 or 4 opcodes and thers a JUMP
[03:31:37] <Xark> Ahh, I see. Yeah, you "optimize" for different things on a game vs a compiler. :)
[03:31:54] <mark4> if you were to single step through it you would get lost in about 30 seconds
[03:32:24] <mark4> in fact it would take about half an hour of single stepping to get into it proper lol. and from then on it would be costant lodsd jmp eax lol
[03:32:35] * Xark is writing an "optimizing" assembler currently (although mostly so it can warn about "stupid shit" as opposed to re-write it for you - but it can if desired [or coping with silly compiler front-end]).
[03:33:11] <mark4> xark have you ever used Eric Isaacsons A86/D86? (A386/D386)
[03:33:37] <mark4> eric isaacson cowrote intels first assembler. a86 was his shareware assembler in the 80's
[03:33:40] <Xark> Maybe a long time ago... (but that is a kind of generic name for an assmebler...)
[03:33:56] <mark4> dos assembler. thers only one a86 dos assembler :)
[03:33:57] <Xark> Yeah, pretty sure I fiddled with it
[03:34:24] <Xark> (Mostly I used GNU tools when available - but 16-bit DOS they were not)
[03:34:28] <mark4> he had a rule. the assembler was to NEVER inject anything into your code other than that which you explicitly specified
[03:34:35] <mark4> no auto override injection etc
[03:34:59] <Xark> Well, that is an option for my assembler (error, warning or fix it up)
[03:35:09] <mark4> but for some god awefull reason he still published his opcode tables in HEX
[03:35:12] <mark4> shuder
[03:36:14] <mark4> blargh. testing a 24 bit value for == 0 takes 2 tests :P
[03:36:39] <mark4> or r1 r2 branch on not z, or r1, r3, branch on not z
[03:36:49] <Xark> The "fun" of an 8-bit architecture. :)
[03:37:23] <mark4> well even tho this 24 bit crap is a PITA its nowhere near as bad as on the PIC24
[03:37:34] <Xark> 1284 is the "biggest" AVR I like to use (with tons of SRAM and <128K flash). :)
[03:37:47] <Xark> Or <= :)
[03:37:52] <mark4> and PIC24's are super super inefficient executing their opcodes
[03:38:09] * Xark completely avoids PICs (well, perhaps a tad of PIC32 nee MIPS)
[03:38:44] <mark4> ya. ive had two jobs with pic24, after about 3k of object size the compiler starts to create broken code if you have ANY optimizations turned on
[03:39:29] <mark4> i think of the PICs in the say way i think of Mahwah New Jersey. if you ever get a chance to go to Mahway New Jersey.... pass it up
[03:39:34] <mark4> same way
[03:39:39] <Xark> Broken compilers are "the devil".
[03:39:49] <mark4> its their closed source HACK on gcc
[03:40:28] <Xark> Yeah, that is my I avoid Microchip. Questionably legal WRT GPL, and a total dick-move no matter.
[03:40:33] <Xark> why*
[03:40:58] <mark4> agreed
[03:41:17] <mark4> my typing skillz are starting to rub off on you :)
[03:41:25] <mark4> i can type 60 wrong words per minute
[03:41:44] <mark4> maybe only 50, im getting old
[03:43:00] <Xark> Hehe. I have "finger macros", and often my brain gets too far ahead of fingers (or vice versa). :)
[03:43:27] <mark4> you type like you have a chordal keyboard?
[03:43:28] <mark4> lol
[03:54:08] <mark4> sbi, sbci but no immediate add? i dont get it lol
[03:55:47] <Xark> mark4: Just add a negative number. :)
[03:56:16] <mark4> sub a neg u mean
[03:56:41] <Xark> Well, yes.
[03:57:27] <Xark> More common to omit subi (like MIPS or PowerPC), then you add negative. AVR is a bit odd with only subi (but all the same with twos-complement).
[03:58:58] <Xark> ARM is the "silly" one where you can add or subtract 0 (with two different opcodes). :)
[03:59:05] <mark4> lol
[03:59:30] <mark4> no. x86 can encode a mov ax, bx with the operands in EITHER order but it still performs the same operation at run time
[03:59:39] <Xark> It has a add/sub bit and the immediate value (not twos-complement).
[03:59:41] <mark4> thers a hidden D bit in many of the opcodes
[04:00:22] <mark4> d for direction
[04:00:38] <mark4> mov ax, bx with the D bit clear moves bx into ax. with it set it moves ax into bx
[04:01:10] <Xark> Yeah, x86 encodings are wacko.
[04:01:21] <mark4> only if you look at them in HEX
[04:01:41] <mark4> look at them in octal and suddenly you could easilly memorize the entire opcode field the way you did for 6502
[04:02:10] <Xark> x86 instruction set is like the layers of dirt in an archeology dig. :)
[04:03:17] <mark4> no actually, from the very first encoding to the modern instruction set they are extreeeeeeemly consistent with their encoding
[04:03:29] <mark4> arm on the other hand totally reinvents their entire map for every generation
[04:03:34] <Xark> Almost humorous how many attempts it took Intel to get SSE almost as usable as PowerPC (AVX stuff is finally decent).
[04:04:08] <mark4> i dont understand what practical use 99% of those opcods have lol
[04:04:31] <mark4> unless you are demultiplexing GR-CORE 253 data :)
[04:04:37] <Xark> Yeah, ARM is getting "storied" too. However thumb2 is decent. ARM 64-bit stuff looks promising too...
[04:04:38] <mark4> optical network shit
[04:05:02] <mark4> i just rewrote my ARM version of my forth compiler in thumb2. thumb2 is anything BUT decent
[04:05:08] <Xark> Handy for graphics and physics.
[04:05:23] <Xark> I like it vs ARM32
[04:05:32] <mark4> arm used to have fixed sized opcodes. now they can be mix-n-fucked-up 16 bit and 32 bit interleaved
[04:05:47] <Xark> Pretty much all the speed and smaller (it was faster on my code - probably due to cache effects).
[04:05:50] <mark4> the idea behind THUMB was that it was more space efficient than ARM.
[04:05:58] <mark4> i call "complete and utter BULLSHIT" on that
[04:06:22] <mark4> thummb2 is only very very marginally smaller than ARM. im using my 100% arm forth and the thumb2 port of it
[04:06:25] <mark4> as a reference
[04:06:38] <Xark> Thumb with limited registers sucked. Thumb2 has few drawbacks (it is just nice often you only need 16-bits for opcode).
[04:06:44] <mark4> and if they really wanted space efficiency they would have built a forth VM into their cores not java
[04:07:21] <mark4> for any non trivial application compiled forth will be about half the size of the equiv asm for ANY core and about 100 times smaller than the equiv c
[04:07:29] <Xark> Well, smaller & faster on my code. :) My assembler is smaller and faster with thumb2 (and g++-4.8).
[04:07:30] <mark4> and i can give you a real world PROOF positive of that
[04:07:45] <mark4> well tahts because you wrote it in c
[04:07:52] <Xark> Yeah, I want fast and small. :)
[04:07:57] <mark4> throw out your code, write it in arm asm then write it in thumb2 asm
[04:08:15] <mark4> it will go from "xxxxx" this big to "xxxx.5" that big and about that much faster
[04:08:28] <Xark> I see wasted condition bits on most ARM32 opcodes etc. :)
[04:08:47] <mark4> 4 bits lol
[04:08:51] <mark4> but ya
[04:09:00] <mark4> in embedded thats objectionable too
[04:09:06] <mark4> but arm is NOT an embedded processor
[04:09:11] <mark4> never was, never will be
[04:09:16] <Xark> I think thumb2 if-then-else opcode is rather clever (vs condition bits everywhere...)
[04:09:37] <mark4> unless you consider the raspberry pi (version 1) an embedded device. i dont. i consider it a full blown very poiwerful desktop computer
[04:09:41] <Xark> Heh, in your mind. The market has spoken. :)
[04:09:43] <mark4> i DO like that
[04:09:58] <mark4> PI2 is sweet tho !
[04:10:19] <mark4> ill be developing an xbee mesh network with BLE beacon tracking using a PI2 next week
[04:10:40] <mark4> i already wrote the xbee mesh network drivers for arduino. the arduino is HORRIBLE i hate it
[04:10:42] <Xark> Yeah, that is what I have been toying on recently (building my assembler etc.). RPi1 was just too slow, I find RPi2 usable for light duty work (and great for "always on" linux box).
[04:10:51] <mark4> i write 600 lines of C code and.... im out of ram
[04:11:12] <mark4> i brok my PI1 and bought a beagleboard XM
[04:11:18] <mark4> developed my forths on that
[04:11:25] <mark4> my arm forths that is
[04:11:36] <mark4> well except the android version lol
[04:11:59] <Xark> I like Arduino just because it is challenging (and keeps my optimization muscles intact after working with 8GB "embedded machines"). :) I can see it being total crap for networking though...
[04:12:41] <mark4> i used the wifi library and wrote my own xbee library because the published one does not support mesh networking
[04:12:59] <Xark> mark4: The kind of stuff I do with Arduino is ->
https://www.youtube.com/watch?v=Imk5ony8JHI
[04:13:05] <mark4> 3 days to write 600 lines of code and when i ran it the entire mesh network WORKED first time.
[04:13:48] <mark4> that your code doing that?
[04:14:07] <mark4> demo coders == game coders == wtf over? lol
[04:14:32] <Xark> Yeah, that is bit-banging NTSC (with 3 voice wavetable audio).
[04:14:36] <mark4> is that doing software blitting?
[04:14:55] <mark4> heh thats more impressive than the avr tiny bit banged USB CDC :)
[04:15:01] <Xark> Yes, just an Arduino and two resistor video (and one resistor + capacitor audio).
[04:15:43] <Xark> mark4: It is a game library I am working on:
https://imgur.com/IgsmEY3 https://imgur.com/gNyTb6u
[04:15:53] <Xark> (also supports horizontal and vertical smooth scrolling)
[04:16:15] <mark4> i was thinking of doing a remake of space invaders but with YOU as the invaders :)
[04:16:20] <mark4> didnt quite work out the details...
[04:16:30] <Xark> Hehe, Earth Invaders. :)
[04:16:31] <mark4> dodge them bullets, catch the refuel from the mothershit
[04:16:35] <mark4> lol yes!
[04:16:45] <mark4> mothershiP even
[04:17:10] <mark4> i heard the guy that wrote that sold it for next to nothing
[04:17:20] <mark4> wonder if he is still kicking himself over that one
[04:17:45] <mark4> if you steal my idea i wont be pissed, i probably wont ever do it lol
[04:18:15] <Xark> Hehe, no worries. :)
[04:18:22] <mark4> and as the earth invaders do you control the entire mass of dropping ships?
[04:19:01] <shiinko> Is there a need to include a resistor between button (connected to ground) and an input pin with pull-up ?
[04:19:12] <mark4> oh. you have to bomb all the blocks out of the way and the enemy... if a blockis in the way and one of your guys hits it he blows up and takes out neighbors with him
[04:19:20] <Xark> shiinko: Not really.
[04:19:43] <mark4> if you can bomb all the blocks out of the way and kill the enemy you get to land and have completed that level :)
[04:19:54] <Xark> shiinko: Assuming you use active LOW logic and the internat AVR pullup resistor.
[04:20:03] <Xark> internal*
[04:20:08] <mark4> you dont control the movement of the ships but maybe the bombing :)
[04:20:26] <shiinko> Xark: Yeah, I do. Thanks ;)
[04:21:03] <Xark> shiinko: If you were in a "harsh environment" an external resistor might be needed, but for the most part the internal pullup works great.
[04:21:42] <Xark> (because external can be lower resistance - pull harder)
[04:23:08] <shiinko> Yeah
[04:23:12] <shiinko> Okay. One more question. A button wasn't working when I was using a 5V voltage regulator without capacitor between output pin and GND. But when I added one it started working.
[04:23:30] <shiinko> Is there anything I can read about the importance of capacitor here?
[04:24:12] <Xark> shiinko: So presumably "noisy" power caused problems. Digital requires fairly smooth power (and decoupling caps that can provide "quick" energy fast).
[04:24:59] <shiinko> Xark: Power was provided by a LiPo battery, so it should be smooth?
[04:25:40] <Xark> shiinko: That is interesting, but it still may not be able to react fast enough to current changes so requires cap as a "reservoir" of energy.
[04:26:06] <Xark> What size capacitor?
[04:26:15] <shiinko> I added 10uF
[04:26:41] <shiinko> Another interesting thing is that it worked fine without capacitor when used with a 9V battery
[04:27:03] <Xark> Yeah, that does seem somewhat unexpected to me...if you had a scope you can probably see what si going on.
[04:27:50] <shiinko> Don't have one though. But thanks for your help ;)
[04:28:01] * Xark is pretty sure he has run AVRs from LiPo without 10uf filtering cap...
[04:28:31] <Xark> Hmm, no, my regulator board has one.
[04:29:24] <Xark> shiinko: The regulator may require a cap to operator correctly (it seems I always see two in many schematics).
[04:29:55] <Xark> Like
http://www.learningaboutelectronics.com/images/LM7805Circuit5.jpg
[04:30:53] <Xark> or
http://www.rakeshmondal.info/pik/IC-7805-voltage-regulator-rakesh-mondal.jpg
[04:31:02] <Xark> Etc.
[04:31:06] <shiinko> This circuit and many others I've seen have 0.1uF on the output
[04:31:13] <shiinko> Is 10uF I put on an overkill ?
[04:31:20] <Xark> I think the values are "negotiable". :)
[04:31:54] <shiinko> Well I already soldered it on and it works so there's really no reason to change it
[04:31:57] <shiinko> :P
[04:32:02] <Xark> shiinko: If you really want to know, read the regulator datasheet (or just copy values from a design you trust).
[04:32:19] <Xark> Yeah, working is working. :)
[04:33:19] <Xark> shiinko: E.g., the 2nd link has two caps on output (to take care of large and small ripples).
[04:33:31] <Xark> (and one is 10uf)
[04:33:37] <mark4> erm add r0, r6 followed by sbci r1, 0 ? would that add with carry ?
[04:33:47] <mark4> this is confuzing me lol
[04:34:10] <mark4> how do you do subtract -0 lol
[04:34:26] <shiinko> Xark: Yep, saw that.
[04:34:49] <mark4> that wont work. the sbc would subract nothng or subtact 1, the desired result is add nothing or add 1.
[04:34:59] <mark4> arm's +/- zero resolves this
[04:36:24] <Xark> mark4: I agree it is confusing, but I think you have everything you need to do it right on AVR.
[04:36:54] <Xark> mark4: I usually make a one-liner in C and then see what opcodes it generates when I don't want to think too hard. :)
[04:36:56] <mark4> xark how do you ADD an 8 bit immediate to a 16 bit number
[04:37:13] <Xark> You subtract a negative number. :)
[04:37:14] <mark4> in C it would extend the 8 bits to 16 bits
[04:37:49] <mark4> no. add first 8 bits, have carry or not. then add immediate 0 does not exist so subtract immediate NEG 0 also does not exist
[04:37:56] <mark4> the only way to do this is with NON immediates
[04:38:02] <mark4> and have a zero register
[04:38:23] <Xark> Oh, yeah, AVR tends to always have R1 == 0
[04:38:42] <mark4> a waste of a register
[04:38:48] <mark4> :)
[04:39:22] <mark4> and why r1 i would think "r0 = 0" scans better mentally lol
[04:39:24] <Xark> Pick your poison. If you use it enough, it is cheaper than having to zero one all the itme...
[04:39:41] <Xark> (and AVR is fairly register rich)
[04:40:07] <mark4> not really considering they are 8 bit
[04:42:32] <Xark> Hmm, GCC chooses to use "03 96 adiw r24, 0x03" :)
[04:42:44] <Xark> (for 16-bit += 3)
[04:43:22] <Xark> However, IIRC addiw takes < 8 bit immediate...(0-63?)
[04:43:29] <mark4> well thats great for values from 1 to 63 :P
[04:43:53] <mark4> 7 bit?
[04:44:20] <mark4> its 4 freeking 30 am here lol i got church to go to blargh
[04:44:25] <Xark> "ADIW Rd+1:Rd,K d ∈ {24,26,28,30}, 0 ≤ K ≤ 63 PC ← PC + 1"
[04:44:26] <mark4> im going to be a zombie
[04:44:39] <mark4> yes.
[04:44:47] <Xark> Ahh, only works on a few regs apparently...
[04:45:06] <Xark> (and only 0-63 too)
[04:45:11] <mark4> yes adiw is limited
[04:45:40] <mark4> so have gcc add an 8 bit 64 to a 16 bit variable
[04:45:47] <mark4> i bet it 0 extends the 8 to 16 first :P
[04:46:06] <Xark> Yeah, probably uses zero reg...lets see.
[04:46:45] <Xark> Hmm, no, this is not too bad...
[04:46:50] <Xark> v += 65;
[04:46:51] <Xark> 98: 8f 5b subi r24, 0xBF ; 191
[04:46:53] <Xark> 9a: 9f 4f sbci r25, 0xFF ; 255
[04:47:07] <mark4> ooh of course
[04:47:08] <mark4> duh!
[04:47:19] <mark4> make the entire thing subi lol
[04:47:20] <mark4> erm
[04:47:47] <mark4> why didnt i actually THINK of that lol
[04:47:51] <mark4> too freeking tired lol
[04:48:18] <Xark> Well, it is what I suggested "You subtract a negative number." :)
[04:48:45] <Xark> No worries. Late here too (and this stuff is always a tad confusing).
[04:48:47] <mark4> i was only thinking of negating the high part but that fails because avr does not have negative zero :)
[04:49:14] <mark4> try compiling a create does> mechanism in forth :P
[04:49:42] <Xark> Only if you translate to C. :)
[04:49:56] <mark4> : constant create , does> @ ;
[04:49:58] <Xark> if (v < 65) { ... }
[04:50:00] <mark4> 0 constant foo
[04:51:00] <mark4> creates a new word called foo. when you execute foo its entry point is a CALL to some machine code within the above word that created it... the word does> patched it to call this address... does> then layd down that machine code where IT is in the definition
[04:51:18] <mark4> that machine code is a call to dodoes. so word calls the machine code leaving a return address on the stack
[04:51:32] <Xark> You have Atmel Studio, so can do a test with a few clicks (then look at lss file in Output Files). :)
[04:51:38] <mark4> the machine code called dodoes leaving a return address on the stack
[04:51:44] <Xark> I am going to crash now. :)
[04:52:10] * Xark waves TTYL
[04:52:15] <mark4> forth pushes its imterprative pointer to the return stack and pops one of the return addresses.
[04:52:28] <mark4> the FETCH then fetches the contents of the first return address
[04:52:32] <mark4> no returns happen
[04:52:38] <mark4> two calls, no returns :P
[09:42:00] <antto> say i have a timer set up with an interrupt, if i disable and enable interrupts for a few clock cycles - would that stop the actual counter from incrementing?
[09:42:47] <Lambda_Aurigae> nope
[09:44:00] <Lambda_Aurigae> global interrupt enable/disable does just that.
[09:44:10] <Lambda_Aurigae> timer counting is a separate on/off
[09:44:15] <antto> ahum
[09:45:00] <antto> so, what happens if i disable interrupts right before the counter should reach its wrap-around point and then re-enable interrupts afterwards?
[09:45:20] <antto> i know i'll miss that interrupt
[09:45:36] <antto> but will the counter wrap around at the right spot still?
[09:46:13] <Lambda_Aurigae> the counter will keep counting and doing its thing.
[09:46:27] <Lambda_Aurigae> if your interrupt routine does anything to change the counter then that change won't happen.
[09:46:28] <antto> so the timer period will remain solid?
[09:46:42] <Lambda_Aurigae> yes.
[09:46:46] <antto> nice
[09:47:03] <antto> in my case, i'm keeping the timer at a fixed period the whole time
[09:48:22] <Lambda_Aurigae> remember that interrupts don't trigger when global interrupts are off so you will lose that interrupt generated by the timer.
[09:48:55] <Lambda_Aurigae> interrupt, or interrupts,,depending on how long you have global interrupts disabled and how fast your timer is overflowing or whatever it is you have it doing to generate an interrupt.
[10:09:29] <martinus> Hello everyone
[10:09:44] <DO9XE> hallo :)
[10:10:03] <DO9XE> if your german, just speak german ;)
[10:10:29] <martinus> Does anyone have the patience to deal with a few newbie questions that google has not been able to answer (to my satisfaction)?
[10:11:28] <martinus> Or perhaps, in a fashion I can understand. :D
[10:14:36] <DO9XE> well, just write the questions :)
[10:14:51] <DO9XE> if the LTE in the bus is good, ill even anwear :D
[10:15:05] <DO9XE> and the LTE ist good ;)
[10:15:20] <martinus> I'm coming from an arduino background, I have been reading through AVR C tutorials and started to haunt the avrfreaks forums but I've not been able to ascertain if I *must* start programming in pure C or if C++ is widely used now. All of the books that are recommended are C which is suggestive but I see C++ code snippets posted all over the place...
[10:20:42] <DO9XE> well, c++ and c are quit similar. I code in simple C, because most librarys i use are C. In my oppinion C++ is object orientated and for GUIs and C ist for real working code ;) I know that there are some options for the compiler to recognize that you use C and C++ code, but i never had to deal with it :D
[10:22:55] <Lambda_Aurigae> being a long time avr hobby player, I use C almost exclusively. Can see no benefit to using C++ myself. It is, however, mostly supported.
[10:23:11] <Lambda_Aurigae> maybe even fully supported now.
[10:24:04] <Lambda_Aurigae> there have been many dis-cuss-ions around here over C vs C++ and whether there is excess overhead in one or the other but I think they come out about even in that respect.
[10:25:12] <Lambda_Aurigae> C++ gives you classes that allow you to lock down access to internals and such and templates which I have no clue what benefit those have....other than that, meh.
[10:25:18] <Lambda_Aurigae> pick the one that works for you.
[10:32:48] <martinus> Many thanks, that makes a lot of sense. I noticed someone refer to using structs as an alternative to classes. I'm assuming they were referring to being able to collect associated variables. Does this make any sense?
[10:35:57] <Lambda_Aurigae> yes
[10:36:00] <Lambda_Aurigae> we did that before C++
[10:36:17] <Lambda_Aurigae> using a struct to hold pointers to functions and variables.
[10:36:43] <Lambda_Aurigae> it doesn't give the isolation that classes can give but otherwise the same basic functionality of gathering functions and data in one variable.
[10:36:50] <proteusguy> martinus, you can always use C++ as a "better C" and take advantage of better type safety and such. If you understand how C++ features are implemented you will never pay more to use C++ than what it would have taken to accomplish the exact equivilance in C - and often you'll pay less.
[10:37:19] <Lambda_Aurigae> proteusguy, yes...all depends on how well you know C++ I imagine.
[10:38:16] <martinus> My knowledge of OO is primarily from python and I guess I have smatterings from intro C++ tutorials so consider me entirely new to the topic for all intents and purposes.
[10:38:28] <proteusguy> Lambda_Aurigae, yes - the basic rules are don't use virtual methods or exceptions and nothing will surprise you. If you need virtual methods or exceptions, generally the C-equivalent will actually be more expensive.
[10:38:59] <Lambda_Aurigae> can't say as I've ever needed either in C.
[10:39:12] <proteusguy> martinus, actually C++ is not an OO language. It is a multi-paradigm language, one of which happens to be class-based object oriented.
[10:39:18] <Lambda_Aurigae> and only used exceptions a couple of times in C++...although I don't do much C++.
[10:39:25] <proteusguy> Lambda_Aurigae, in small embedded projects it's unlikely you ever would.
[10:39:31] <Lambda_Aurigae> too true.
[10:39:40] <martinus> Sorry, I should have clarified my knowledge of C++ classes, thanks for reminding me.
[10:40:12] <martinus> Or the intent behind classes, I should say.
[10:40:18] <Lambda_Aurigae> I've done quite a few larger C applications for the PC in the past too so I do know how unwieldy it can get if done wrong.
[10:40:30] <proteusguy> C, properly used, is simply a portable assembly language. Once you get into any kind of higher level constructs then you will find C++ to be superior. That's why C is still the language of choice for an OS kernel.
[10:41:08] <Lambda_Aurigae> FORTRAN was always fun too but that's a whole different world.
[10:41:47] * proteusguy has no recolection of FORTRAN ever being "fun". :-)
[10:41:53] <Lambda_Aurigae> hehe.
[10:42:10] <Lambda_Aurigae> we used it to write orbital mechanics systems for satellite tracking..
[10:42:45] <Lambda_Aurigae> at the time, late 80s, FORTRAN's math functions were superior to C or Ada.
[10:43:01] <Lambda_Aurigae> late 80s/early 90s.
[10:43:39] <proteusguy> Lambda_Aurigae, indeed, a lot of the more popular math libraries are STILL in fortran. But fortunately the SciPy team has wrapped them in python so you can get their speed and correctness without ever seeing a line of fortran code.
[10:44:09] <Lambda_Aurigae> we wrapped fortran stuff in C a lot of times.
[10:44:22] <Lambda_Aurigae> this was back when we were running Sun System V release III unix.
[10:44:32] <Lambda_Aurigae> on sun 3/260 workstations!
[10:44:48] <Lambda_Aurigae> WITH optical mice!
[10:44:54] <Lambda_Aurigae> in the 80s and 90s.
[10:45:20] <Lambda_Aurigae> mouse ran on a checker board patterend metal mousepad and nowhere else.
[10:45:45] <Lambda_Aurigae> glub but I miss those mice...accurate and never skipped a beat.
[10:46:44] <Lambda_Aurigae> and we had 20 inch high resolution CRT monitors too...that were half again the original size due to the EM shielding on them for security purposes.
[10:47:19] <proteusguy> haha yet you could redirect your X output (and audio) to any other sun box on the network with fun results... :P
[10:47:43] <Lambda_Aurigae> team leader for the NDS system from Sandia National Labs gave me my first K&R C book then too.
[10:47:53] <Lambda_Aurigae> oh, yeah....remote X was awesome.
[10:48:08] <Lambda_Aurigae> running remote apps on people's desktops was fun too.
[10:48:24] <martinus> proteusguy: You have no idea how thankful I am for that, it helped me get a PhD. :D
[10:48:41] <Lambda_Aurigae> we had no audio on our sun systems though.
[10:48:56] <proteusguy> martinus, being able to send your X output to another workstation even without permission?
[10:49:12] <Lambda_Aurigae> doing satellite C&C, we didn't need audio.
[10:49:29] <martinus> python, scipy , numpy and matplotlib is a phenomenally useful set of tools.
[10:49:48] <proteusguy> martinus, ah indeed they are quite amazing. We use it all the time.
[10:50:09] <proteusguy> martinus, what's your PhD in and what was your thesis?
[10:50:20] <Lambda_Aurigae> I wrote a tool that we could run from any of the 6 workstations in the vault that would lock all 6 screens with a big red screen with SECRET in the middle..and would require a password on any of them to unlock them all.
[10:50:23] <martinus> I haven't had to worry about trying to afford a matlab licence in years.
[10:50:40] <Lambda_Aurigae> we often had visitors who weren't allowed to see what was on the computers...a quick click and all screens locked.
[10:50:59] <proteusguy> Lambda_Aurigae, hahaha that's true... fun times.
[10:50:59] <martinus> The Biomechanics of Knees of Total Knee Replacement Golfers".
[10:51:16] <Lambda_Aurigae> haha.
[10:51:27] <proteusguy> martinus, cool - real cyborg stuff!
[10:51:38] <Lambda_Aurigae> I did some of that in the past too martinus....only from the messy side of the world.
[10:51:52] <martinus> Motion capture plus inverse dynamics.
[10:51:58] <Lambda_Aurigae> I was a surgical scrub tech for a couple of years and worked in a hospital that did a lot of joint replacement surgery.
[10:52:04] <martinus> Awesome
[10:52:14] <Lambda_Aurigae> that was back in the mid 90s.
[10:52:22] <martinus> You appear to have a diverse carreer. :D
[10:52:27] <Lambda_Aurigae> very much so.
[10:52:41] <Lambda_Aurigae> not much I can't do if I put my mind to it.
[10:52:50] <Lambda_Aurigae> just don't have the wallpaper to prove it.
[10:53:09] <Lambda_Aurigae> as I don't do well in school.
[10:53:15] <Lambda_Aurigae> well, did in highschool
[10:53:37] <Lambda_Aurigae> but after that and USAF tech school, I kinda lost the whole classroom ability thing.
[10:54:32] <martinus> Golf happens to be the most widely adopted sport post surgery (we don't count walking as a sport). It also happens to have what I considered to be a worryingly high rate and magnitude of loading on the knees. Surgeons have been recommending it for years.
[10:54:33] <Lambda_Aurigae> so now I fix copiers and help re-engineer them on occasion and teach a few kids who are interested in learning basic electronics and microcontrollers and programming.
[10:54:56] <Lambda_Aurigae> yeah...golf has lots of walking and twisting.
[10:55:44] <martinus> Turns out that the loading is higher than jogging but it's so brief and infrequent that the golfer gets far more benefit out of "the long walk" than potential risk from hitting the ball.
[10:57:44] <martinus> Excellent. My 'classes' are limited to teaching basic astrophotography and programming in Scratch. :)
[11:01:38] <Lambda_Aurigae> I teach kids from local 4H and scouting groups.
[11:01:52] <Lambda_Aurigae> need to go over soon and clean up the work area in fact.
[11:02:02] <Lambda_Aurigae> it has been used for random storage over the winter.
[11:04:25] <Lambda_Aurigae> this summer I think our ultimate project is going to be hunter seeker robots...little bots that search for "food".
[11:04:51] <Lambda_Aurigae> the food being rechargeable battery packs they can latch onto and use to charge their own internal batteries.
[11:05:06] <Lambda_Aurigae> and, hopefully, to include a bit of battle bot in it for added fun..
[11:06:03] <Lambda_Aurigae> maxwell is sending me 10 ultracapacitors to play with.
[11:06:14] <martinus> Awesome. I've got an old Tamiya RC car here I'd love to turn into a collaborative rover testbed but I find I've never enough hours in the day. :D
[11:07:07] <Lambda_Aurigae> I've collected a bunch of vex robotics gear over the years...have enough to build at least 5 little 2-wheel differential drive rovers with drag wheels.
[11:10:15] <martinus> I'm guessing your bots are all ground-based? A friend from my local maker group had the rather lofty idea of creating a "hide and seek multirotor". I liked the idea (and have since built a multirotor) but I think we have a long way to go to integrate a set of sensors.
[11:12:05] <martinus> I can't believe how cheap all the parts are now, I'm in my mid-thirties and have memories of wanting to build an RC plane as a kid. Back then a decent transmitter would have started at nearly £200 (GBP)
[11:12:59] <Lambda_Aurigae> yeah..flying stuff gets expensive.
[11:13:18] <martinus> I picked up a programmable, AVR-based nine-channel transmitter (Turnigy 9X) for less than £40! The postage from China was a bit of a stinger but wow, I am amazed at how low-cost everything is now.
[11:13:19] <Lambda_Aurigae> I did model aircraft as a kid and into my 20s.
[11:13:42] <martinus> I built my entire tricopter and have lots of spare parts for < £160
[11:13:55] <Lambda_Aurigae> when I am collecting parts for 3 to 8 kids it gets much more expensive than if I were doing it for myself.
[11:14:17] <Lambda_Aurigae> the robotics stuff is all reusable from year to year...like erector set on steroids.
[11:14:26] <Lambda_Aurigae> the electronics is mostly free sample stuff.
[11:14:42] <Lambda_Aurigae> and I do this all free of charge,,just for the fun of it.
[11:15:44] <martinus> I built balsa free-flight models as they were very inexpensive but I'm utterly amazed at the powered models one can now construct from inexpensive foam-board.
[11:16:27] <martinus> £60 of electronics (assuming one already has a transmitter) and you have an RC plane.
[11:18:34] <Lambda_Aurigae> yup.
[11:18:55] <Lambda_Aurigae> I also scavenge a lot of electronics, motors, gears, and stuff out of the copier bone pile at work.
[11:19:03] <Lambda_Aurigae> so, really, I have to buy very little.
[11:19:27] <Lambda_Aurigae> I still would prefer to build balsa models if I got back into model aircraft.
[11:19:46] <Lambda_Aurigae> did the foam core planes for a while and they just didn't have the character that balsa models did.
[11:20:01] <Lambda_Aurigae> you don't have the pride in saying, I cut and glued every piece of this machine.
[11:20:38] <Lambda_Aurigae> any idiot can put together a foam core ARF(Almost Ready to Fly) model and fly it.
[11:20:47] <Lambda_Aurigae> and if they crash it they just shrug it off.
[11:21:43] <Lambda_Aurigae> if you spent 50 to 100 hours actually cutting and fitting and gluing the pieces together you take more pride in your plane, learn to fly it better(usually), and appreciate it more.
[11:22:31] <Tom_itx> 51`
[11:22:33] <Lambda_Aurigae> I look at the whole arduino vs bare AVR from scratch thing the same way really.
[11:25:41] <martinus> I love balsa building but it's heartbreaking when they crash. Foam is just so easy to repair and takes all of the anxiety out of flying.
[11:25:57] <Lambda_Aurigae> that's why you learn to fly better!
[11:25:58] <Lambda_Aurigae> hehe
[11:26:01] <martinus> :D
[11:26:28] <Lambda_Aurigae> I remember the guys doing bombing runs with flour bombs back in the day.
[11:26:48] <Lambda_Aurigae> take off, circle, dive bomb the target, come back for another bomb..
[11:27:07] <Lambda_Aurigae> one guy thought it would be cute to put water in his bomb rather than flour.
[11:27:19] <Lambda_Aurigae> he got off the ground but couldn't get altitude fast enough.
[11:27:41] <Lambda_Aurigae> and shredded the plane through a 3 foot high chain link fence at the end of the field.
[11:28:39] <Lambda_Aurigae> was a nice scale model realistic type bomber too...he had a lot of time in it.
[11:28:49] <Lambda_Aurigae> he shed a couple of tears over it.
[11:29:47] <Lambda_Aurigae> mmmm....brunch...homemade corned beef hash from corned beef and potatoes I cooked in the crock pot yesterday.
[11:35:55] <martinus> Ouch, I'm nowhere nearly skilled enough to want to fly a scale model. I think I'll spend a few more years on low time and money-investment foamies. :)
[11:36:43] <Lambda_Aurigae> hehe.
[11:36:54] <Lambda_Aurigae> I learned on balsa models..we didn't have foamies back then.
[11:37:32] <Lambda_Aurigae> started with rubber band powered free flight then went on to fixed throttle .049 engine powered then moved up to the bigger monsters.
[11:38:31] <Lambda_Aurigae> my last one was a super telmaster with a 4 stroke engine
[11:40:01] <martinus> I still have my collection of peanut-scale balsa free-flight models. I do get nostagic pinings for them every once in a while.
[11:41:58] <martinus> Sorry, a collection of plans, not a collection of models.
[11:42:51] <Lambda_Aurigae> one of my clients is Sig Manufacturing..they make model aircraft kits.
[11:43:19] <martinus> Scandanavian company isn't it?
[11:43:49] <Lambda_Aurigae> dunno bout that...looks like a small local company here.
[11:43:57] <Lambda_Aurigae> don't know if they have big brothers elsewhere or not.
[11:44:40] <Lambda_Aurigae> http://www.sigmfg.com/
[11:45:19] <Lambda_Aurigae> looks like they are all local here to Montezuma, IA, USA.
[11:45:30] <Lambda_Aurigae> except for their webmaster who is in new zealand.
[11:46:00] <martinus> Oh! Haha, I remember where I saw that: SIG is a branch of the Swedish armed forces.
[11:46:26] <martinus> Definately got my wires crossed there. :)
[11:46:31] <hypermagic> hello my friends
[11:46:38] <hypermagic> what are you creating?
[11:46:46] <Lambda_Aurigae> nothing at the moment.
[11:46:59] <martinus> Ah, those are lovely looking sport fliers.
[11:47:43] <Lambda_Aurigae> figure we will build model aircraft and arm them with .22 semi-automatic guns and create some artificial intelligence units to fly them....let them take over the world.
[11:47:53] <hypermagic> haha
[11:48:00] <hypermagic> why would that be cool?
[11:48:18] <Lambda_Aurigae> then I can just turn them loose and let them take over the world for me.
[11:48:36] <Lambda_Aurigae> easier than doing it myself.
[11:48:39] <hypermagic> you can just throw down a 500 megaton H-bomb that is drty
[11:48:43] <martinus> Hello hypermagic, if you're limiting the question to AVR I'm on the low end of the learning curve. If not then sensory augmentation devices and astrophotography gear is on my in-progress list.
[11:48:55] <Lambda_Aurigae> maybe build some von-newman robots to collect the materials to build more.
[11:49:32] <hypermagic> that would require knowledge of how to use the materials
[11:49:36] <martinus> Somewhere an academic working in AI just unconciously broke into a cold sweat, Lambda. :D
[11:49:59] <Lambda_Aurigae> unfortunately we haven't gotten to the AI stage yet..
[11:50:10] <Lambda_Aurigae> heck, we aren't even to the AS stage yet really.
[11:50:13] <martinus> ...and relax.
[11:50:17] <hypermagic> martinus, so you already made a newton telescope right? ;>
[11:50:49] <martinus> I am in the process of setting up to grind a 10-inch speherical mirror in fact.
[11:51:01] <hypermagic> :)
[11:51:16] <hypermagic> will it be aluminium plate?
[11:51:21] <Lambda_Aurigae> glub..now I want to make another 2 meter sailplane!
[11:51:30] <martinus> I have a schmidt corrector plate from a busted telescope that I'm going to match to it to remove spherical abberation and increase the flatness of the field.
[11:51:42] <hypermagic> why not make a parabolic?
[11:52:07] <hypermagic> too easy?
[11:52:15] <martinus> Parabolic mirrors are more difficult to grind. :D
[11:52:58] <martinus> First make a spherical mirror then start a loop of paraboloise > test > parabolise > test > parabolise...
[11:53:01] <hypermagic> spin a bowl full of mercury
[11:53:12] <martinus> Only good for looking stright up. ;)
[11:53:48] <hypermagic> make a parabolic mirror and silver its surface?
[11:54:12] <hypermagic> it works out of pure aluminium btw
[11:54:22] <martinus> I wonder when the last all-metal mirror was made...
[11:54:42] <hypermagic> but it is probably easier to grind glass and aluminize the surface maybe
[11:54:53] <martinus> Glass is more thermally stable.
[11:55:08] <hypermagic> but you still coat it with aluminium
[11:55:15] <martinus> Yeah, a few microns.
[11:55:23] <hypermagic> and they have different thermal expansions..
[11:55:46] <hypermagic> so temperature cycling it will cause delamination
[11:56:03] <martinus> modern mirros get coated with alu then a high-transmission protective coating.
[11:57:12] <martinus> You'd have to heat it very quickly to cause significant delamination, at least, from what I understand.
[11:57:23] <hypermagic> no
[11:57:38] <hypermagic> just extreme, and many cycles
[11:57:46] <hypermagic> al layer will break anyway
[11:57:57] <martinus> I'm not an optics engineer so I'm, limited to what I've read of other expert opinions.
[11:58:14] <hypermagic> silver is probably better because of the chemical resistance, and it is softer
[11:58:29] <hypermagic> do they use gold mirrors ?
[11:58:32] <martinus> Yea
[11:58:44] <hypermagic> but only for IR i guess
[11:58:48] <martinus> Well, gold-plated.
[11:59:44] <martinus> See James Webb telescope for a recent example. :)
[11:59:48] <hypermagic> Lambda_Aurigae, do you already have a motion detector turret in your yard?
[12:00:03] <Lambda_Aurigae> no
[12:00:15] <hypermagic> it is very old technology, why not?
[12:00:19] <Lambda_Aurigae> have one in my shop hooked to a nerf gatling gun.
[12:18:55] <hypermagic> what if aliens come to you ?
[12:19:51] <hypermagic> Lambda_Aurigae, only computer controlled turret can protect against aliens
[12:20:13] <Lambda_Aurigae> aliens will take over the computers.
[12:20:16] <Lambda_Aurigae> they all have cyber implants.
[12:21:51] <hypermagic> what do you think about rayguns btw?
[12:22:33] <Lambda_Aurigae> give me one to test and I'll let you know.
[12:22:45] <hypermagic> those bright colored light throwing things you see in vide games
[12:23:30] <hypermagic> problem with it is the components to make on are not officially "invented"
[12:23:47] <hypermagic> one
[12:24:01] <antto> did someone say aliens? >:)
[16:33:05] <Torx_> Hi guys anyone can describe in most simple way (or just give link where i can read about it), Why i just get another .hex file from atmel studio and another from Avr when i just download .hex from it ?
[16:33:53] <Lambda_Aurigae> Torx_, that question makes no sense whatsoever.
[16:33:55] <Torx_> Here is form avr
http://pastebin.com/M353SqUB
[16:34:07] <Torx_> here is from atmel studio
http://pastebin.com/M353SqUB
[16:34:26] <Lambda_Aurigae> so, what about them?
[16:34:45] <Torx_> They aren't look the same
[16:35:00] <Lambda_Aurigae> they are intel hex file format...the format describes where to store the data in the microcontroller.
[16:35:11] <Lambda_Aurigae> so, if they aren't the same they are different.
[16:35:18] <Lambda_Aurigae> still don't understand your question.
[16:35:45] <Torx_> Ok When i try Verify i got that they are 100 % same
[16:36:10] <Torx_> but when I just look in the hex file I see differences here
[16:36:19] <Lambda_Aurigae> so, look at what the differences are.
[16:36:27] <Lambda_Aurigae> probably setup information or something.
[16:36:38] <Lambda_Aurigae> I bet the data and where it goes is the same.
[16:37:02] <Lambda_Aurigae> you will have to know the file's data format and do some comparisons.
[16:37:25] <Torx_> Hmmm ok thanks for answer. I just go to check that
[16:43:10] <Lambda_Aurigae> I don't see any differences.
[17:01:50] <Lambda_Aurigae> in fact, you posted the same link twice.
[17:02:45] <Casper> he's gone, jim
[17:02:53] <Lambda_Aurigae> oops.
