Back
[02:13:11] <buhman> I'm attempting to figure out these output compare registers; what I'm particularly interested in is a table in the datasheet that shows me what output compare registers map to which pin
[02:13:23] <buhman> all I can find on the matter is "A match can be used to generate an Output Compare interrupt, or to
[02:13:37] <buhman> generate a waveform output on the OCnx pin."
[02:14:39] <buhman> somehow, I don't understand the "OCnx pin" part of that
[02:15:46] <buhman> I see on my hardware's pinout, for example, "PD7 (OC2A/PCINT31)", perhaps that's what it's talking about?
[02:27:55] <specing> Sherlock.
[03:34:35] <Casper> !seen rikusw
[03:34:35] <tobbor> RikusW was last seen in #avr on Apr 30 07:02 2012
[05:30:01] <inflex> oh feckity feck... damned USB socket has ripped from this PCB... and the one track that is torn off is the V+ track... uggggrhgh
[05:30:15] <inflex> (and there's no immediately visible point I can link to
[05:33:17] <inflex> yay for highres cameras with macro!
[05:34:24] <inflex> http://dxp.me/i/usb1.jpg
[05:44:54] <OndraSter> how did you do that :o)
[05:45:25] <OndraSter> V+ is not that big of a deal, it will be either connected to some LDO or if the device runs at 5V, to any power pin :)
[06:13:08] <Kevin`> inflex: v+ or d+?
[06:13:39] <Kevin`> inflex: you could link to the resistor immediately connected to the pad easily enough
[06:14:03] <inflex> Kevin`: it's V+
[06:14:05] <inflex> anyhow, fixed now
[06:14:44] <inflex> now comes the REALLY hard bit... reassembling it
[06:17:20] <inflex> mmmm... might have to touch it up a tiny bit more -
http://dxp.me/i/usb2.jpg
[06:18:11] <inflex> the ID pin might not quite be soldered enough
[06:18:33] <grummund> "ripped from this PCB..." Eek! :-O
[06:19:37] <Kevin`> inflex: you are going to add some sort of glue to hold the thing down after you clean it right?
[06:20:16] <mrfrenzy> what kind of camera setup is that inflex ?
[06:21:39] <inflex> just a Fujifilm S5700
[06:21:46] <inflex> Kevin`: yes, used a few drops of CA
[06:54:42] <OndraSter> who has broken it, inflex ?
[06:54:49] <OndraSter> it looks just baaaad
[06:57:40] <inflex> OndraSter: repair for someone else - their dogs got tangled up in the leads
[06:57:47] <OndraSter> :o)
[06:58:43] <inflex> whatI really hate about this thing is that the data is actually stored in a virtual-drive system
[06:59:10] <inflex> so you have to rely on the built in board to do all the decoding ... which means you can't just pull it off like with normal enclosures
[06:59:29] <inflex> and it's so fecking slow
[06:59:46] <OndraSter> you could always buy another one and swap the chips/whatever
[06:59:49] <OndraSter> is it some flash drive?
[07:00:09] <inflex> no, it's a 1TB WD "My Book Elite" storage unit
[07:00:40] <OndraSter> oh
[07:03:37] * inflex really needs to get a 3~10TB storage rack
[07:03:50] <inflex> so many customer systems I work on have dying drives and I need to store images of them
[07:08:51] <inflex> what's scary is that the data is all encrypted on the HDD, so even if you pull the drive out, you cannot decodeit
[07:12:26] <specing> Haha
[07:19:00] <specing> And WD probably has a backdoor built in
[07:19:16] <specing> So the encryption feature is pretty much useless ;)
[07:19:41] <Tom_itx> ask flyback about hdd recovery
[07:20:47] <inflex> data is being pulled off atm
[07:22:55] <Grievre> What is the advantage of using a harvard arch?
[07:25:53] <Tom_itx> you get along better with ppl from harvard?
[07:26:03] <specing> Haha ;)
[07:26:32] <inflex> lolz
[07:26:50] <Tom_itx> it's like any other standard, you say you're gonna do it this way and i'll say i'm gonna do it another.
[07:27:10] <Tom_itx> both can blink an led
[07:28:08] <Tom_itx> there may be an advantage but i dunno what it is
[07:30:27] <OndraSter> it is easier to test the code, you don't need to flash it, just upload to RAM and jump on the beginning
[07:30:46] <CapnKernel> Dubious advantage: If you have a 16-bit pointers (but you don't have paging), you effectively double the address space, because with a von Neumann architecture, both the instructions and data must be mapped into the same address space.
[07:30:57] <OndraSter> I wish AVRs had JvN option... flash would move to memory space as well
[07:31:22] <OndraSter> with xmegas having 24bit addressing I say it wouldn't be that bad
[07:31:24] <CapnKernel> Is that airborne pork I see?
[07:33:33] <grummund> yes
[09:02:44] <rue_house> Grievre, I keep telling people to use hardeware state machines but they just dont wanna do it
[09:04:48] <rue_house> part of the reason I prefer avrs over pics is the flat memory,
[09:04:57] <rue_house> and the lack of a /4 on the cpu clock
[09:05:03] <rue_house> and the open source dev tools
[09:06:13] <specing> and a larger community
[09:06:32] <specing> and a more active IRC channel
[09:06:34] <rue_house> and consistant programmer standards
[09:06:41] <specing> and the list goes on and on and on...
[09:06:50] <inflex> yep
[09:06:52] * rue_house hugs his parallel port pogrammer
[09:06:54] <inflex> and portability
[09:06:58] <grummund> AVR has consistant programmer standards?
[09:07:04] <inflex> oh yes, the 3-resistor AVR //port programmer is awesome
[09:07:33] <rue_house> grummund, PICs do non-backwards compatible programming method changes
[09:07:55] <rue_house> and the programming algs aren't open, so you have to buy a new programmer from them every time
[09:08:23] <grummund> atmel hides (some of) the programmer standard
[09:08:41] <rue_house> most PIC programmers dont care, they only paid $200 for a compiler and another $50 or so for another programmer is just part of the fun
[09:09:38] <grummund> yep and in the commercial world it's the same for avr
[09:09:38] <rue_house> I'm interested to see where the MSP stuff goes
[09:10:26] <inflex> yes, I'd love to se the MSP430 devtool stack become as common as the AVR one for linux
[09:17:54] <asteve> i'm more of a fan of avrs then msp430s
[09:19:00] <asteve> and by then i mean than
[09:19:36] <grummund> what's the gcc support like? it seemed pretty sparse when i looked a few years ago.
[09:27:35] <ziph> Huh? The MSP430 GCC was always superior to AVR GCC in many ways.
[09:31:10] <ziph> Full gdb source level debugging with the programmer interface built in for starters.
[09:31:20] <grummund> i never tried it but was judging from [in]activity on the mailing list
[12:19:57] * RikusW is trying out the lynx browser :'|
[12:20:54] <RikusW> at least the pages load faster
[12:21:56] <Steffanx> lol
[12:22:39] <RikusW> but seems it breaks a lot of stuff :(
[12:22:55] <RikusW> its like 15kb for RS home instead of 400kb
[12:23:19] <RikusW> and my connection seems extra slow tonight...
[12:23:29] <RikusW> or maybe the rs server
[12:23:56] <RikusW> anyone here used lynx before ?
[12:32:28] <RikusW> seems like there is an unbelievable amount of crap data embedded in webpages these days....
[12:33:06] <mrfrenzy> flashblock usually helps
[12:33:30] <RikusW> even in the html itself
[12:33:37] <Steffanx> That too, but no one cares about it..
[12:33:52] <OndraSter> gzip :)
[12:33:52] <RikusW> website design gone down the drain with fast connections...
[12:33:58] <Steffanx> Except you
[12:34:12] <RikusW> yeah :|
[12:34:25] <RikusW> even my brother got a 1MBit line
[12:34:30] <RikusW> soon to be 4MBit
[13:02:36] <specing> RIKUSW!?!
[13:02:42] <specing> Meh he left again :/
[13:14:19] <Steffanx> poor specing
[13:16:08] <Tom_itx> yeah and you're just not good enough
[13:16:31] <Tom_itx> funny, i must not be either...
[13:17:05] <Tom_itx> i should go wire up my stepper drive
[13:20:35] <Steffanx> Have fun Tom_itx
[13:20:46] <Tom_itx> i got the hv side wired last night
[13:20:54] <Tom_itx> need the signals and the psu next
[13:21:03] <Tom_itx> waiting for my cap boards so i can finish the psu
[13:21:19] <Tom_itx> did you see it?
[13:21:27] <Steffanx> I think i didn't
[13:21:30] <Steffanx> see it
[13:22:25] <Tom_itx> i found some nice heatsink at the scrap yard for the drivers
[13:22:44] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/cnc/psu/psu_index.php
[13:52:23] <nofxxx> Tom_itx, how many amps to feed it?
[13:55:34] <Tom_itx> i dunno
[13:56:25] <Tom_itx> it's overkill for the app but they were surplus
[14:00:36] <nofxxx> Tom_itx, nice. Pardon my ignorance, but can a switched supply run it? a cnc/3d printer/step motors thing
[14:00:47] <Tom_itx> yes
[14:01:26] <Tom_itx> http://www.kelinginc.net/SwitchingPowerSupply.html
[14:02:02] <Tom_itx> or one of those big fat torroids
[14:02:45] <Tom_itx> the idea is to get the voltage up on the steppers and use a current limiting driver
[14:03:09] <Tom_itx> improves torque at higher speeds
[14:03:54] <Tom_itx> and with these drivers i'll be able to rewire the steppers in parallel mode for even better performance
[14:04:03] <Tom_itx> it remains to be seen how much
[14:05:07] <Tom_itx> you would need minimal steppers for a printer
[14:05:18] <Tom_itx> nema 17 i think is what most use
[14:05:49] <Tom_itx> i need more power on my mill though since it's under alot more load
[14:06:25] <Tom_itx> i've got the 3 original steppers and drivers from it that i could make a printer with
[14:24:59] <Essobi> sup
[14:31:01] <_abc_> is there a neat way to implement arithmetic right shifting of integers in C ?
[14:31:15] <_abc_> I mean -8>>1 -> -4
[14:31:27] <_abc_> This implies sign extension tricks.
[14:32:38] <specing> int8_t i; i = -8; i >> 1; and see what it generates ;)
[21:24:03] <inflex> oh fgecking damnit
[21:24:14] <inflex> why does the new toolchain break on _delay_ms(100) etc
[21:53:13] <inflex> Anyone have a sane fix for - /usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:153:28: error: __builtin_avr_delay_cycles expects an integer constant.
[21:53:32] <inflex> I've got #define F_CPU 8000000UL so I'm confused to say the least
[21:53:56] <inflex> and this is code that -used- to work about 3 months ago and I've not touched it since, only the compiler/gcc has changed
[22:29:18] <inflex> *ping*
[22:31:01] <Casper> *pong*
[22:32:34] <Tom_itx> *poing*
[22:32:40] <clever> *bing*
[22:33:03] <inflex> *sigh* so no one can help me with my issue :(
[22:34:05] <inflex> avr-gcc 4.5.3
[22:35:12] <Tom_itx> did they change the delay routine?
[22:36:03] <inflex> just seems if I try to use _delay_ms(100); or even _delay_ms(x); // uint32_t x it just keeps on failing
[22:37:04] <inflex> One of those "this just should not be broken" things
[22:37:19] <inflex> as mentioned, worked fine with avr-gcc from 3 months ago when I last compiled it :(
[22:38:10] <inflex> As annoying as cramming in some firmware down to the last byte, then the next version makes it a few bytes later :(
[22:38:11] <inflex> large
[22:38:15] <inflex> larger even... *sigh*
