Back
[00:01:02] <dgriffi> or is there some sort of name game going on here that avrstudio32 isn't picking up on?
[00:02:47] <dgriffi> anyone?
[00:07:23] <theBear> this is really an 8bit avr channel mostly.. also you might have to wait for ANYONE to see the question...
[00:17:10] <dgriffi> theBear: what I'm after is some way to use a graphical simulator. my target is an ATmega8
[00:17:37] <dgriffi> I sort of stumbled into avrstudio32 thinking that might have something for me.
[00:19:46] <theBear> hangon
[00:19:54] <theBear> atmega doesn't do avr32
[00:20:02] <theBear> or linux
[00:20:13] <theBear> and a linux-gcc won't build for 'baremetal'
[00:20:24] <theBear> it'll only build stuff that'll run in a compatible linux environment
[00:22:02] <dgriffi> so, what do I actually need for developing and simulating atmega8 code?
[00:23:25] <theBear> avr-gcc for building it, the only thing i know that does any simulating is avrstudio, which i THINK has a linux version, i haven't touched it for many years personally
[00:24:26] <theBear> simulating is only of limited usefullness anyway, as most code for things like avr really doesn't do much without external inputs/outputs connected
[00:25:22] <dgriffi> theBear: I have the linux version of avrstudio installed already
[00:26:01] <megal0maniac> There's simulavr or something like that. Cross platform, works with gdb
[00:26:27] <megal0maniac> Pain in the arse to use from my own experience
[00:27:36] <dgriffi> and buildroot-avr-32 failed to build without giving me any clue as to why
[00:29:45] <theBear> avr32 is no use to you, you don't have an avr32
[00:29:53] <theBear> you have an avr(8)
[00:34:10] <dgriffi> so, what's a good environment to use for it?
[00:37:22] <theBear> what you mean environment ? i just use a text editor and avr-gcc (gcc and libs for 8bit avr, ie. all tiny and mega)
[00:42:35] <dgriffi> well, I've installed avr-gcc and friends. I guess I can use simulavr when I get something compiled
[00:42:58] <dgriffi> I don't even know how to get a hello-world program going.
[00:43:16] <dgriffi> things like DDRB and PORTB are undeclared
[00:45:05] <R0b0t1> Did you include the proper headers?
[00:45:11] <R0b0t1> Have you programmed in C before?
[00:45:18] <dgriffi> yes
[00:45:25] <dgriffi> I have "#include <avr/io.h>
[00:45:26] <dgriffi> "
[00:45:42] <dgriffi> and I gather that DDRB and PORTB should be defined there
[03:12:47] <theBear> hehe, flashing a led or something can be easier than 'hello world' on a micro... 'cos ya know, micros don't really have a screen or default text output :)
[03:13:06] <Badaboom> No
[03:13:24] <h4x0riz3d> morse code then
[03:13:37] <Badaboom> except mine says Chaos now
[03:13:46] <Badaboom> Not Hello;)
[03:14:44] <dgriffi> okay, I'll just get some more parts and forget about simulating
[03:15:12] <theBear> that's teh spirit !@
[03:15:22] <Tom_itx> get 2, not just one
[03:15:43] <theBear> i been using these suckers 10 years or more now, and i never thought to myself "hmm, a simulator would make this easier"
[03:15:47] <Roklobsta> get some parts, buy a Dragon. stuff simulating.
[03:16:04] <dgriffi> I'll wind up with a bunch of duplicated things, but I need a new soldering iron anyway
[03:16:11] <theBear> they sell dragons ? i heard they weren't available ! all spikey and fire breathing !
[03:16:13] <Tom_itx> get parts, buy avrtinymkii
[03:16:32] <theBear> but yeah, unless something has scaly wings and breathes fire, don't buy a dragon
[03:16:36] <dgriffi> I have one of those avrtiny-based programmers on the way
[03:16:52] <Badaboom> I swear Bear
[03:16:57] <theBear> i too, often swear
[03:17:06] <Badaboom> U drinking again?
[03:17:19] <dgriffi> I thought the dragon thing was useful if you brick an AVR
[03:17:22] <theBear> hells yes, at least until the part of the fortnight where i'm broke again
[03:17:29] <Badaboom> lol
[03:17:30] <Tom_itx> dgriffi, one of these?
http://tom-itx.dyndns.org:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[03:17:35] <theBear> well don't brick one, or get avrtinymkii
[03:18:08] <Badaboom> Ive Bricked before:(
[03:18:15] <Badaboom> Not fun
[03:18:33] <theBear> i haven't, you may call Mr Awesome if you wish :)
[03:19:04] <theBear> and i program my fuses manually with one byte hex files, none of this sissy webpage assistance stuff
[03:19:09] <Roklobsta> dgriffi: nah, ISP saves the day everytime.
[03:19:29] <dgriffi> timemage: oh, that's cute! no, not one of those. something from adafruit
[03:19:34] <Badaboom> Lobsta, u in FL?
[03:19:36] <Roklobsta> pah, #include <avr/fuse.h>
[03:19:39] <theBear> then again, i suspect that a lot of bricking is due to people using those pages without understanding... slightly wrong model = slightly wrong fuses = more than slightly sad
[03:21:11] <Badaboom> Bear, i just use a 1amp fuse
[03:21:21] <Fleck> :D
[03:21:24] <Badaboom> lol
[03:21:26] <theBear> :)
[03:22:19] <dgriffi> Tom_itx: oh, that's cute! no, not one of those. something from adafruit
[03:24:19] <theBear> orright ! revenge of the nerds started, handful of pills and a little rest for bears.... then i might have me some bacons AND eggs
[03:29:15] <Badaboom> lol
[03:29:35] <Badaboom> What no shrimp on the barbie?
[03:30:10] <Roklobsta> prawns, dagnabit.
[03:30:13] <Roklobsta> PRAWNS
[03:30:53] <Badaboom> I know what they are,, i just like teasing him
[03:31:38] <Badaboom> Wonder if they taste the same as our Jumbo Shrimp here
[03:32:01] <theBear> struth cobber ! enough of the jingo jango, give a feller a break
[03:32:26] <theBear> lol, jumbo shrimp :) are they like mini-lobsters ?
[03:32:39] <Badaboom> Naa,, not quite that big
[03:32:49] <Badaboom> Pretty big tho
[03:32:53] <theBear> outrageous !
[03:33:00] <theBear> what will those scientists come up with next ?
[03:33:19] <Badaboom> We have Stone Crabs here that are great,, you can only keep the claws tho
[03:33:28] <Badaboom> Very tasty
[03:33:46] <Badaboom> Seen some claws the size of my hand
[03:36:13] <Roklobsta> you must have a small hand
[03:42:07] <Badaboom> Have you ever seen a Stonecrab claw?
[03:43:02] <Badaboom> http://www.frenchysstonecrab.com/wholesale.php
[03:43:38] <theBear> hehe, looks like a regular crab on steroids
[03:43:45] <Badaboom> :)
[03:44:09] <Badaboom> Ive seen bigger,, believe me they arent something u wand your hand in
[03:44:23] <Badaboom> hand
[03:44:31] <Badaboom> sigh i must be tired
[03:44:53] <Roklobsta> hey where in avrgcc are things like SREG and SP defined?
[03:50:13] <Tom_itx> they were in common.h but not now
[03:51:08] <Tom_itx> AVR architecture 1 has no RAM, thus no stack pointer.
[03:51:17] <Roklobsta> found it for me... iom1280.h
[03:51:21] <Tom_itx> All other architectures do have a stack pointer.
[03:51:35] <Roklobsta> wellllllllllllllllllll, SP is alliased to regs
[03:51:45] <Roklobsta> i mean i/o ram
[03:57:05] <Roklobsta> aha, common.h sez define SP _SFR_MEM16(0x3D)
[03:57:47] <Roklobsta> joerg_wunsch is a busy guy
[04:52:07] <OndraSter__> how am I supposed to document a methods like:
[04:52:07] <OndraSter__> ItemBase* GetItem() { return Item; }
[04:52:10] <OndraSter__> void SetItem(ItemBase* Item) { this->Item = Item; }
[04:52:12] <OndraSter__> :/
[04:53:02] <RikusW> its already documented :-P
[04:53:06] <OndraSter__> :D
[04:53:07] <OndraSter__> yeah
[04:53:14] <OndraSter__> I use names that are self explanatory
[04:53:22] <OndraSter__> but we are supposed to have a thorough documentation!
[04:54:01] <RikusW> aren't you missing class::GetItem ?
[04:54:14] <OndraSter__> no
[04:54:16] <OndraSter__> this is in the .h
[04:54:19] <RikusW> ah
[04:54:23] <OndraSter__> I don't put a single command stuff into .cpp
[04:54:34] <OndraSter__> I would have a file full of a single line methods
[04:54:44] <RikusW> why not access Item directly :-P
[04:54:54] <OndraSter__> because it is a bad measure!
[04:54:56] <OndraSter__> getter & setter
[04:55:01] <RikusW> heh
[04:55:28] <OndraSter__> I might move all the code to the .cpp files
[04:55:34] <RikusW> the code would be no diffent when compiled....
[04:55:34] <OndraSter__> because this way it is recompiling more than needed
[04:55:39] <OndraSter__> yeah
[04:55:43] <OndraSter__> but it is a bad measure!
[04:55:46] <OndraSter__> ask our teachers!
[04:55:48] <RikusW> lol
[04:56:11] <RikusW> goto banned too ?
[04:56:33] <RikusW> I have the occasional use for goto
[04:56:33] <OndraSter__> I banned goto myself
[04:56:58] <RikusW> but abusing that can certainly lead to messy code
[04:57:34] <RikusW> some uni's don't even like continue; and break;
[04:58:17] <OndraSter__> I use it rarely (break and continue)
[04:58:20] <OndraSter__> (except in switch)
[04:58:28] <OndraSter__> but you cannot do switch on string in C++ since it is not a basic datatype
[04:59:08] <RikusW> switch only work on const....
[04:59:18] <RikusW> const int...
[05:00:00] <RikusW> how about returning inside a loop ?..
[05:01:00] <OndraSter__> sure! :)
[05:16:18] <OndraSter__> yayz
[05:16:19] <OndraSter__> TilePerson
[05:16:21] <OndraSter__> wrong
[05:16:31] <OndraSter__> http://pastebin.ca/2394632
[05:16:41] <OndraSter__> for some reason I can't copypasta from my host to vmware and back... but Unity works?!
[05:16:43] <OndraSter__> (vmware tools installed
[05:19:47] <RikusW> c&p works fine with virtualbox
[05:19:56] <RikusW> once its enabled in settings
[05:20:01] <OndraSter__> well I am using years old ubuntu
[05:25:47] <RikusW> In some ways I liked my old Debian etch + KDE3 better than the new Linux desktops....
[05:26:10] <specing> RikusW: go tiling :D
[05:26:39] <braincracker> h
[05:26:55] <RikusW> tiling ? another desktop ?
[05:27:57] <Roklobsta> when an IRQ is executed, the PC is pushed to the stack and the new PC is the vector. What order is the PC stored on the stack? LowMem: PC[0] , PC[1], PC[2] Highmem?
[05:28:37] <Roklobsta> or is it lowmem: PC[2] PC[1] PC[0] : highmem
[05:29:10] <RikusW> I'll have a peek at some old code of mine that used that
[05:30:12] <Roklobsta> the manual doesn't spell it out! Bad Manual!
[05:30:51] <braincracker> :)
http://pastebin.com/PimgrKBD
[05:31:29] <RikusW> seems I popped of the high one first
[05:31:38] <RikusW> so PC is stored as BE
[05:31:43] <braincracker> floatingpoint randomz extension
[05:31:45] <RikusW> even though flash is LE
[05:32:07] <Roklobsta> right so... stack lowmem: PC[2] PC[1] PC[0] : stack highmem
[05:32:19] <RikusW> ah ofc
[05:32:21] <RikusW> LE then
[05:32:37] * RikusW got inverted stack reasoning :-P
[05:32:59] <RikusW> err BE...
[05:33:05] * RikusW is confused..
[05:33:44] <RikusW> low 2 1 0 high...
[05:33:54] <RikusW> I only used 16 bit PC
[05:34:04] <Roklobsta> qewl.
[05:34:23] <RikusW> Roklobsta: got a jtag debugger ?
[05:34:32] <Roklobsta> i am using the 1280 so it should be 3 byte PC
[05:34:41] <RikusW> else you can print the value to see if it is as expected.
[05:34:44] <Roklobsta> yes I do. it's off in the other room.
[05:34:48] <RikusW> 1280 will have 2 byte PC
[05:35:04] <RikusW> since word addresses is 64k *2
[05:35:37] <RikusW> you can use the jtag to verify the code.. fortunately for you
[05:35:40] <Roklobsta> hang on, i am trying to understand the ISA still
[05:36:18] <Roklobsta> i would have thought 128K needed 3 bytes. why is PC a word address aligned and not byte
[05:36:24] <RikusW> only 256k AVR got 3 byte PC
[05:36:49] <RikusW> because AVR use 16bit instructions and PC addresses it that way too
[05:36:50] <Roklobsta> i hate reading pdf's on laptop
[05:37:06] <RikusW> (256k got 17 bit PC)
[05:37:20] <Roklobsta> AHA ok, i see, looking at ISA doc now I see 16 bit opcodes.
[05:38:15] <Roklobsta> OK I am clear now.
[05:38:17] <RikusW> there are a few 2 word instructions
[05:38:24] <RikusW> lds/sts jmp
[05:38:31] <RikusW> rjmp is 16bit
[05:38:47] <Roklobsta> i need to shift my brain out of planet 8051
[05:38:53] <RikusW> heh
[05:39:10] <RikusW> AVR is simpler, its either 2 or 4 bytes per instruction
[05:39:28] <Roklobsta> oh yeah, i hated 8051 from when i first used one in 1993
[05:39:33] <braincracker> https://en.wikipedia.org/wiki/Binary_Golay_code why is it cool to shuffle the redundancy matrix?
[05:39:58] <RikusW> PIC 16F got 14 bit opcodes :-P
[05:40:26] <Roklobsta> the 56000 DSP has 24bit data words
[05:40:37] <braincracker> :)
[05:40:38] <Roklobsta> or had
[05:40:54] <Roklobsta> and the 56002 had a sinewave in rom
[05:41:10] <braincracker> and the pc knows PI
[05:41:48] <Roklobsta> OK, i am trying to work out how to do context switches, hence the PC and SP jibber jabber
[05:41:58] <braincracker> and fsincos can create a table for you
[05:42:12] <Roklobsta> pah roll your own with cordic
[05:43:08] <braincracker> i'm not sure i'd use a thing that has a sine-table in it
[05:43:26] <RikusW> Roklobsta: basically save IP SP FLAGS + r0-r31
[05:43:59] <braincracker> that assumes i'm a weenie and unable to create one
[05:44:05] <braincracker> or worse
[05:44:16] <Roklobsta> rikus: i figured as much. just need to mess with the PC on the stack to jump to the new process.
[05:44:35] <Roklobsta> ram was tight in 1995
[05:44:53] <Roklobsta> there was gcc for 56000 too.
[05:45:02] <Roklobsta> i have the floppies somwhere.
[05:51:15] <braincracker> hey twnqx
[05:51:24] <twnqx> hey
[05:51:30] <twnqx> and sorry, afk for lunch :P
[05:56:25] <braincracker> do you use gray codes in micros?
[05:56:37] <braincracker> other than position encoder wheels ?
[06:12:47] <Gumboot> Grey-code counters are used in low-power devices, sometimes, because it means fewer flip-flop transitions.
[06:33:04] <Badaboom> Tom_itx: you available?
[06:36:49] <braincracker> Gumboot <= also you can determine a state transition correctly without glitches, only 1 bit flips at a time in a sequence
[06:36:59] <braincracker> ^^ FMA, AES instruction set
http://en.wikipedia.org/wiki/X86_instruction_listings
[06:37:03] <braincracker> hey Badaboom
[06:37:23] <Badaboom> Yo
[06:40:01] <RikusW> braincracker: nice link ! :)
[06:40:32] <RikusW> that would be ideal if I someday work on my x86 assembler again
[06:40:54] <RikusW> I didn't have any easy way to know which instruction is for which cpu...
[06:41:00] <braincracker> was teasing you a bit after the atmel instruction set
[06:42:46] <braincracker> so
http://en.wikipedia.org/wiki/Gray_code
[06:43:00] <RikusW> I did a full assember/disassembler for x86 instructions, not sure if I added MMX.....
[06:43:18] <RikusW> that was like 12 years ago...
[06:43:59] <RikusW> didn't finish symbolic support...
[06:45:05] <braincracker> The problem with natural binary codes is that, with real (mechanical) switches, it is very unlikely that switches will change states exactly in synchrony. In the transition between the two states shown above, all three switches change state. In the brief period while all are changing, the switches will read some spurious position. Even without keybounce, the transition might look like 011 — 001 — 101 — 100. When the switches
[06:45:05] <braincracker> appear to be in position 001, the observer cannot tell if that is the "real" position 001, or a transitional state between two other positions. If the output feeds into a sequential system (possibly via combinational logic) then the sequential system may store a false value.
[06:45:58] <RikusW> I made a cardboard graycode wheel for a hid steering wheel once
[06:46:03] <RikusW> 8 bit
[06:50:20] <braincracker> optical?
[06:53:46] <RikusW> yes
[06:54:04] <RikusW> IR leds + photo diodes
[06:55:00] <Badaboom> I keep wanting to do something with my 100rgb's ..im thinking about a gloge
[06:55:43] <braincracker> hehe
[06:55:57] <braincracker> start wiring up those shiftregisters
[06:56:17] <braincracker> hm, 100...
[06:56:31] <braincracker> 10x10 RGB display is not that big
[06:56:33] <braincracker> but
[06:57:02] <braincracker> if you connect 8-16 RGB leds to your atmega using shift registers, you can create a POV display
[06:57:29] <Badaboom> any atmega in mind?
[06:57:34] <Badaboom> 328 644?
[06:58:17] <braincracker> i picked 168pa for myself, it already has 16K flash
[06:58:51] <Badaboom> and ill have to get more 595's
[06:59:07] <braincracker> yeah those are cool stuff
[06:59:13] <Badaboom> I love those:)
[06:59:16] <braincracker> you can wire up any number of leds on a string
[06:59:29] <Badaboom> yep,, just keep shifting
[06:59:47] <braincracker> i'd put a buffer after 3-20 595's
[06:59:55] <braincracker> depending on speed requirements
[07:00:01] <Badaboom> 244?
[07:00:04] <Badaboom> 245?
[07:00:19] <Badaboom> ill have to look up the 244
[07:00:20] <braincracker> or an ST-not
[07:00:29] <braincracker> (2 of em)
[07:00:29] <Badaboom> hmm
[07:00:36] <braincracker> that removes noise
[07:00:43] <Badaboom> I just salvaged 2 244's the other day
[07:01:01] <Badaboom> off an old cdrom
[07:01:05] <braincracker> hehe
[07:01:09] <braincracker> some has 373 too
[07:01:12] <Badaboom> fun stuff
[07:01:16] <Badaboom> hmm
[07:01:44] <Badaboom> my eyes arent what they used to be:)
[07:01:53] <Badaboom> hard time seeing it
[07:01:55] <braincracker> use a light.
[07:02:07] <Badaboom> I use an LED light,, works best
[07:02:08] <braincracker> 3W led is fine for everything close-up
[07:02:12] <Badaboom> lol
[07:02:22] <Badaboom> agreed
[07:03:22] <Badaboom> I don't know quite all the chips,, 393?
[07:03:28] <Badaboom> err 373
[07:03:45] <Badaboom> 74hct373?
[07:03:50] <Badaboom> als?
[07:04:35] <braincracker> yes
[07:04:36] <Tom_itx> Badaboom, i am for a bit
[07:04:38] <braincracker> or LV
[07:04:43] <braincracker> LVC
[07:05:00] <braincracker> i like HC types more, because they do not neeed 4.5-5.5V
[07:05:10] <Badaboom> Tom: real quick and im not promising anything but i may be allowed to get a cookie this week
[07:05:18] <Badaboom> lol
[07:05:50] <Badaboom> That is if the plane parts are what there supposed to be $$ wise
[07:05:56] <Tom_itx> steal a couple while you're in the cookie jar
[07:06:07] <Badaboom> U know what i speak of:)
[07:06:12] <Badaboom> but i will
[07:06:14] <Tom_itx> yes
[07:06:30] <Badaboom> I have to wait to see the parts list for the plane
[07:06:40] <Badaboom> landing gear is expensive
[07:07:08] <Badaboom> sorry brain
[07:07:15] <braincracker> Badaboom <= you are building a plane ?
[07:07:35] <Badaboom> No i have a timeshare in one but keep the mait on 2
[07:07:48] <Badaboom> well order parts and whatnot
[07:07:59] <Badaboom> im not a mechanic
[07:08:23] <Badaboom> Not to say i wouldnt mind restoring an old mustang
[07:08:29] <Badaboom> but....
[07:08:46] <braincracker> building an RC plane is not really mechanical engineering
[07:08:52] <braincracker> it is more about the electronic part
[07:08:54] <Badaboom> close to 1million if u can find one unrestored.. and thats impossible
[07:09:06] <braincracker> and you can fly nearly anything that has a wing
[07:09:06] <Badaboom> Im talking the real planes
[07:09:07] <braincracker> ^^
[07:09:14] <Badaboom> lol
[07:09:24] <Badaboom> I don't trust my arse to balsa
[07:09:51] <braincracker> fiberglass, carbonfiber
[07:10:14] <Badaboom> apparently its been ages since ive seen the construction of RC
[07:10:26] <Badaboom> carbonfiber on RC?
[07:10:36] <braincracker> sure
[07:10:39] <braincracker> they use that
[07:10:42] <Badaboom> good golly
[07:10:52] <Badaboom> yeah,, so does cessna
[07:10:56] <braincracker> it is ultralight, and stiffer than fiberglass
[07:10:57] <Badaboom> on the citations
[07:11:13] <braincracker> it is however more brittle
[07:11:14] <Badaboom> I know what it is
[07:11:31] <Badaboom> 11 dimensions of weaving
[07:11:32] <braincracker> it will just "oh snap"
[07:11:36] <braincracker> :)
[07:11:50] <braincracker> wing lost
[07:11:57] <Badaboom> It's my understanding its quite strong
[07:13:19] <Badaboom> I need to look these parts up i have here
[07:13:35] <Badaboom> 245 is buffer?
[07:14:30] <braincracker> get datasheets on thing you want to use
[07:22:28] <Badaboom> What's a data sheet?
[07:23:37] <Badaboom> ok,, another bad joke brought to you by Badaboom;)
[07:23:55] <Badaboom> I pulled this one and am looking at it
[07:24:16] <Badaboom> Octal bus
[07:24:25] <braincracker> http://ecee.colorado.edu/~mcclurel/sn74ls245rev5.pdf
[07:24:40] <braincracker> it can drive leds though
[07:25:11] <Badaboom> kay?
[07:25:26] <Badaboom> interesting
[07:27:21] <Badaboom> yeah see i have the 74hct not the schlutt
[07:27:38] <Badaboom> pin for pin tho
[07:31:51] <Badaboom> then theres these
[07:31:55] <Badaboom> http://pdf1.alldatasheet.com/datasheet-pdf/view/15658/PHILIPS/74HCT688N.html
[07:32:08] <Badaboom> no good
[07:35:02] <Badaboom> and a couple 590's,, could possibly do something with those
[07:41:03] <Badaboom> right now i need to find (hunt) a 5vreg
[07:49:06] <braincracker> 7805
[07:49:48] <braincracker> lm317, fan1117 equivalent
[07:50:18] <Badaboom> yeah i don't have any.. 33pg7l405,, no clue ,, no data sheet
[07:50:27] <Badaboom> wonder if thats one
[07:50:42] <braincracker> the use the ones i presented
[07:50:43] <braincracker> y
[07:51:04] <braincracker> motherboards, vga cards, whatever
[07:51:13] <Badaboom> I know the 7805 and 317 just trying to find one in my scrap box:)
[07:51:34] <braincracker> cd drive, hdd
[07:51:37] <braincracker> printer
[07:51:40] <braincracker> motherboard
[07:51:53] <Badaboom> that one i describes is on an old cd
[07:52:14] <Badaboom> I havent managed to find any 7805s or 317's
[07:52:53] <Badaboom> im sure one of these has to be equiv
[07:56:42] <OndraSter__> no 7805/317s in your boxes?
[07:56:46] <OndraSter__> I have got them everywhere
[07:56:51] <OndraSter__> nearly even stuck in my feet
[07:57:50] <Gumboot> Is there a straightforward AVR instruction set simulator I can use for testing code performance without flashing a device?
[07:58:10] <Gumboot> Something which will give me printf() to stdout.
[07:58:30] <Badaboom> OndraSter__: i know,, i usually always have them:(
[07:58:33] <ambro718> maybe
http://gitorious.org/simavr
[07:59:03] <ambro718> haven't tried it, but apparently it prints output into usart0 into stdout
[07:59:34] <ambro718> so you just need to do whatever you need to make printf go to serial
[07:59:39] <ambro718> (google it)
[07:59:57] <tzanger> does it simulate peripherals including timing?
[08:00:08] <tzanger> oh I clicked the "more" link, heh
[08:00:14] <Gumboot> Seems likely I could just get a good libc and it'll set itself up.
[08:03:09] <ambro718> if you're lazy you can take my code
http://ideone.com/Hn8KV7
[08:03:14] <ambro718> just need -DBAUD=...
[08:07:46] <ambro718> If anyone needs optimized division or sqrt:
https://github.com/ambrop72/avr-asm-ops division is faster than what gcc-4.8 produces, the unrolled div_32_32_large takes 384 cycles versus gcc's 653. The smaller div_32_32_small takes 510.
[08:12:22] <Gumboot> Is GCC's divide just compiled C?
[08:12:58] <Gumboot> If so, maybe you should ping the maintainer and get that integrated. It'd be better for everyone.
[08:14:48] <ambro718> Gumboot: I'm trying to get that done,
http://lists.nongnu.org/archive/html/avr-libc-dev/2013-06/msg00001.html
[08:15:02] <ambro718> but the big unrolled version is probably not suitable for default use
[08:15:14] <ambro718> it's about 2K of code lol
[08:16:19] <Gumboot> My first 8051 had 2k of code space.
[08:19:52] <Badaboom> See ya later all,, gotta run to the store
[08:21:40] <Gumboot> ambro718: Have you tried rolling some of the repeated macros into loops?
[08:26:44] <ambro718> Gumboot: yes, that's div_32_32_small
[08:26:55] <ambro718> but it's much slower
[08:26:56] <Gumboot> I kind of wonder if division isn't the same kind of horrible accident as printf(), and including either in your code might suggest that you need to re-think.
[08:27:25] <Gumboot> Obviously sometimes you really do need a division... but maybe not as often as it happens by accident.
[08:27:25] <ambro718> huh?
[08:27:50] <Gumboot> Well, one of the classic mistakes people make when they don't want large code is that they call sprintf somewhere in it.
[08:28:25] <ambro718> no, I really need division, I need to solve quadratic equations
[08:28:51] <jacekowski> good luck with that on avr
[08:28:58] <ambro718> it's working well
[08:29:15] <ambro718> I'm driving a stepper and I solve a quadratic equation for every step
[08:29:44] <jacekowski> you probably can do it using integer math
[08:29:50] <ambro718> this,
https://github.com/ambrop72/aprinter/blob/master/aprinter/driver/AxisDriver.h
[08:30:02] <ambro718> indeed, I use integer math. Including integer division.
[08:30:22] <jacekowski> then it's not so bad
[08:30:23] <ambro718> (but it's wrapped into a FixedPoint template class which keeps track of the exponent)
[08:33:38] <Gumboot> Convert everything to logarithms. Then it's just a subtraction.
[08:34:21] <Gumboot> I'm sure my algorithm would be better than 400 cycles.
[08:34:37] <Gumboot> Perhaps "sure" is an overstatement.
[08:34:46] <ambro718> how do you add logarithms?
[08:35:00] <Gumboot> Not easily!
[08:35:07] <ambro718> yeah ;)
[08:35:16] <Gumboot> I think you can LUT your way out of it, but you end up doing a mulitply.
[08:37:27] <Gumboot> something like a table of log(exp(x)+1)
[08:38:30] <ambro718> somehow I think I'll me more successfull by optimizing my fixed-point code even more
[08:38:56] <Gumboot> Probably.
[08:39:31] <ambro718> I can still speed up the division and sqrt because I don't have real 32-bit numbers (30 bit or something rather)
[08:40:31] <Gumboot> pow(x, y) is often done as exp(log(x)*y) though (with tweaks to avoid zeroes and ones in ugly places).
[08:41:53] <Gumboot> That probably comes down to hardware accelerating a minimal set of operations, where it turns out that exp() and log() give good coverage compared to other operations.
[08:43:25] <ambro718> but then I'd probably need to use floating point to do anything useful with exp and log
[08:43:48] <Gumboot> Works fairly well as 8.24 fixed-point.
[08:44:00] <Gumboot> floating point is awfully close to log domain already.
[08:44:50] <ambro718> ah yes I see
[08:45:19] <Gumboot> The sign bit turns out to be a degenerate angle (0 or 180 degrees only). If you extend it to a word then you have full log-polar coordinates.
[08:54:02] <ambro718> Right. Have you done any tests how fast this works out?
[08:54:24] <ambro718> can you get exp and log to work fast enough?
[09:07:23] <Gumboot> The one platform I did it on had multiply and divide that were faster than the conversions.
[09:07:27] <Gumboot> And more accurate.
[09:20:55] <braincracker> lol.
[09:21:30] <braincracker> shit platform
[09:23:18] <tzanger> Gumboot: you're far too CS for me. I can barely follow this conversation :-)
[09:23:46] <tzanger> I consider myself more like that oddly retarded race from ST:TNG... I think I'm a packlid here... I make things go. that's about it.
[09:26:41] <braincracker> tzanger <= counterstrike?
[09:28:41] <tzanger> no, computer science
[09:29:36] <tzanger> Gumboot seems to ahve a very deep and theoretical knowledge about basic math function. I just look for a faster routine (from people like him) when I find that the function I have is too slow.
[09:29:58] <braincracker> oh
[09:30:44] <braincracker> Gumboot <=
https://en.wikipedia.org/wiki/Binary_Golay_code why is it cool to shuffle the redundancy matrix?
[09:31:13] <braincracker> (apart from the thing to be incompatible with other implementations)
[09:35:12] <Gumboot> tzanger: Only a few things which I've taken the time to study. Very few things.
[09:38:25] <Gumboot> braincracker: What shuffling is this?
[09:39:25] <braincracker> well they say it is generated according to the 12 faces of a dodecahedron (12 faces)
[09:40:02] <Gumboot> Sounds like Timecube talk to me!
[09:41:26] <braincracker> http://www.quadibloc.com/crypto/mi0602.htm
[09:41:42] <braincracker> but military has some odd standard for the shuffling method too
[09:42:26] <braincracker> "ITU H.223"
[12:29:40] * braincracker examines very old manypin PDIP microcontroller board with 5 digit 7segment+dot display, ;/ too many pins, i'm not gonna desolder that, *grabs* screwdriver, fixes things
[12:30:04] <braincracker> mm nice 5 digit led display, it glows red with less than 0.5mA
[12:38:16] <xaxes> hey all.. a simple question.. I have a bts7741 and some of the pins are connected together inside.. so I have some pins 4 times, and others 2 times.. do I have to connect them all? and why if so?
[12:39:12] <twnqx> load distribution or noise immunity, normally
[12:39:31] <xaxes> hah, okay :) thanks!
[12:49:17] <braincracker> wow, the board has a pcf8583
[12:49:32] <braincracker> PCF8583
[12:49:32] <braincracker> Clock and calendar with 240 x 8-bit RAM
[12:50:32] <braincracker> would you use this ? www.nxp.com/documents/data_sheet/PCF8583.pdf
[12:51:00] <twnqx> if i had a need for it...
[12:53:52] <braincracker> an interrupt every second and a little coding can do the same
[12:54:06] <braincracker> even more
[13:56:54] <Gumboot> seems something in that division code I posted earlier kills avr-gcc dead.
[13:57:17] <Gumboot> At least, my build (4.7.2).
[14:01:25] <inkjetunito> Gumboot: repost
[14:32:25] <braincracker> uhh
[14:33:05] <braincracker> did you know atmega168 and similar has internal temperature sensor? it is tied to adc8
[14:38:19] <braincracker> i'm a bit confused on this internal aref thing, i have connected the aref to avcc with a piece of copper, will this cause the internal reference to short on avcc if i enable internal 1.1V aref ?
[14:38:41] <braincracker> or is it muxed properly?
[14:39:05] <braincracker> abcminiuser ?
[14:39:52] <abcminiuser> What device?
[14:40:12] <abcminiuser> Most likely it will catch fire, usually you just whack a cap on there to buffer the charge
[14:40:26] <abcminiuser> Also, holy god is the new IOS7 interface ugly
[14:40:36] <braincracker> abcminiuser <= atmega168pa
[14:41:00] <braincracker> hm...
[14:41:24] <braincracker> but i wanted to use +5V as reference now
[14:41:33] <braincracker> so tied that to aref
[14:41:56] <abcminiuser> Lemme grab the datasheet one sec
[14:42:05] <braincracker> datasheet is unclear i think
[14:42:21] <braincracker> it does not tell me if it will catch fire or not
[14:43:15] <abcminiuser> Internal reference voltages of nominally 1.1V or AVCC are provided On-chip. The voltage refer-
[14:43:15] <abcminiuser> ence may be externally decoupled at the AREF pin by a capacitor for better noise performance.
[14:43:17] <braincracker> if it does, then i would need to use some resistor
[14:43:43] <abcminiuser> Meaning it is available on AREF, and connecting AREF to VCC will break it if you select an internal source lower than VCC
[14:43:54] <braincracker> but resistor to +5V will give a pullup current, don't know if it is ok, and also, it will decrease performance when i want to use 5V reference
[14:44:14] <braincracker> ahhh
[14:44:32] <abcminiuser> Figure 24-1 shows the internal MUX, which connects it to AREF
[14:44:33] <braincracker> so i do not need to connect my aref to avcc if i want that for reference?
[14:44:43] <abcminiuser> No
[14:44:54] <abcminiuser> Keep AVCC as VCC +/- .3V
[14:44:56] <braincracker> i think i have read this somewhere btw
[14:45:07] <abcminiuser> Then just put a cap on AREF and use the internal reference
[14:45:30] <abcminiuser> AVCC should be at VCC level, it's a dedicated pin so you can add filtering on the analog supply
[14:45:41] <braincracker> and if i turn off the internal 1.1V reference then it will mux avcc on it ?
[14:45:54] <abcminiuser> Only if you select that
[14:46:10] <braincracker> okey thanks
[14:46:18] <braincracker> seems like i miswired this thing
[14:46:27] <abcminiuser> See 24.5.2
[14:46:27] <abcminiuser> ADC Voltage Reference
[14:46:36] <braincracker> good to know if i'd switch the internal reference on now it would catch fire
[14:47:19] <abcminiuser> This call may be monitored for quality control purposes.
[14:49:06] <braincracker> hmm so i could use aref pin to control a mosfet
[14:49:11] <braincracker> ;>
[14:49:32] <braincracker> or a pnp transistor
[14:49:43] <abcminiuser> Err, not recommended
[14:49:46] <braincracker> 24 io pins then
[14:49:48] <braincracker> ^^
[14:50:21] <braincracker> *** +1 output
[14:51:33] <braincracker> cutting traces on boards before i solder them
[14:51:37] <braincracker> ;/
[14:56:11] <abcminiuser> http://www.cultofmac.com/230825/this-is-what-ios-7-looks-like-gallery/
[14:56:22] <abcminiuser> For a design company, they sure made an ugly-ass theme
[15:19:42] <systemerror> hi all
[15:22:55] <systemerror> avrdude usbdev_open() did not find any usb device usb ?
[15:24:24] <MannImMond> root
[15:25:09] <systemerror> yes root
[15:26:06] <twnqx> it's a system error, then
[15:28:00] <systemerror> what?
[15:30:41] <MannImMond> what is your target programmer? What is your OS?
[15:32:33] <systemerror> is ubuntu 11. at90usb1287
[15:33:07] <systemerror> say: avrdude usbdev_open() did not find any usb device usb
[15:33:13] <MannImMond> Which programmer are you trying to use? Can you see it with lsusb?
[15:33:27] <systemerror> make: ** [program-dragon] Error 1
[15:35:30] <systemerror> with lsusb - Atmel corp. at90usb AVR DFU bootloader
[15:45:49] <Gumboot> inkjetunito: the killer line was `while (j >= (256 << 8)) ... ` -- changing it to `while (j >= ((uint32_t)256 << 8)) ...` fixed it.
[15:46:51] <Gumboot> I take that back. The change only made the problem show up later.
[15:48:21] <ambro718> Gumboot: 256<<8 is integer overflow on AVR
[15:50:06] <Gumboot> Yeah. Producing a binary that stops in the middle is a pretty extreme interpretation of "undefined behaviour".
[15:50:25] <Gumboot> It's a fantastic size optimisation, though.
[15:50:27] <braincracker> abcminiuser <= so the temperature measurement device is part of the internal bandgap reference i assume
[15:51:08] <Gumboot> That was 256<<8 in the parser, by the way.
[15:51:08] <braincracker> 314mV typ @ 25C
[15:51:24] <Gumboot> Fixing it still produces garbage output.
[15:51:52] <ambro718> Gumboot: it's pretty clear, the type of "256" is int because "int" is the first type from (int, long int, long long int) that can hold that value (see standard). And right-shifting that by 8 produces something not representable in int.
[15:52:16] <ambro718> Gumboot: what's your problem? (I just came here)
[15:52:34] <ambro718> * left-shifting...
[15:52:42] <Gumboot> I was compiling code and I found that the object file was nearly empty.
[15:52:55] <Gumboot> Even main was missing.
[15:53:46] <Badaboom> yawn
[15:53:46] <Gumboot> Because the compiler hit the line in question, and freaked out and stopped producing output.
[15:53:46] <Gumboot> Must be the back-end, or it would have produced nothing at all. I don't even know what it _intended_ to produce there.
[15:53:54] <Gumboot> Oh, but I could guess. When I get the types right it subtracts one from the constant and compares with that. It probably freaked out at the unsigned comparison.
[15:54:06] <Gumboot> unsigned comparison with zero minus one.
[15:54:10] <ambro718> it may just have, legitimately, assumed that that point in the program could not have been reached, since it was doing UB
[15:54:39] <Gumboot> I think it's meant te emit a warning.
[15:54:50] <twnqx> did you use -Wall -Werror? :P
[15:54:55] <ambro718> usually it does, perhaps you have turned it off, or you need ^^
[15:54:56] <Gumboot> The former.
[15:55:05] <twnqx> btw, gcc optimizes dead code away
[15:55:11] <twnqx> legitimately
[15:55:13] <Gumboot> main is dead code?
[15:55:24] <twnqx> and it can kill code like if -1 > 0
[15:55:33] <twnqx> and it can kill code like if (-1 > 0) { }...
[15:55:53] <Gumboot> You know what it can't kill? A call to a 64-bit shift library function when you shift a 64-bit value by a multiple of 8.
[15:56:18] <twnqx> unless you did not delcare 256 as 32 or 64bit value
[15:56:26] <Gumboot> Instead it loads the constant 16 into another operand register (both the high and low bytes of the constant 16) and calls another function.
[15:56:29] <twnqx> because iirc sizeof(int) on avr is 16
[15:56:39] <twnqx> and 256 < 8 is larger than that
[15:56:55] <Gumboot> 256 << 8
[15:56:57] <twnqx> the behavior of that shift is not defined in avr
[15:57:01] <twnqx> yes
[15:57:04] <twnqx> 256 << 8
[15:57:14] <Gumboot> It wasn't in an AVR, it was in the compiler.
[15:57:19] <twnqx> so what
[15:57:32] <twnqx> the compiler behavior is not defined by the C language standard
[15:57:36] <Gumboot> So I expect the compiler to issue a warning.
[15:57:54] <Gumboot> I'm not using the C language standard to compile my code. I'm using GCC.
[15:58:00] <ambro718> fix your expectations then
[15:58:05] <twnqx> indeed
[15:58:21] <twnqx> i have never seen gcc emit an overflow/underflow warning
[15:58:24] <ambro718> but you looks like you're not aware GCC tries to follow the C standard
[15:58:31] <ambro718> twnqx: I have
[15:58:34] <Gumboot> twnqx: Maybe because you use avr-gcc and it has a bug?
[15:58:39] <Gumboot> On desktop it does it all the time.
[15:59:07] <ambro718> twnqx:
http://ideone.com/60PZwI
[15:59:45] <Gumboot> ambro718: Are you seriously trying to tell me that I should expect that when GCC encounters nonsense code I should expect it, rather than emit something saying "that's a load of crap", it will just truncate the object file?
[16:00:23] * twnqx stares at his gcc
[16:00:43] <twnqx> no, it will eliminate dead code
[16:00:46] <Gumboot> Maybe it should truncate my whole hard drive.
[16:00:54] <Gumboot> Or set my computer on fire.
[16:00:56] <twnqx> which is behavior people rely on
[16:01:36] <twnqx> the outcome of your shift is not defined. any code relying on the result can thus be eliminated.
[16:01:45] <twnqx> that is even documented, though not in the manpage
[16:01:52] <Gumboot> Maybe email an anonymous terrorism tip to the police to get me arrested for shifting an integer further than I intended.
[16:03:39] <twnqx> and i am not the only one writing macros with an if() in it and expecting gcc to kill a constant if
[16:03:40] <Gumboot> I don't expect gcc to kill a constant if.
[16:03:40] <twnqx> i do
[16:03:40] <twnqx> and everyone knowing gcc will know it does
[16:03:40] <twnqx> maybe not with -O0
[16:03:40] <Grievre> If a compiler doesn't kill a constant if it's a worthless compiler
[16:03:40] <ambro718> Gumboot: feel free to compile with -O0
[16:03:40] <Grievre> imo
[16:03:48] <Gumboot> twnqx: So you _are_ the one expecting gcc to kill a constant if.
[16:03:54] <twnqx> not the one
[16:03:54] <Gumboot> By your own admission!
[16:04:11] <twnqx> but one of the majority
[16:04:15] <Gumboot> It's not killing a constant if, anyway.
[16:04:16] <twnqx> of preogrammers using compilers
[16:04:19] <twnqx> no
[16:04:30] <twnqx> but like i said twice already
[16:05:20] <Gumboot> What it is doing is truncating the object and assembly files.
[16:05:20] <twnqx> and i say it doesn't
[16:05:20] <twnqx> or do you have proof of that?
[16:05:20] <twnqx> does you object file not link?
[16:05:20] <Gumboot> Of course not!
[16:05:22] <Gumboot> It's truncated.
[16:05:23] <twnqx> or you asm file not compile?
[16:05:26] <twnqx> yeah yeah
[16:05:28] <Gumboot> No, that's truncated too.
[16:05:32] * twnqx parts attention
[16:05:34] <Gumboot> main is missing.
[16:05:44] <Grievre> Gumboot: give the offending C file and the .s file that gcc generates
[16:05:57] <Grievre> because now I'm curious
[16:06:22] <Gumboot> Give me a minute.
[16:09:20] <Gumboot> Damn it. Now I'm stuck between optimisations. I'll do it later.
[16:09:30] <scipy53> I'm working with FreeRTOS on an AVR, and have a simple question. Can I ask here?
[16:09:31] * Grievre hahs
[16:09:37] <Grievre> scipy53: Sure
[16:09:40] <scipy53> Thanks
[16:09:58] <scipy53> So I am having a hard time understanding what semaphores are for
[16:10:14] <scipy53> I can't see why the examples given can't just use queues
[16:10:31] <scipy53> To send data between tasks
[16:10:57] <Grievre> How do you suppose a queue works?
[16:11:25] <scipy53> Umm, ok sorry if I'm totally wrong, I'm very new to this stuff
[16:11:31] <Grievre> I'm pretty sure the implementation of a queue involves semaphores at some point
[16:11:38] <scipy53> I think they are related
[16:11:53] <scipy53> But I think a queue just holds a pointer to a spot in memory
[16:12:02] <Grievre> just one pointer?
[16:12:22] <scipy53> Each entry into the queue, I think, is pointed to with just one
[16:13:16] <Grievre> scipy53: Using semaphores directly instead of a queue allows you to avoid unnecessary copying of data I would assume
[16:13:52] <scipy53> I thought queues don't copy data
[16:14:14] <Grievre> it depends on which of the many implementations of a queue you use
[16:14:23] <scipy53> That seems to be true
[16:14:39] <scipy53> So why would I ever want to send a copy anyway? Wouldn't that use more memory?
[16:15:25] * Grievre rubs forehead
[16:15:32] <Grievre> That's a fundamental programming question
[16:15:40] <Grievre> not an avr or freertos-specific question
[16:15:45] <scipy53> I suppose so
[16:16:07] <scipy53> Anyway, thanks for leading me off in a new direction
[16:16:14] <scipy53> Will attempt some more research
[16:16:38] <scipy53> Thanks Grievre
[16:27:29] <Gumboot> Ah, well that's where main went. It inlined the call to the faulty function.
[16:31:17] <Gumboot> I can't even _force_ an "unsigned compare with 0" warning with an explicit unsigned compare with zero. What's the switch for that?
[16:35:42] <Gumboot> OK, so the result was (256 << 8) -> 0 (as we already knew), used in an usigned compare to produce an infinite loop. The rest of the file disappeared because that infinite loop was inlined.
[16:36:33] <tzanger> optimization at its finest
[16:36:45] <tzanger> I bet your feeble human mind would not have done such an amazing job
[16:36:49] <Gumboot> I'd hate to have had call overhead on my infinite loop.
[16:40:12] <Gumboot> I like the infinite loop better, to be honest.
[16:40:23] <Gumboot> The optimisation on the other version makes me cringe.
[16:58:04] <Gumboot> further optimised:
https://gist.github.com/sh1boot/5732738
[16:59:04] <Gumboot> But it's still pretty awful compared to what I'd expect from hand-coded assembly.
[17:00:32] <Gumboot> And it was the addition of the conditional return at the start which highlighted the inlining behaviour.
[17:02:17] <ambro718> Gumboot: AVR assembly is easy
[17:03:09] <ambro718> but my usual approach to asm is to first bring the C code to "asm level" so rewriting it in asm is little more than substitution, and preserving correctness is easy
[17:06:07] <ambro718> while (t >= ((uint32_t)256 << TABBITS)) <-- such shifts are inefficient in AVR
[17:11:31] <ambro718> isn't that the same as "(t >> (TABBITS + 8)) >= 1" ?
[17:12:23] <ambro718> it's easier to check because it means to just check some high bits in 't', as opposed to producing an uint32_t and comparing to it
[17:12:51] <ambro718> Gumboot: and there's no UB ;)
[17:12:57] <ambro718> or risk of UB
[17:26:28] <braincracker> data ff = 11111111 =>
[17:26:28] <braincracker> 2d2d = 0010110100101101
[17:26:36] <braincracker> who can spot the pattern?:)
[17:28:42] <Gumboot> ambro718: TABBITS is a constant, so 256 << TABBITS is a constant, and a power of two.
[17:28:46] <Gumboot> The compiler is bungling the comparison.
[17:28:53] <Gumboot> Wait.. not what I meant.
[17:29:06] <Gumboot> (uint32_t)256 << TABBITS is a power of two (because _
[17:29:11] <Gumboot> (because _that_ isn't zero)
[17:29:23] <ambro718> Gumboot: so is there anything wrong with my suggestion?
[17:29:38] <ambro718> you can even remove the >=1 part
[17:29:45] <Gumboot> Depends on whether or not TABBITS is a multiple of 8.
[17:29:58] <Gumboot> If it's not, I'd expect the compiler to do something even more stupid than what it's doing now.
[17:30:52] <Gumboot> When you compare with a power of two, and the cut is below that power of two, then you should only compare one byte. Not all of them.
[17:31:12] <Gumboot> Well, as many bytes as there are between the top and that single bit.
[17:31:16] <Gumboot> But in my case, just one byte.
[17:31:51] <Gumboot> What the compiler actually generates is while (!(t <= 0xffff))
[17:32:01] <Gumboot> Which forces it to compare both bytes.
[17:34:00] <Gumboot> Or in more general terms, cmpc with zero is pointless.
[17:34:31] <Gumboot> (if nothing more interesting follows, and your test doesn't include equality)
[17:36:12] * Gumboot tries while (t >> ((TABBITS + 8) & ~7) >= (1 << (TABBITS + 8) & 7))
[17:37:39] * Grievre wonders if Gumboot is of the walrus variety
[17:38:32] <Gumboot> Is that about my misplaced ( ?
[17:39:38] <Grievre> Gumboot: Do you have that C/asm pair I asked about earlier? That demonstrates the problem you're talking about?
[17:40:20] <Gumboot> 22:21 <Gumboot> OK, so the result was (256 << 8) -> 0 (as we already knew), used in an usigned compare to produce an infinite loop. The rest of the file disappeared because that infinite loop was inlined.
[17:41:57] <Grievre> Gumboot: I don't understand why you are pasting that
[17:42:17] <Gumboot> Because it's the answer.
[17:42:44] <Grievre> I want to see the code, not your description of the code
[17:43:12] <Gumboot> It's not a description of the code. It's a description of the problem.
[17:43:56] <Gumboot> ambro718: That's even worse!
[17:44:17] <Gumboot> Now it's testing three eight bit registers to see if they're zero.
[17:44:36] <ambro718> Gumboot: yes, that's the inherent complexity of it, I think
[17:45:01] <Gumboot> Not at all. The test can be done with a single compare.
[17:45:06] <ambro718> how would *you* test it?
[17:45:42] <Gumboot> We go in with a value between 0x0000 and 0xffff, and we shift it left by 8 before comparing it with 0x10000.
[17:46:02] <Gumboot> All we need to know is whether or not j & 0xff0000 is non-zero.
[17:46:15] <Gumboot> t, rather.
[17:46:38] <ambro718> Gumboot: so compare it before you shift it
[17:46:44] <Grievre> Gumboot: I still want to see a code sample
[17:47:06] <ambro718> while ((before_shift >> TABBITS)) { ... }
[17:47:15] <Gumboot> Grievre:
https://gist.github.com/sh1boot/5732738 cut out the (uint32_t) discussed earlier, and delete the conditional early return.
[17:47:15] <ambro718> that's assuming the shifting was by 8 bits left
[17:47:47] <Grievre> Gumboot: oh wait, you had a while (always true) { something } and then something else after that?
[17:47:52] <Grievre> Gumboot: yeah, that makes sense
[17:48:23] <Gumboot> Grievre: The thing I failed to parse correctly was not that divfn() had been converted into a short infinite loop, but that main had disappeared because it _inlined_ the same loop.
[17:48:27] <Gumboot> IT had just become tiny.
[17:49:00] <Gumboot> Also, the other part I thought should still be in main was #ifdef-ed out.
[17:50:08] <Gumboot> ambro718: That's kind of like the other version I had, there.
[17:51:30] <Gumboot> Grievre: I figured it out when main reappeared, because I had pressed forward with my intended optimisation, which involved putting the conditional return into divfn().
[17:54:08] <Gumboot> ambro718: Doing the test on the original 16-bit type fixed it.
[17:54:19] <ambro718> yeah :D
[17:54:31] <Gumboot> Unfortunately that forced me to use an inner loop which came out absolutely terrible.
[17:54:44] <ambro718> show your code
[17:54:44] <Gumboot> Looks like an right shift where k catches the carry from j, right?
[17:55:05] <Gumboot> ambro718: Same function; but it's the opposite side of the #if block.
[17:55:57] <Gumboot> Should just be lsr, ror, ror, but gcc added mov, mov, clr, or, lsr, and ror.
[17:55:58] <Gumboot> and mov and clr
[17:56:32] <Gumboot> Oh god... unless mov and clr are part of the compare.
[17:56:43] <ambro718> yes, don't worry about that, you have shifts that eat the carry (ror, rol)
[17:57:55] <Gumboot> Is there an idiom that GCC is more likely to catch to implement that loop?
[17:58:11] <Gumboot> ... where'd my inc go?
[17:58:29] <Gumboot> oh, subi.
[17:58:51] <Gumboot> Does AVR have two completely different instruction sets for each half of its register file or something?
[17:59:15] <ambro718> Gumboot: what's the purpose of the first line inside the loop k = ((j << 7) & 0x80) | (k >> 1); ??
[17:59:30] <ambro718> Gumboot: why not just "k = t" like the upper loop
[17:59:58] <ambro718> you're repetedly overwriting the value of "k" without using it in the mean time
[17:59:59] <Gumboot> ambro718: I don't know how many times I iterate, but for every time that I do iterate, I want the carry which falls off of j to be pushed onto the top of k.
[18:00:10] <Gumboot> k is used at the end of the line.
[18:00:14] <Gumboot> | (k >> 1);
[18:01:05] <ambro718> ah I see, so yes, that would be just ror in assembly
[18:01:09] <Gumboot> The first version temporarily maps k to the bottom 8 bits of t. The second version tries to use j and k directly, but there's nothing in C which implements the ROR instruction.
[18:01:31] <ambro718> Gumboot: IMO you're going to have to do this in asm anyway if you want to make if useful
[18:01:36] <Gumboot> But the first version results in a convoluted comparison because t is so big.
[18:01:37] <ambro718> so don't worry about what gcc does
[18:01:59] <Gumboot> I'm full of hope and optimism for GCC optimisation performance.
[18:02:16] <ambro718> avr-gcc is dumb, you're wasting your time with it
[18:02:16] <Gumboot> But saying things _could_ get better is just another way of saying they're crap right now.
[18:02:39] <Gumboot> So hope is a pretty negative perspective, really.
[18:03:25] <Gumboot> I remember I used to work with ..umm.. Keil or that other one..
[18:03:43] <Gumboot> What might I be thinking of which isn't Keil?
[18:04:56] <braincracker> weenietot ?
[18:05:07] <Gumboot> IAR.
[18:05:07] <twnqx> isn't keil pretty expensive?
[18:05:12] <Gumboot> I don't know why weenietot made me think of it.
[18:05:28] <braincracker> ;>
[18:05:47] <braincracker> BirdyNumNum made me remember Al Bundee
[18:05:59] <Gumboot> I think I was meant to make a decision and I intended to order one but I ended up with the other.
[18:06:09] <Gumboot> Which didn't seem matter very much because it was doing a fine job anyawy.
[18:07:06] <twnqx> well, open source = you get what you pay for :/
[18:07:17] <braincracker> :)
[18:07:25] <twnqx> and gcc is almost a trainwreck of software
[18:07:39] <twnqx> maybe someone implements a llvm backend one day
[18:07:53] <braincracker> it is mostly usable, because you know, they want to use it
[18:08:01] <ambro718> someone did but I'm not sure about its current state (google avr llvm)
[18:08:03] * twnqx goes to dream of that, nn
[18:08:23] <Gumboot> GCC seems like it must be very hard to hack.
[18:08:31] <twnqx> it is
[18:08:46] <Gumboot> If LLVM breaks into the 8-bit space it'll probably get a lot of architectures very quickly.
[18:13:36] <Horologium> a full branch off of gcc for avr would be better than trying to keep it integrated into the gcc core.
[18:13:42] <Horologium> and a full rewrite...but, still.
[18:15:16] <ambro718> Horologium: who's going to maintain the steady flow of new features, esp. C++ stuff?
[18:15:24] <Gumboot> Could LLVM really do worse than GCC on AVR?
[18:15:43] <braincracker> yes
[18:15:45] <Horologium> one of the things I would love to see is an external/extended memory extension for gcc...to be able to put a parallel or serial sram on the device and define a memory segment for it for heap storage or the like.
[18:15:46] <Gumboot> The weaknesses I've seen in LLVM don't seem relevant. There may be more I haven't noticed, but ..
[18:16:10] <Horologium> poorly implemented llvm would be worse than current GCC.
[18:16:23] <braincracker> Horologium <= you can do that
[18:16:27] <braincracker> why not?
[18:16:29] <Horologium> ambro718, didn't say it would be easy.
[18:16:40] <Horologium> braincracker, how?
[18:16:50] <Horologium> I know some AVRs have external memory interface already.
[18:17:18] <braincracker> it is just... atmels don't really support that
[18:17:21] <Horologium> I'm talking about implementing it in software,,,specially for using serial srams...but looks like I'll have to od it myself.
[18:17:32] <braincracker> i think they are not able to run code from external ram
[18:17:41] <Horologium> I'm not talking about code.
[18:17:47] <Horologium> I said heap...variables storage.
[18:18:16] <Horologium> yes, it would slow things down.
[18:18:22] <Horologium> but it would be fun to play with.
[18:18:26] <braincracker> http://www.nongnu.org/avr-libc/user-manual/malloc.html
[18:18:59] <braincracker> the memory allocator thingy for avrs is a bit over-simlified, but it is there
[18:18:59] <Horologium> that only supports the internal and hardware mapped external ram.
[18:19:40] <Horologium> up to 64KB on the atmega chips that support external memory.
[18:20:27] <Gumboot> So what's the penalty in using external RAM at present?
[18:20:34] <Gumboot> More complex instructions?
[18:20:36] <Horologium> it would have to be implemented something like the way eeprom access is I bet..
[18:20:46] <Horologium> Gumboot, depends on how the external ram is configured and what
[18:20:51] <Horologium> what you want to do with it.
[18:21:05] <Gumboot> OH, so it's not implicitly supported with special instructions?
[18:21:25] <braincracker> Horologium <= yes you must write a readwrite function to it, unles atmel starts adding more support
[18:21:26] <Horologium> currently, if it is not part of the contiguous 64K ram space then you can't use it for simple access via simple instructions...you would have to write your own access routines.
[18:21:44] <braincracker> it is because 16 bit pointer...
[18:21:46] <Gumboot> 8051 has only 256 bytes of internal, so you usually hit the "external" interface while addressing more internal RAM even before you get to real external memory.
[18:22:09] <braincracker> you need larger address space, or memory pages to address more
[18:22:15] <Horologium> Gumboot, yes, that's why I use 8051/2 chips on occasion...because of the nice external ram access.
[18:23:00] <Horologium> what I am looking at is replacing malloc and other routines that access the internal SRAM with something that can access serial memories, like serial sram.
[18:23:41] <braincracker> ok, you need to add read write function to malloc things
[18:23:55] <Horologium> for chips like the atmega8515 and atmega128 there is a hardware interface for parallel sram or even memory mapped i/o up to 64KB total.
[18:24:07] <Gumboot> Whichever compiler I ended up using, in my previous idle ramble, it was originally bought for 8051 compilation, and it implemented an overlay structure rather than a stack.
[18:24:11] <Gumboot> I thought that was pretty neat.
[18:24:32] <Horologium> that extended sram can be accessed by programs compiled with GCC with minimal effort...
[18:25:33] <Horologium> my sick and twisted brainchild would be adding memories elsewhere and make easy access to them.
[18:25:52] <Horologium> maybe by adding a variable definition extension or something.
[18:26:08] <Horologium> or specific variable types... uint8_ext or something.
[18:26:23] <braincracker> hm
[18:26:35] <Horologium> but I have to learn much more about the core of gcc before I can do that level of work.
[18:26:42] <Gumboot> far pointers!
[18:26:56] <Horologium> Gumboot, it's far more than just far pointers.
[18:27:09] <Horologium> it would have to be defined as a whole different memory segment.
[18:27:10] <Gumboot> really_far pointers!
[18:27:11] <braincracker> Horologium <= i think if you find the malloc function you can just modd it
[18:27:27] <braincracker> adding custom types is interesting
[18:27:28] <Gumboot> Far pointers were different memory segments.
[18:27:40] <Horologium> malloc is a start but there are other routines that access the malloc'd memory sections.
[18:28:03] <braincracker> Horologium <= though there is a thing in avr-gcc already called PROGMEM attribute
[18:28:14] <braincracker> you may want something like that
[18:28:17] <Horologium> Gumboot, I was thinking more like section rather than segment really...like accessing PROGMEM and EEPROM
[18:28:21] <Horologium> braincracker, yes..
[18:28:35] <braincracker> EXTMEM
[18:28:45] <Horologium> you can, kindof, define a variable as eeprom.
[18:28:52] <braincracker> so you search for those, see what they hack
[18:28:59] <Gumboot> Oh, wait... wasn't "far" used as the keyword to identify a pointer which could point to both code and data on a harvard architecture device?
[18:29:17] <Gumboot> In one compiler I can't remember the name of.
[18:29:55] <braincracker> Horologium <= after done adding the type, you write readwrite function, and you can use it
[18:30:11] <Horologium> Gumboot, no,,,harvard means separate program and address spaces.
[18:30:12] <Horologium> far pointer is to go outside your local segment....like, 256byte or whatever..
[18:30:38] <Horologium> braincracker, I know the basis of how to do it...just haven't done it yet.
[18:30:39] <Gumboot> Horologium: Exactly. They had a pointer type that included information about which instructions you had to execute to get the data.
[18:31:36] <Gumboot> If you're going to do that, you might as well write a C++ compiler.
[18:31:51] <Horologium> Gumboot, why?
[18:31:54] <Horologium> I like C
[18:32:03] <Horologium> have no need for C++ on an avr
[18:32:17] <Gumboot> No, I mean if you're going to extend your language to include your access method in your pointer structure, then you've gone off on a C++-like tangent.
[18:32:51] <braincracker> yey Badaboom
[18:33:00] <Badaboom> yey
[18:33:19] <ambro718> I couldn't stand AVR programming without C++ templates. You just can't make efficient abstractions in C.
[18:33:33] <Badaboom> hmm
[18:34:11] <ambro718> in C you're either forced to break abstraction or use function pointers
[18:34:28] <ambro718> C++ allows you to specify callbacks and such at compile time
[18:34:56] <braincracker> Badaboom <= examined very old manypin PDIP microcontroller board with 5 digit 7segment+dot display, ;/ too many pins, i'm not gonna desolder that, *grabs* screwdriver, fixes things
[18:34:58] <braincracker> :)
[18:35:17] <braincracker> it even had a maxim ic on it, that came down in 2 parts
[18:36:05] <Badaboom> lol
[18:36:32] <braincracker> the red led digits glow red even with 0.5mA, can be seen in the dark
[18:36:41] <Badaboom> wth?
[18:36:44] <Badaboom> really?
[18:36:47] <braincracker> yea
[18:36:51] <Badaboom> Interesting
[18:37:00] <Badaboom> whats the max?
[18:37:09] <braincracker> i assume 10mA/segment
[18:37:21] <Badaboom> Bright as hell?
[18:37:40] <braincracker> must be visible at daytime :)
[18:37:52] <Badaboom> Youve seen mine right?
[18:37:59] <braincracker> ye
[18:38:07] <Badaboom> It can get pretty bright
[18:38:11] <braincracker> with that ugly max ic
[18:38:21] <Badaboom> lmao 0------
[18:38:36] <Badaboom> It was designed for daylight usage
[18:38:43] <Badaboom> The display
[18:38:48] <braincracker> pwm it
[18:38:53] <braincracker> light sensor
[18:39:08] <Badaboom> I need to phase out of the 2313,, its to small for my needs i think
[18:39:20] <Badaboom> and yes ide like to pwm
[18:39:22] <braincracker> automatic brightness control
[18:39:32] <Badaboom> i have pwn running the spkr right now
[18:39:45] <Badaboom> well piezo trans we talked about
[18:40:40] <Badaboom> 4 ch pwn on the 2313,, hmm
[18:40:44] <Badaboom> pwm
[18:41:11] <Badaboom> well 4 hw
[18:41:14] <braincracker> well, 100Hz would be fine for a display
[18:41:27] <braincracker> 5 digits = 500Hz
[18:41:47] <Badaboom> Heres the thing, if i change out of the max dont i need a 595 per seg?
[18:41:49] <braincracker> not that hard ro pwm that
[18:41:52] <braincracker> to
[18:42:13] <braincracker> if you want it static
[18:42:16] <braincracker> yes
[18:42:18] <Badaboom> right
[18:42:29] <Badaboom> "camera friendly"
[18:42:36] <braincracker> just hook them up in a row, and clock in states
[18:42:48] <Badaboom> thats alot of 595s tho
[18:42:50] <braincracker> could even pwm them...
[18:42:55] <Badaboom> yeah
[18:43:03] <braincracker> 5 / 5 digit is much?
[18:43:09] <Badaboom> no i have 7
[18:43:22] <Badaboom> still
[18:43:37] <braincracker> ok, you can use 2, but you need to scan them as usual.
[18:43:45] <Badaboom> hmm
[18:43:55] <Badaboom> but i will have more control
[18:44:21] <braincracker> no.
[18:44:40] <braincracker> same, it will just lower the effective brightness and cause it to flicker
[18:45:03] <braincracker> and take CPU time even if you don't pwm it
[18:45:10] <Badaboom> i mean vs the max
[18:45:46] <Badaboom> I guess my question is, is there an advantage to using the 595's vs the max?
[18:46:03] <braincracker> yes, not having a max is always cool
[18:46:07] <Badaboom> lol
[18:46:18] <Badaboom> cyptic
[18:47:11] <braincracker> and if you want, add more 595s and you have your 1024 led string on it too
[18:47:47] <braincracker> advanced christmas lights
[18:48:02] <Badaboom> I think i will start a new projest tonight messing with the 595's and shifting
[18:49:12] <Badaboom> Its funny, i used to think of the cubes as a challenge
[18:49:29] <braincracker> void send_qword_595(uint64_t) { ...
[18:49:55] <Badaboom> 64 to send the whole string?
[18:50:02] <braincracker> 8 bytes
[18:50:12] <Badaboom> right
[18:50:17] <braincracker> or just use an array
[18:50:18] <Badaboom> 8x8
[18:50:33] <Badaboom> Yeah you mentioned that a while back
[18:50:40] <braincracker> don't tell me it is hard
[18:50:50] <Badaboom> no,, on the contrary
[18:51:55] <Badaboom> Ide rather use an array now with my expierence with the max
[18:52:09] <Badaboom> set the array as a lib?
[18:52:14] <Badaboom> .h
[18:52:22] <Horologium> just remember that putting all those LEDs on one power line, if they are all on at once it's gonna be quite a total current draw.
[18:52:35] <braincracker> :)
[18:52:42] <Badaboom> so should i add somewhere?
[18:52:59] <Badaboom> some sort of supplemental pwr?
[18:53:12] <braincracker> Horologium <= he already has it working
[18:53:22] <braincracker> with that ugly max ic
[18:53:23] <Badaboom> hmm
[18:53:29] <Badaboom> lmfao
[18:53:37] <Horologium> just thinking about that and remembering the massive power supply and wiring on an old LED sign.
[18:53:45] <braincracker> sure
[18:53:47] <Badaboom> Im gonna send u a whole box,, like choclates of max chips
[18:54:07] <braincracker> 8x10mA x 5 = 400mA
[18:54:10] <Horologium> I like maxim toys....specially the ds89c450
[18:54:21] <Badaboom> see
[18:54:49] <Badaboom> You know they have gotten really strict with there samples lately
[18:54:51] <Horologium> and max233 and these nifty little clock chips that I don't remember the number on.
[18:54:51] <braincracker> all leds lit
[18:54:54] <Horologium> oh?
[18:55:03] <Badaboom> max232:)
[18:55:06] <Horologium> I've had no problems...got some from them about a month ago or so.
[18:55:11] <Horologium> Badaboom, nono..max233
[18:55:16] <Horologium> 232 requires external caps.
[18:55:24] <Horologium> 233 has them built in..no external parts needed.
[18:55:24] <Badaboom> I have 1 max233
[18:55:29] <Badaboom> Yep
[18:55:35] <Horologium> considerably more expensive.
[18:55:37] <Badaboom> remember the days of the 4
[18:55:42] <Horologium> like 7 dollars vs 2.
[18:55:44] <Badaboom> 4 caps
[18:55:58] <Horologium> but the space savings on the board makes up for it in my one-off thingies.
[18:56:08] <Badaboom> yes
[18:56:11] <Badaboom> definitly
[18:56:28] <Badaboom> I just lied to u...
[18:56:32] <Badaboom> I have 2 ere
[18:56:35] <Badaboom> here
[18:56:44] <Horologium> I have used the max232 with huge caps to make a charge pump for building a pic programmer....needed 12V to enter programming mode..
[18:56:44] <Badaboom> max233acwp
[18:56:56] <Horologium> could use the same design for an HVPP or HVSP design for AVR too.
[18:56:58] <Badaboom> wow
[18:57:05] <Badaboom> interesting
[18:57:13] <Badaboom> so fuse fix
[18:57:19] <Horologium> yeah.
[18:57:22] <Badaboom> hmm
[18:58:04] <Badaboom> Ive had these max233's for quite some time,, maybe its time to use 1
[18:58:16] <Badaboom> then i have many 232's
[18:58:27] <Badaboom> obsolete probably
[18:59:09] <Horologium> never tried a 233 as a plain 12V boost.
[18:59:38] <braincracker> Badaboom <= :) the atmega168pa even has an internal temperature sensor on adc mux channel 8
[18:59:39] <Badaboom> is there any info on that or was that just a suggestion?
[19:00:20] <braincracker> ~1C native resolution after calibration
[19:01:02] <braincracker> just found this today
[19:01:10] <Horologium> Badaboom, on mine? or the temp sensor?
[19:01:20] <Badaboom> on the HVPP
[19:01:23] <Horologium> the temp sensor is very documented...right in the datasheet.
[19:01:31] <Horologium> oh...it was a thought...
[19:01:35] <braincracker> yeah, i just noticed now
[19:01:40] <Badaboom> lol
[19:01:48] <Badaboom> sorry,, ill address next time
[19:01:49] <Horologium> you need 12V for HVPP....why not use a nifty pre-packaged charge pump for it?
[19:02:37] <braincracker> Horologium <= or a single port
[19:02:55] <braincracker> and create a magic squarewave with it
[19:02:58] <Horologium> when I first started with PIC I needed 12V for standard programming...then they implemented ICSP but that didn't support writing fuses and you still needed 12V for that.
[19:03:31] <Horologium> braincracker, then you need a coil and cap and all that junk.
[19:03:41] <Badaboom> lc
[19:03:43] <braincracker> i see 2 methods
[19:04:16] <braincracker> "coil, diode, cap nfet/transistor junk", or few caps and diodes junk
[19:04:59] <Horologium> or just get a max chip that does it...
[19:05:01] * Horologium ducks
[19:05:06] <Badaboom> lmao
[19:05:10] * Badaboom ducks too
[19:06:36] <Horologium> but the caps and diodes method requires an alternating current, not just a pulsed DC.
[19:06:45] <Horologium> I have tried that.
[19:06:53] <braincracker> you did it wrong
[19:06:57] <Horologium> in fact, somewhere I have a 16 stage cap and diode multiplier.
[19:07:27] <braincracker> 3 stage can make 12V from 5V
[19:09:18] <braincracker> "
http://www.talkingelectronics.com/projects/50 - 555 Circuits/images/VoltageDoubler.gif"
[19:10:15] <Horologium> that one only doubles.
[19:10:24] <braincracker> well i'd say 2 doublers would do
[19:10:33] <Horologium> so, from 5V you can only get, at most 8V because of the diode loss.
[19:10:34] <braincracker> cascade them
[19:10:46] <Horologium> could use a dickinson multiplier.
[19:10:57] <Horologium> dickson multiplier
[19:11:09] <Horologium> but that requires 2 digital outputs.
[19:11:12] <Badaboom> This is what's gonna show up at brain's house one day filled with chips:)---
http://www.polyvore.com/buy_maxims_de_paris_chocolate/thing?id=15759210
[19:11:52] <braincracker> http://www.seekic.com/uploadfile/ic-circuit/200962345954533.gif
[19:12:14] <braincracker> Horologium <= ?
[19:12:19] <Horologium> http://en.wikipedia.org/wiki/File:Dickson_voltage_multiplier.svg
[19:13:23] <Horologium> I bet that's how the max232 series works.
[19:13:34] <Horologium> that and an inverted pump for the -12V
[19:13:40] <braincracker> not sure about that
[19:14:01] <braincracker> it may have 10000 transistors in it
[19:14:42] <braincracker> and high power analog multiplexers
[19:16:11] <Badaboom> Transistor Count 123
[19:16:26] <Badaboom> 202e and 232
[19:16:36] <Horologium> heck, TI even makes max232 chips.
[19:16:42] <Badaboom> Yep
[19:16:52] <Badaboom> I have some max and some ti
[19:17:39] <Horologium> and they've apparently been around since the 80s.
[19:18:14] <braincracker> Horologium <=
http://upload.wikimedia.org/wikipedia/en/1/12/Dickson_voltage_multiplier.svg < btw the phase relations are incorrect
[19:18:15] <Badaboom> Hes still pissed about the heart shaped box ..lol
[19:18:41] <Horologium> braincracker, possibly...I didn't draw it.
[19:19:06] <Horologium> it does give me ideas though.
[19:19:42] <braincracker> yes
[19:19:59] <braincracker> it 'may' work
[19:21:17] <braincracker> Horologium <= and now i was thinking about this
http://mathworld.wolfram.com/PenroseStairway.html
[19:21:18] <braincracker> :)
[19:21:54] <braincracker> all the way up
[19:22:00] <Horologium> all the way down.
[19:22:22] <Horologium> make them round and put a wall around it and you have a perpetual slinky stairway!
[19:22:52] <Badaboom> makes ya think
[19:23:00] <Horologium> not really.
[19:23:08] <Horologium> just because you can draw it doesn't mean you can build it.
[19:23:15] <Badaboom> well
[19:23:19] <Badaboom> true
[19:23:26] <Horologium> at least, not with today's human technology.
[19:24:55] <Horologium> once we invent 9 dimensional transphasic physics, then we can try building that.
[19:25:17] <Badaboom> yeah..
[19:26:00] <braincracker> http://www.moillusions.com/2008/01/yet-another-impossible-structure.html
[19:26:04] <Badaboom> I tend to think well go interdimensional before we travel thur space but thats just what i believe
[19:26:43] <braincracker> Horologium <=
http://3.bp.blogspot.com/_cxmptAPYR-s/R4rC1GiiX8I/AAAAAAAAB2A/K43vai7kowE/s1600-h/circle-sculpture.jpg
[19:26:57] <Badaboom> Now that one is making me turn my head
[19:27:22] <braincracker> http://www.99opticalillusions.com/wp-content/uploads/2012/02/Impossible-riangleIllusion.jpg
[19:27:33] <Horologium> http://www.mcescher.com/
[19:27:34] <braincracker> (these are real)
[19:27:48] <Badaboom> Its giving me spacial sickness,,
[19:28:00] <braincracker> http://scienceblogs.com/omnibrain/2007/03/05/3d-impossible-structure/
[19:28:16] <braincracker> space is flexible you know
[19:28:54] <Badaboom> I agree,, did you look at that article i sent u?
[19:29:00] <Badaboom> Kaluza Kline?
[19:29:18] <Horologium> http://www.mcescher.com/Gallery/back-bmp/LW390.jpg
[19:29:23] <Badaboom> It deals with bending space and time
[19:29:44] <Badaboom> Bringing 2 points together and traveling thru them
[19:29:53] <Horologium> http://www.mcescher.com/Gallery/back-bmp/LW389.jpg
[19:30:06] <braincracker> snake eating itself :)
[19:30:46] <Horologium> http://www.mcescher.com/Gallery/back-bmp/LW375.jpg
[19:30:54] <Horologium> that's one of my favorites
[19:31:32] <braincracker> dislike
[19:31:38] <braincracker> not colored ;/
[19:32:01] <Horologium> http://www.mcescher.com/Gallery/recogn-bmp/LW439.jpg
[19:32:15] <Horologium> and the one that really started all the twisted neverending stairs kinda pictures.
[19:32:25] <Horologium> of course they aren't colored...they were etchings.
[19:33:09] <Horologium> http://www.mcescher.com/Gallery/recogn-bmp/LW435.jpg
[19:36:35] <Horologium> Escher was a sick and twisted genius.
[19:36:46] <Horologium> I think he was on some massive drugs though.
[19:36:56] <Badaboom> http://chrisbgriz.wordpress.com/2012/08/10/kaluza-klein-theory/
[19:37:38] <Horologium> http://www.kleinbottle.com/baby_klein.htm
[19:38:38] <Badaboom> ..
[19:39:22] <Horologium> I love the klein bottle.
[19:40:02] <Horologium> it's like a 3D moebius strip.
[19:41:09] <Badaboom> so im thinking of how to write a simple code to start the process in the RGB test
[19:41:40] <Badaboom> I guess ill wire up the 595's
[19:42:13] <Badaboom> U used the max?
[19:42:18] <Badaboom> 7219 or?
[19:43:10] <Horologium> I've used shift registers in sequence before but not for driving LEDs.
[19:43:21] <Badaboom> ahh
[19:43:42] <Horologium> I don't do a lot of large quantity blinkylights though.
[19:43:47] <Badaboom> Im still trying to wrap my head aroung what im attempting
[19:43:56] <Horologium> you know how a shift register works, yes?
[19:44:00] <Horologium> two lines...clock and data.
[19:44:02] <Badaboom> I remember you saying something like that
[19:44:07] <Badaboom> yes
[19:44:09] <Tom_itx> is it like a stick shift?
[19:44:16] <Badaboom> lol
[19:44:16] <Tom_itx> manually shifting
[19:44:17] <Horologium> set data, toggle clock, set data, toggle clock, etc, ad-inifnitum.
[19:44:19] <Badaboom> Tom
[19:44:54] * Tom_itx heads back out to the shop
[19:44:56] <Horologium> Tom_itx, yea, pretty much.
[19:45:12] <Badaboom> lol
[19:46:23] <Horologium> time to watch Avatar..again.
[19:46:45] <Badaboom> I tried,, my copy is corrupt,, kinda strange u mention that
[19:46:54] <Badaboom> and i mean legal copy
[19:47:02] <Horologium> I got an extended version.
[19:47:12] <Badaboom> Thats what i have
[19:47:18] <Badaboom> Starts out on earth
[19:47:23] <Horologium> yup.
[19:47:30] <Badaboom> about fixing his spine
[19:47:49] <Badaboom> but then either my player or something is screwy
[19:47:50] <Horologium> If there is a hell you might want to go there for a little R&R after a tour on pandora.
[19:47:57] <Badaboom> lol
[19:48:23] <Badaboom> Itll chew u up and
[19:48:50] <Badaboom> See, i think a home like hometree would be cool
[19:52:10] <Horologium> I think just going to another planet would be cool.
[19:52:46] <Badaboom> Agreed,, heres a thought
[19:53:02] <Horologium> if I was single I would volunteer for a one way to mars.
[19:53:08] <Badaboom> Ever have the "" voices in the back of your head telling u things?
[19:53:15] <Horologium> me and how many million others..
[19:53:19] <Badaboom> lol
[19:53:25] <Horologium> no...they are in the front of my head.
[19:53:53] <Badaboom> Imagine if u will there from another dimension,, ppl you havent known but they know of u,, tellig u things
[19:54:06] <Horologium> first I have to imagine you speak english.
[19:54:07] <Badaboom> I read a poem with that in it,, creepy
[19:54:07] <Horologium> but,
[19:54:26] <Badaboom> ??
[19:54:41] <Horologium> "u" is not a valid word in the english language.
[19:54:57] <Horologium> and you used "there" where it should be "they're"
[19:54:58] <Badaboom> ...nm
[19:55:19] <Horologium> but, I'm a bastard.
[20:05:08] <Horologium> that double rotor helo looks like it would be fun to fly..
[20:05:50] <Badaboom> Don't yop<- Mean Helicopter?
[20:06:14] <Horologium> the aircraft on Avatar
[20:06:32] <Badaboom> lmao I had to do that
[20:07:15] <Badaboom> I think a guy by the name of mollar attempted a hovercraft to that effect
[20:07:23] <Badaboom> maybe it's molar
[20:07:51] <Horologium> the CGI in this movie is awesome too.
[20:12:48] <Badaboom> bbl
[23:00:11] <Badaboom> sigh, the 2313 only has 2 external int pins
[23:01:20] <Badaboom> or any of the PCINT7..0 pins. hm
