Back
[00:04:03] <inflex> right, two more PCBs arrived
[00:04:11] <inflex> this time the precious LOM main boards
[00:24:45] <ziph> Are you on a nickname basis with the GP guy yet? :)
[00:25:03] <inflex> pffft... just "shane" :p
[00:25:16] <inflex> http://static.rcgroups.net/forums/attachments/2/4/1/8/1/a4436284-82-picDSCF0102.JPG <=- came out nice enough
[00:25:39] <inflex> hoping that the 'fully walled' shielding approach doesn't make things any worse though on the noise level
[00:27:25] <inflex> well, will build that tonight problem... sheesh, another $80 of parts or so I suppose *bleah*
[00:27:53] <ziph> What's the pad under the IC for?
[00:27:57] <inflex> will actually have bidirectional serial on this one, though don't know if I'm going to have any luck using it
[00:28:12] <inflex> the one with 9 holes?
[00:28:16] <ziph> Yeah.
[00:28:36] <inflex> just goes through to the groundplane on the other side and feeds off a star connection to the GND terminal
[00:29:21] <inflex> trying very hard not to have any notable voltage gradients across that section of copper
[00:30:58] <inflex> ( about 50mA flows through
[00:31:38] <inflex> I might put a pin through on the TO220 GND hole to act as the stronger/lower-resistance feed-through
[00:38:02] <inflex> anyhow, will attack that tonight
[00:38:53] <Casper> it's sad that copper have such high resistance isn't it? :D
[00:39:30] <inflex> only when it's reallly thing ;)
[00:39:37] <inflex> thin
[00:40:07] <inflex> really hope to hell that this is the last notable revision, costing me a fortune to keep building new boards
[00:40:13] <inflex> those 24-bit ADCs aren't so cheap
[00:40:29] <inflex> sure, a lot cheaper than 10 years ago... but still expensive
[00:40:39] <inflex> then there's all the fittings/connectors
[00:40:59] <inflex> and maybe, just maybe this time around, the $$$$ 0.01% TO220 resistor
[01:11:19] <earthshine> Morning
[01:12:26] <inflex> hi
[01:12:38] * inflex ponders a 10 sample window for compression
[01:15:52] <soul-d> what you making today inflex ?
[01:16:35] <inflex> soul-d: just trying to work out how to maximise the storage of my data into an EEPROM
[01:19:37] <soul-d> ok so working on data compression what kind of datastream ?
[01:20:03] <inflex> easier ifI show you a pic
[01:20:38] <inflex> http://dxp.me/i/servo-smps.png
[01:20:38] <soul-d> probably just woke up kickstarting with coffee ;)
[01:21:02] <inflex> the red one is the killer, since it's too wild to use deltas with
[01:21:44] <inflex> I can eliminate the purple, since it's just an incrementing (seconds) tick, so I've packed that in with the blue (volts)
[01:21:57] <inflex> the green I can get away with deltas for the most part
[01:22:28] <inflex> but that's not really compression as such...
[01:22:41] <inflex> so, I was thinking I can store about 128 bytes of data and try compress those
[01:22:56] <soul-d> what are the names of axis and red and green are adc ?
[01:24:36] <inflex> but I'm having trouble finding small dataset compression algorithms
[01:24:55] <inflex> red is current, in 10mA steps, so, 60 = 600mA
[01:25:06] <inflex> blue is volts in 0.1V steps, so 60 = 6.0V
[01:25:27] <inflex> green doesn't really matter, it's just clock-ticks (pulse width), but essentially it's without needing a base
[01:26:01] <inflex> I did come up last night with the idea that I can reduce the range for V by setting the base level to 30 or 40 (because that's as low as the system will go)
[01:26:12] <inflex> but in the end, yes, current (red) is the killer, because it just won't sit still
[01:27:17] <soul-d> so name of image could be "servo feedback"?
[01:27:42] <inflex> well, it's really servo power rails current/voltage
[01:28:25] <inflex> at an extreme push,. I could probably get away with dropping the pulse-width, since it's only for correlations ... maybe drop its range down to 0~64
[01:29:25] <inflex> so you end up with pulse { 0, 64 }, volts { 40, 72 }, current {0, 255}
[01:30:52] <inflex> so you have 6, 5 and 8 bits, which doesn't quite fit into 2 bytes - so hence, my idea to go with storing ~128 bytes of cumulated data, compress it, then store
[01:31:20] <inflex> you actually could get away with slightly lossy compression
[01:38:36] <soul-d> intresting not that i know much yet on it except i might need it in near future
[01:39:19] <inflex> am thinking that perhaps I should treat the current stream entirely separately and just bitpack/delta the other streams
[01:40:33] <soul-d> and the voltage stays constant ? i see 1 small peak
[01:40:38] <inflex> it wiggles around
[01:40:40] <soul-d> so why storing that
[01:41:01] <inflex> just on my test it doesn't show up as much - but in real life, it moves up/down with the current
[01:41:20] <inflex> http://dxp.me/i/ss2.png <=- wiggles a fair bit more here
[01:41:48] <inflex> and it gets worse on other setups, can expect anything from 3.3V ~ 7.5V swings
[01:43:45] <inflex> hrmm.. have 512 bytes of RAM I can use, 128 for sure iwll be used by the stack/vars... so maybe I can store 64 samples each of volts, pulse, current... leaving me with 196 bytes of scratch to compress
[01:44:04] <soul-d> ok yeah makes more sense
[01:44:20] <inflex> but still have to come up with the compression algorithm :)
[01:44:28] <inflex> RLE won't be a lot of use
[01:45:26] <ziph> What if you use a maximum of last N entries filter?
[01:47:22] <inflex> ziph: not sure what you mean - sorry. I was actually just thinking of using back-reference linking
[01:47:38] <inflex> eg, if a value matches a previous one, backreference it
[01:47:53] <inflex> trouble is, these are all sucking up a lot of CPU time
[01:48:11] <ziph> inflex: as in y(t) = max(x(t), x(t - 1), x(t - 2), x(t - 3))
[01:49:08] <inflex> sort of a digital filter, picking out peak values in a sliding window?
[01:50:39] <ziph> Yeah.
[01:50:57] <ziph> Try it on your gnuplot data...
[03:08:38] <inflex> hrmm... how odd... I was silly enough to have my buzzer control line on a programming pin - but it's interesting, the noise it makes is "louder" (in perception) than when I try to maximise the loudness of the buzzer myself
[03:10:31] <inflex> the big difference is that the data stream is a lot more random than my "clean" pulse
[03:11:17] <ziph> :)
[03:21:12] <inflex> right, that's the servo pulse lost-model alarm part sorted out
[03:29:47] <inflex> hrmm.. still cannot emulate the damned noise
[03:39:02] <inflex> gone for a space-invader attack sound now for the moment
[03:39:04] <inflex> pew pew pew
[03:39:48] <Tugge> Hello everyone. I'm building RS-232 analyzer using AtMega324A controller. Programming is done via JTAG ICE MKII. Now i'm stuck here. I have four leds connect to PORTA[3:0] and for some reason my controller resets itself. Now my program is here:
http://pastebin.com/GS90E1FL
[03:40:09] <inflex> unhandled interrupt?
[03:41:25] <Tugge> I don't have any interrupts here.
[03:41:52] <Tugge> Fuse bytes seems to be right.
[03:42:35] <Tugge> JTAGEN programmed adn SUT_CKSEL = Ext crystal Osc 8,0- MHz
[03:43:31] <Tom_itx> pullup on reset?
[03:44:12] <Tugge> Yes. 10k resistor and oscilloscope shows that, reset & Vcc lines are nicely in +5V
[03:45:03] <Tugge> I've been playing with AVRs quite a lot, but this is first time that this kind of error occures.
[03:45:20] <Tom_itx> try a different chip
[03:45:25] <inflex> yeah, well right now I'm wondering wth my buzzer is so damned weak... am thinking MOSFET isn't turning on right :(
[03:45:30] <Tom_itx> not likely it but...
[03:45:43] <inflex> but when the unit is -programming- it gets the full 5V
[03:45:53] <Tugge> Argh.. It's SMD chip so it's not nice to change :D
[03:46:00] <Tom_itx> oh
[03:46:02] <inflex> (where's it only gets ~3.6V with the AVR directly)
[03:47:23] <ziph> What FET?
[03:47:51] <inflex> well, it's a FDN337 atm... but about to change to a PVM31XN
[03:48:20] <ziph> Tom_itx: Seen
http://www.forbes.com/special-report/2011/migration.html ?
[03:48:21] <RikusW> Tugge: what is the E H L fuse hex values ?
[03:49:58] <RikusW> Tugge: and do you have a proper crystal connected with 18pF caps ?
[03:51:25] <RikusW> Tugge: it might be brownout detect or WDT
[03:54:43] <Tugge> RikusW: Fuses: E = 0xFF, H = 0xB9, L = 0xDE. Brown-out detection disabled
[03:55:22] <Tugge> I think, the crystal is fine because if I change fuses to internal 128 kHz osc. it does the same thing.
[03:56:54] <RikusW> Tugge: I'd suggest setting H = 0x99, for SPIEN
[03:57:01] <RikusW> why did you disable SPI ?
[03:58:50] <RikusW> You gain nothing except potential for trouble
[04:00:05] <Tugge> RikusW: Just for making sure, that ISP is not making the reset.
[04:00:29] <RikusW> I can't see how thats possible
[04:01:03] <RikusW> You've tried single stepping through code on the m324a ?
[04:02:36] <RikusW> Tugge: using AVRStudio ?
[04:03:19] <RikusW> only other thing I can think of is you defined the wrong AVR.
[04:05:59] <Tugge> I'm using AVR Studio 4.19. The chip is this one:
http://fi.farnell.com/atmel/atmega324a-au/mcu-8bit-avr-32k-flash-44tqfp/dp/1841608?Ntt=1841608 And in Project -> config. options I've defined device to atmega324a
[04:07:58] <Tugge> When I start debugging via JTAG and when I press F5 I get these messages: JTAGICE mkII: Target has entered sleep mode.
[04:07:58] <Tugge> JTAGICE mkII: Target has left sleep mode.
[04:08:31] <Tugge> So is it possible that my device some how goes to sleep mode??
[04:08:43] <grummund> Tugge: you can inspect MCUSR to determine cause of reset
[04:09:07] <Tugge> Hmm.. How?
[04:09:19] <RikusW> using the mkII
[04:09:31] <RikusW> and the registers pane in debug mode in AS4
[04:09:42] <grummund> or just capture the register at startup and display it on the LEDs
[04:10:17] <grummund> also, does the reset happen without the JTAG connected?
[04:11:22] <Tugge> Yes it happens.. Connecting or disconnecting the JTAG cable doesn't effect it at all
[04:12:03] <grummund> maybe WDT reset?.... anyway MCUSR will tell you.
[04:13:41] <RikusW> Tugge: what do you have connected to the reset line ?
[04:14:46] <RikusW> and how about the power supply ?
[04:17:15] <Tugge> Reset line is simply pulled up via 10k resistor. And then ofcourse JTAG-connectors nSRST is there also
[04:19:11] <grummund> what's the nature of the reset? does it happen fixed time after power-on, or what?
[04:26:57] <Tugge> Hmm... Very very intresting.. I started to debug that MCUSR register and All those reset flags were up?? So I clicked them off and restarted debugging, but it didn't help. Then I started from start. Un plugged my analyzer from USB-port (which powers my board) and connected the JTAG cable and started debugging and IT WORKS now..
[04:28:04] <RikusW> how do you connect to rs232 ? using max232 ?
[04:28:24] <Tugge> Could it be that those reset flags doesn't clear if you don't cut the power off?
[04:29:09] <Tugge> I have ST232 for RS_232 converter.
[04:29:54] <RikusW> those are only to indicate reset source
[04:30:11] <RikusW> how about grounding issues ?
[04:30:26] <RikusW> ground currents ?
[04:34:40] <Tugge> Not likely. Currents are so small in my board and pour copper is connected to ground.
[04:38:32] <grummund> personally i'd try to solve this with the JTAG disconnected, one less thing to worry about.
[04:39:05] <grummund> what's the behaviour of the reset? does it happen fixed time after power-on, randomly, or what?
[05:03:06] <rue_bed> inflex, pluck a stretched spring
[05:23:34] <inflex> okay I'm going insane here... something I've done is just weird....
[05:23:51] <inflex> error: __builtin_avr_delay_cycles expects an integer constant. for _delay_ms(100);
[05:24:33] <ziph> That's what you get for putting #define 100 3.141592654 in a header file. ;)
[05:24:43] <inflex> hahaha, if only, that's whatI was thinking at first too
[05:24:50] <inflex> but it's for all the_delay_ms() calls
[05:24:55] <inflex> and all different numbers
[05:25:11] <ziph> Got a weird clock frequency?
[05:25:26] <inflex> no... this is from my old LOM8 code... which I just tried and it also now fails the compile
[05:25:27] <inflex> O_o
[05:25:53] <inflex> yep, they're all doing it
[05:27:24] <inflex> she's looking sexy and simple now..
http://dxp.me/i/lom14.jpg
[05:27:53] <ziph> You should print that on a transparency and put it over glass. ;)
[05:28:17] <inflex> heh, easier to just do it in software:D
[05:28:19] <ziph> What's that serial header?
[05:28:35] <inflex> how do you mean? as in what make/model is theconnector or what?
[05:28:40] <ziph> Yeah.
[05:28:55] <inflex> something crass and cheap that I bought 1000 of a few years ago at Soanarplus
[05:29:00] <inflex> KK connectors I think
[05:29:00] <ziph> Ahh.
[05:29:09] <ziph> I hate finding connectors.
[05:29:34] <inflex> I know :(
[05:30:15] <inflex> they're not even branded, they're just 0.1" locking polarized headers
[05:30:20] <inflex> Jaycar sells them too
[05:31:05] * inflex wonders wtf is going on with _delay_ms()
[05:31:13] <ziph> Yeah, they have a few good ones, but I wanted something that I could source easily in the event they get bored of selling them.
[05:31:16] <inflex> waiting for my apt-get updates to finish, hopefully that'll clear it
[05:31:24] <inflex> yeah, they're profoundly generic
[05:31:42] <ziph> inflex: What's the definition of _delay_ms in your version of avr-libc?
[05:32:53] <inflex> looking at the file now
[05:33:44] <inflex> static inline void _delay_ms(double __ms) __attribute__((always_inline));
[05:33:48] <inflex> wtf? double?
[05:34:54] <inflex> mmm.. seems it's always been that
[05:35:11] <karlp> mmm, doubles.
[05:35:17] <karlp> doubles that aren't
[05:35:55] <ziph> inflex: Umm, I would've expected that error from a macro, not an inline.
[05:37:23] <inflex> ugh, well, to be honest, I find a lot of these files quite convoulted... and I've been doing C for 25 years!!!
[05:39:31] <inflex> worst case scenario, I reinstall avr-gcc/libc
[05:39:50] <inflex> I don't normally use _delay_ms() because it frequently blows out to a silly size
[05:40:03] <inflex> and now it's blown up in my face... that'll learn me
[05:40:54] <ziph> inflex: Declare your own _delay_ms and look at the error.
[05:41:07] <ziph> inflex: That'll tell you if it is a macro or not.
[05:42:50] <inflex> /usr/lib/gcc/avr/4.5.3/../../../avr/include/util/delay.h:133:1: note: previous definition of ‘_delay_ms’ was here
[05:43:32] <inflex> yep well, this is all very curious isn't it
[05:43:48] <ziph> Yeap, it really is a function.
[05:44:02] <inflex> F_CPU and F_OSC are defined too
[05:44:16] <ziph> Before the AVR headers?
[05:44:21] <inflex> yep
[05:44:36] <ziph> Make a copy of _delay_ms called _my_delay_ms and call it?
[05:44:59] <ziph> (A non static inline one so that perhaps you'll get better line numbers from the error).
[05:46:35] <inflex> hrmm... wrapped it and called it... still wants an int constant... very odd
[05:47:02] <inflex> to me, it's more like when delay_ms() is compiled it's missing something within its own internals that tells it how many cycles to delay
[05:47:47] * inflex wonders what else could be fubar'd
[05:48:05] <inflex> I take it no one else here is having the same issue
[05:48:47] <ziph> People on The Google are.
[05:51:34] <inflex> it's not the compile flags either... removed them all, still the same
[05:52:48] <inflex> screw this, doing it the usual fix way... make my own 1ms delay :(
[05:53:51] <inflex> now, how to chew up 8000 cycles
[05:55:15] <inflex> and there you go... as usual, everything now works great
[06:16:15] <inflex> hrmm... something _VERY_ odd is going on... now my programming (avrdude) speeds are back to the old slow rates O_o
[06:17:08] <RikusW> using which programmer ?
[06:17:17] <inflex> usbtiny
[06:17:39] <inflex> but you see, the issue here is that... I've been using them for a long time... and not had this trouble until now
[06:17:52] <RikusW> didn't the sck frequency somehow change ?
[06:17:59] <inflex> nope, sitting at 3
[06:18:52] <RikusW> 3 ?
[06:19:05] <inflex> sorr, that's the bit-delay via -B
[06:19:24] <RikusW> ah
[06:19:47] <RikusW> try -B 2 ?
[06:21:06] <inflex> it's just ODD because everything has now started going crazy on me.... and I've been using this workstation for a long time now
[06:21:41] * RikusW know the feeling :S
[06:21:56] <RikusW> sometimes things just go weird
[06:24:06] <karlp> step away from the computer, turn it off, and get a beer.
[06:24:15] <karlp> it will all magically work again tomorrow
[06:25:27] <inflex> aww... have no beer:(
[06:29:11] <karlp> then you're doomed to failure!
[06:32:21] * inflex wonders if a reboot would work, new kernel and all...
[06:40:34] <inflex> okay, going to my backup station to see if it works!
[07:08:57] <inflex> something is mangled on this machine
[07:09:03] <inflex> the backup station works fine
[08:36:57] <roxlu> hi!
[08:37:04] <inflex> struth, this channel actually has life
[08:37:13] <roxlu> does someone knows a good/simple AVR, attiny 2313 programmer board? (or proto board0
[08:37:47] <inflex> well, the 2313 is quite a limited chip - but there's a lot of AVR ISP programmers built using it
[08:39:06] <inflex> but I'm not sure if there are any prototyping/development boards for it
[08:39:13] <inflex> (other than putting one into a breadboard :)
[09:34:59] <rue_house> I wonder if the babayboard II works with that
[09:35:40] <rue_house> I think the babyboard II was designed for a tiny26
[09:35:55] <rue_house> !assist avr
[09:35:55] <tobbor> Possibly
http://eds.dyndns.org/~ircjunk/avr
[09:38:50] <rue_house> wow, I didnt' even take a pic of the II
[09:43:42] <_Shurik_> Hola
[09:45:48] <rue_house> hi
[09:45:48] <tobbor> hi rue_house.
[09:47:58] <_Shurik_> Just got a bluetooth module from DealExtreme to play with over the weekend. Should be fun
[09:52:32] <rue_house> cool
[10:25:06] <ru^2> hi
[10:25:29] <ru^2> one I/O pin on my atmega seems to be blocked to low level (I measure ~0.70v instead of 5v ), does that can means the pin is dead ??
[10:54:35] <grummund> ru^2: even with reset pin held low?
[13:00:00] <RikusW> Steffanx: flash writing just worked on m32u2 :) :)
[13:00:05] <Steffanx> :)
[13:00:09] <RikusW> wrong parameters from the config file...
[13:00:26] <RikusW> for CMD_PROGRAM_FLASH_ISP
[13:00:33] <RikusW> don't know how that happened
[13:00:47] <RikusW> will check the AS4 xml....
[13:01:21] <RikusW> Guess I'll have to have a carefull look at all of those parameters, maybe some automatic checking
[13:01:35] <RikusW> especially for the mode byte
[13:05:06] <ChrisSc> hi all
[13:05:32] <ChrisSc> need some help with a fairly easy program, 16bit*16bit
[13:05:32] <ChrisSc> http://pastebin.com/54kn8Rkc
[13:05:50] <ChrisSc> woks fine in simulator, but cpu seems not to execute the last ADD
[13:05:57] <ChrisSc> why?
[13:11:02] <RikusW> there is no jumps, so I can't see a problem
[13:11:14] <RikusW> whats with all the ST x+, R29 at the top ?
[13:11:52] <ChrisSc> i need to store "0" to all adresses after the first 4
[13:12:08] <ChrisSc> 4 bytes for mul, 12 bytes set to 0
[13:12:35] <ChrisSc> its inline assambler on a smartcard running SOSSE
[13:14:37] <RikusW> ChrisSc: go get appnote AVR200 from atmel.com
[13:14:44] <RikusW> and the source zip too
[13:14:51] <RikusW> 16 bit multiply routines
[13:15:43] <RikusW> http://www.atmel.com/dyn/resources/prod_documents/doc0936.pdf should work
[13:15:52] <RikusW> you'll have to search for AVR200.zip
[13:16:02] <ChrisSc> thx, but need to have an own solution
[13:16:37] <RikusW> http://www.atmel.com/dyn/resources/prod_documents/AVR200.zip
[13:16:38] <ChrisSc> i just son't understand why it works within the simulator, but not on the chip
[13:16:45] <RikusW> hmm
[13:16:54] <RikusW> do you have a jtagice ?
[13:16:57] <RikusW> or dragon ?
[13:17:04] <RikusW> what avr do you use ?
[13:17:32] <ChrisSc> atmega163 smartcard
[13:17:51] <ChrisSc> no inline debugging....
[13:18:01] <ChrisSc> just input -> ... -> output
[13:18:09] <RikusW> do you have other debuggable avrs to test the code on ?
[13:18:21] <RikusW> mega163 os quite old...
[13:18:24] <RikusW> *is
[13:18:56] <ChrisSc> and MUL of 0x0101 * 0x0101 gives 0x00000201
[13:19:07] <ChrisSc> no, sry
[13:19:23] <ChrisSc> i know, but its not my hardware
[13:24:32] <RikusW> Steffanx: got my bug -> AVR068 -> Note: Only bit 0-6 are set in the XML file, because bit 7 is not constant and must be controlled by the PC software.
[13:24:38] <RikusW> The page write bit....
[13:24:46] <RikusW> that explains a lot :S
[13:24:58] <ChrisSc> got the error with some helf of the guys from ##asm
[13:25:04] <ChrisSc> forgot to clear r8
[13:26:42] <RikusW> the little things cause much trouble....
[13:27:13] <ChrisSc> yeah
[13:29:14] <RikusW> hi vectory
[14:08:37] <tlvb> Tell me if I'm wrong here, running at 20MHz and a timer configured to generate an overflow interrupt every 4000 cycles and having a variable update every 5000'th interrupt should yield a one second delay between updates, right?
[14:10:14] <digi001> HI! i need some help breaking up a 32bit float into two 16 bit words to send to another processor, then when i get the data back. assemble the 2 16bit words into a float again
[14:10:21] <digi001> can anyone provide a suggestion how to do this?
[14:10:36] <tlvb> bit masking and shifting
[14:11:37] <tlvb> h16 = x32>>16; l16=x32&0xffff
[14:11:57] <digi001> awesome thanks!
[14:12:26] <tlvb> assembling would be x32 = (h16<<16) | l16
[14:13:18] <digi001> 20Mhz / 4000 = 5kHz interrupt
[14:13:27] <digi001> 5kHz / 5000 = yes equals 1
[14:13:31] <digi001> per second
[14:13:39] <digi001> sounds right to me
[14:13:41] <tlvb> my conclusions too
[14:13:44] <digi001> not working?
[14:13:47] <tlvb> nope
[14:13:55] <tlvb> it's more like two seconds per update
[14:14:42] <tlvb> I would suspect that it is programmed to run at the internal 8MHz resonator, but the fuse bits check out
[14:15:22] <digi001> you check like the system clocl oscilator divides?
[14:15:30] <digi001> and multiplies
[14:15:43] <digi001> are you able to scope out the system clock output pin to verify 20mhz?
[14:16:03] <tlvb> I guess I could enable the clko pin
[14:16:11] <tlvb> depending on what it is connected to...
[14:29:19] <tlvb> hm, the output clock, averaged over 10 cycles says 20MHz
[14:32:25] <digi001> averaged over 10 cycles"?
[14:32:36] <digi001> what is the period between pulses?
[14:34:08] <tlvb> about 50ns, I measured over 10 pulses to get a good average value
[14:36:43] <digi001> ok. but i dont think you need an average value when it comes to a system clock. it should be exactly 1/20Mhz every single time or else u have problems
[14:37:51] <devilsadvocate> digi001: real life rarely works like that
[14:38:10] <devilsadvocate> of course, most instruments commonly avaiable wouldnt know the difference
[14:38:55] <digi001> u would be suprised how accurate digital electronics are these days. 20ppm
[14:39:55] <devilsadvocate> digi001: you do realize that the fact that you're giving me the 1-sigma value of error means that its not exactly on the dot?
[14:41:07] <digi001> ha yes
[14:41:22] <digi001> thats true
[14:41:37] <digi001> hey so my compiler says 16 is too large for shift
[14:43:24] <tlvb> hm, it seems that I have multiplied somewhere I should have been dividing or the otherway around
[14:43:48] <tlvb> digi001: waht compiler would that be?
[14:44:55] <tlvb> does it work if using two consecutive >>8 instead?
[14:44:57] <digi001> code composer studio
[14:45:16] <digi001> sorry its not avr
[14:45:31] <digi001> i could try that
[14:48:11] <tlvb> msp430?
[14:50:05] <tlvb> yay, it works now
[14:52:17] <digi001> no tms320f28335
[14:52:24] <digi001> what was the issue?
[14:53:27] <tlvb> I haven't bothered to work out the math yet, but basically 5000 should have been 2500, I guess the '2' in 20MHz went on the wrong side of a division or something like that
[14:54:43] <tlvb> I cannot find where though
[14:54:49] * tlvb is quite confused right now
[14:58:06] <RikusW> tlvb: what avr is that ?
[14:58:13] <tlvb> atmega168
[14:58:34] <RikusW> what is your clock prescaler set to ?
[14:58:37] <RikusW> CLKPR
[14:58:40] <digi001> yes i think its prescaler
[14:58:42] <tlvb> my best bet right now is that I have configured the timer so that it for some reason takes twice the time
[14:59:16] <RikusW> and what about the CKDIV8 fuse ?
[14:59:27] <tlvb> I have confirmed that I run at 20MHz already, also a factor two does not match neither of the ckdiv8 or the prescaling of the timer input
[14:59:40] <tlvb> *double negative*
[15:00:44] <tlvb> that, is it, I thought I had set it to do CTC, but I misread the datasheet
[15:01:51] <tlvb> I had it set to phase and frequency correct operation
[15:14:29] <RikusW> stk500 and jtag mki use word addressing for flash, to make life interesting it seems jtag mkii use byte addressing for flash :S
[16:05:10] <amee2k> am i doing it wrong, or are PCB mount push buttons with built-in LEDs hard to find??
[16:06:27] <amee2k> emphasis on "built in LED" and "PCB mount", because this way it pretty much saves me from making a front panel
[16:06:57] <amee2k> and i can just put the matrix on a board and mount it against the inside of the case with just a rectangular cut-out
[16:10:06] <vectory> then were would be the fun of building it yourself
[16:10:11] <vectory> and saving a few bucks on top
[16:11:19] <vectory> bye
[16:12:24] <amee2k> "saving a few bucks"?
[16:13:11] <amee2k> well, i would but only because 50 cent push buttons suddenly cost three bucks if they come with an LED
[16:13:51] <amee2k> i'm repurposing the case from a rackmount switch so it allready has suitable cutouts
[16:46:23] * Casper wonders if phantone want to make a competition with him... hmmm
[17:19:39] <phantoxe> Casper: one of my nicks in another network is "phantom" :)
[17:20:45] <Casper> so maybe it's you that keep trying to identify as my second nick? :D
[17:21:13] <phantoxe> nop
[17:21:43] <phantoxe> although I still have that nick on that network, I currently only use this one there also
[19:30:59] <tomatto_> is it not possible to tell that i want -0 instead of 0 isn't it?
[19:33:20] <inflex> shit... found a good replacement chip for my needs... but now I have no $$$$
[19:34:43] <Tom_itx> life is funny that way
[19:34:57] <inflex> yeah... nice 16MBit EEPROM/Flash SPI chip
[19:35:03] <inflex> 10c more than the 256KBit one
[19:35:10] <inflex> same brand too (Atmel)
[22:45:40] <Casper> abcminiuser:
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html#codelisting
[22:45:44] <abcminiuser> There's an old cornell one
[22:45:46] <abcminiuser> Snap
[22:46:01] <abcminiuser> Low speed only, but good enough for HID devices
[22:46:13] <Casper> good enought to enumerate usb device
[22:46:21] <Casper> I wonder if it would work with hubs
[23:16:07] <Tom_itx> abcminiuser, does your buttloader allow you to use isp or do you still need flip or dfu programmer?
[23:17:10] <abcminiuser> Casper, no, it won't work as hubs need bulk endpoints (not possible with low speed USB)
[23:17:19] <abcminiuser> Tom_itx, wha?
[23:17:29] <abcminiuser> Buttload can be programmed into the Butterfly however you like
[23:17:41] <abcminiuser> Then you can use it as an AVRISP to ISP other devices
[23:17:55] <abcminiuser> Or you can store the programming commands internally, and ISP program other devices without a PC
[23:18:10] <Tom_itx> so it's written for the butterfly?
[23:19:53] <abcminiuser> Yep
[23:20:02] <abcminiuser> It's a rather old project, remember
[23:20:08] <Tom_itx> i know
