Back
[03:17:57] <Jamax> hello
[04:41:35] <beaky> hello
[04:42:35] <beaky> if I want to clock my avr at a frequency other than 1Mhz, 2MHz, 4Mhz, or 8Mhz, what should I do?
[05:05:49] <Fleck> detune oscillator or use external clock
[05:13:47] <twnqx> Fleck: fast learning :P
[05:14:17] <Fleck> twnqx: ;pp
[05:15:29] <Valen> get a different frequency xtal?
[05:18:14] <megal0maniac> I'm with Valen on this one
[05:19:16] <Fleck> yeah, if you got pins for xtal, why not...
[05:20:52] <megal0maniac> Also (usually) much more accurate
[05:29:44] <beaky> ah
[05:29:51] <beaky> I want my clock to count every .5ms
[05:30:07] <beaky> but if I use timer interrupts over _delay_ms my code will be longer
[05:30:15] <beaky> I think I'll use the 16-bit timer
[05:31:59] <beaky> btw how do you guys structure your avr C projects?
[05:35:11] <R0b0t1> Does anyone know of an 8051 disassembler?
[05:37:12] <beaky> does objdump wokr?
[05:37:13] <beaky> work*
[05:41:27] <R0b0t1> 'doh, lemme see if sdcc ships with one
[05:49:19] <beaky> how do I power on my stk500?
[05:53:09] <twnqx> Fleck: beware that a detuned osc will break eeprom writing & flash self programming
[05:57:47] <Horologium> beaky, how do you mean by "structure"?
[05:58:10] <Horologium> R0b0t1, look at 8051.com and see if there is one there.
[06:05:19] <R0b0t1> Horologium: d52 works passably on .hex files, the distributed .lib seems to be something else entirely... 5.9MB library?
[06:05:52] * Horologium shrugs.
[06:05:55] <R0b0t1> Yeah.
[06:05:59] <Horologium> I don't do any disassembly these days.
[06:07:39] <Horologium> beaky, to power the stk500, as stated in stk500 users guide, "Apply 10 - 15V DC to the power connector."
[06:15:11] <Fleck> twnqx: yep, I have red about that
[06:16:18] <Horologium> hmmm...how about a tunable oscillator made from a 555 and a digital pot?
[06:16:22] <Horologium> muahahahaha.
[06:17:35] <Fleck> ;pp
[06:23:35] <twnqx> Horologium: still requires a clock pin.
[06:23:45] <Horologium> true, but only one!
[06:24:02] <twnqx> like an external cmos oscillator :P
[06:26:41] <Fleck> twnqx: got some asm examples of OSCCAL ?
[06:31:08] <Horologium> as for detuning with OSCCAL, you can go way up and not affect the EEPROM or FLASH writing so long as you don't exceed the maximum frequency of the chip, or the maximum operating frequency at the voltage you are using.
[06:36:26] <Horologium> http://www.atmel.com/Images/doc2555.pdf this tells all about the internal RC oscillators.\
[06:38:28] <Horologium> including calibrating and, I do believe, setting to odd frequencies.
[06:50:03] <twnqx> Fleck: like Horologium linked. there are a few more documents though
[06:58:30] <Horologium> lots of such documents
[07:16:53] <megal0maniac> How does one keep a Linux system clean?
[07:21:02] <antto> with alcohol ;P~
[07:22:50] <tzanger> megal0maniac: clean in what sense?
[07:24:18] <antto> or with bleach
[07:27:25] <megal0maniac> tzanger: Remove unnecessary packages. You install one thing, it installs 5 dependenices, then you remove it and you only get rid of the main package
[07:27:44] <megal0maniac> I'm sure my system is full of stuff I don't need or want. Packages and config
[07:28:25] <tzanger> megal0maniac: apt-get autoremove
[07:39:00] <twnqx> emerge --depclean
[07:39:12] <megal0maniac> tzanger: The config files are more of a pain
[07:39:20] <megal0maniac> (I'm on debian, so apt-get is right)
[07:40:11] <tzanger> oh in that case you should apt-get purge packagename if you want to blow it away
[07:40:27] <tzanger> I am not aware of a way to locate unused config files but I'm sure it's there
[07:42:01] <megal0maniac> Ooh, purge
[07:42:04] <megal0maniac> Sounds dangerous :)
[07:49:36] <Tom_itx> apt-get clean?
[07:53:45] <Tom_itx> clean will free drive space
[07:55:29] <megal0maniac> Tom_itx: I mostly want to get rid of config
[08:00:30] <Tom_itx> how do you list what's installed?
[08:02:48] <beaky> hello
[08:07:48] <Tom_itx> recharge your cell phone in 20 sec
[08:07:49] <Tom_itx> http://www.electronicproducts.com/Power_Products/Batteries_and_Fuel_Cells/High_school_student_wins_Young_Scientist_Aware_for_supercapacitor_that_can_re-charge_cell_phone_in_seconds.aspx
[08:18:08] <skroon> hi
[08:18:44] <Tom_itx> lo
[08:30:24] <twnqx> right
[08:31:01] <twnqx> so highschoolers with interest an nanochemistry beat the hell out of professional scientists
[08:31:06] <twnqx> in terms of results
[08:32:09] <Tom_itx> imbarrasing ehh?
[08:32:21] <Tom_itx> em*
[08:41:12] <tzanger> nothing embarassing there
[08:41:14] <tzanger> that's how science works
[09:16:53] <inflex> Tom_itx: thought that was just a horrible bit of reporting and awarding
[09:17:19] <inflex> I mean, you'd need a supercap the size of a suitcase to compete with the energy stored in a lipo cell in the phone
[09:19:40] <megal0maniac> inflex: Let them dream ;)
[09:20:10] <inflex> Bad science reporting
[09:20:56] <tzanger> inflex: that's what I thought as well
[09:21:06] <tzanger> they have very high internal resistance
[09:21:12] <tzanger> you can charge them just fine but you can't get more than a few mA out of them at a time
[09:22:42] <Fleck> Horologium: thx, but I asked for ASM example :D
[09:25:32] <twnqx> compile it, look at disassembly >_>
[09:30:30] <Fleck> twnqx: again - not what I am asking :D
[09:31:25] <Fleck> anyway - I think I found example...
[09:31:31] <twnqx> i obviously don't understand what you're asking for, then
[09:35:25] <tzanger> what are you looking for?
[09:36:04] <Fleck> downclock my attiny13 to ~8MHz
[09:36:08] <Fleck> in ASM
[09:36:24] <tzanger> ok, I maybe missed it yesterday, but why is an 8MHz clock important?
[09:36:29] <tzanger> what is wrong with 9.6?
[09:36:52] <Fleck> chiptunes code here, plays too fast :D
[09:37:01] <Fleck> was made for 8MHz
[09:37:13] <tzanger> it'd be far easier to just skip clocks
[09:37:23] <tzanger> I assume you are playing based on a timer
[09:37:37] <tzanger> recalibrate your timer so the ticks are what it's supposed to be
[09:37:38] <Fleck> yeah - vector 3
[09:37:41] <tzanger> ok
[09:37:50] <tzanger> so it's timer0 right? what is your period supposed to be?
[09:38:44] <tzanger> hell you've got the code, look at the configuration and calculate based on 8MHz
[09:43:20] <Fleck> tzanger: want to take a look and help? :D
[09:43:43] <tzanger> Fleck: no, I have a pretty good idea what you have to do
[09:44:50] <tzanger> look at TCCR0A/B and TCNT0.
[09:45:04] <tzanger> the timer counts from TCNT0 to overflow, then interrupts
[09:45:08] <megal0maniac> Fleck: Do your homework!
[09:45:11] <megal0maniac> :)
[09:45:33] <tzanger> how much time passes per "tick" for the counter is the i/o clock divided by the prescaler which is configured by TCCR0B
[09:45:50] <megal0maniac> A wild Atmel dev appears!
[09:45:51] <tzanger> i.e. a 1:128 prescaler means 128 i/o clocks pass for ever 1 tick of the timer
[09:46:27] <tzanger> so you know what the original i/o clock is (125ns). you know what the prescaler and count are
[09:46:34] <Fleck> prescaler is disabled - not used - 1
[09:46:38] <tzanger> so you should be able to easily figure out what the correct timer tick rate is
[09:46:45] <tzanger> er timer interrupt rate
[09:46:49] <tzanger> good
[09:46:58] <tzanger> so you know that the timer counts up every 125ns
[09:47:04] <tzanger> now what is TCNT0 set to
[09:47:16] <Fleck> not a single TCNT0 line
[09:47:44] <tzanger> ok, maybe it is just counting from 0 up. not initializing shit is bad practise but whatever
[09:47:52] <tzanger> so 256 125ns ticks is how much time?
[09:48:10] <tzanger> <insert jeapordy music here>
[09:48:32] <Fleck> 32000ns
[09:52:06] <tzanger> right, so 32us per interrupt
[09:52:12] <tzanger> now you have a 9.6MHz clock so what is your tick time
[09:55:51] <Fleck> ~104ns
[09:55:59] <tzanger> right, or about 20% faster
[09:56:23] <tzanger> so that means your timer0 interrupt rate went from 32us to ~27us, which is why it's playing faster
[09:56:27] <tzanger> so
[09:56:30] <tzanger> we need to slow that fucker down
[09:56:39] <Fleck> TCNT0 ?
[09:57:05] <tzanger> now a maximum TCNT0 value (0) is as slow as you're going to go for a given prescaler
[09:57:29] <tzanger> so you'll ahve to change your prescaler to the next gear ratio (1:2) which gives you ~54us per maximum count, which is far too slow
[09:57:54] <tzanger> so now you edit TCNT0 so that it starts at a higher value so it will reach overflow faster and thus interrupt faster
[09:57:57] <tzanger> with me so far?
[09:58:07] <Fleck> yep
[09:58:13] <tzanger> ok
[09:58:15] <tzanger> so
[09:58:24] <tzanger> at a 1:2 gear ratio, what is your time per timer tick?
[09:58:54] <tzanger> ioclk is 104ns, 2 of those per timer tick, so...
[09:59:04] <Fleck> 204ns
[09:59:22] <tzanger> yep. now you want an interrupt every 32000ns
[09:59:37] <Fleck> 156
[09:59:41] <Fleck> TCNT0 value
[09:59:41] <tzanger> 32000 / 204 is 157
[09:59:51] <Fleck> ok, 157
[09:59:51] <tzanger> so you want an interrupt every 157 timer ticks
[09:59:55] <tzanger> now the timer counts up, not down
[10:00:06] <Fleck> 99 that is
[10:00:06] <tzanger> so you want to load TCNT0 with 256-157 every interrupt
[10:00:11] <Fleck> yeah
[10:00:33] <tzanger> so configure TCCR0B for 1:2 ratio and load TCNT0 with 99 in the ISR
[10:01:00] <Fleck> thx, You are the best! I'll try...
[10:02:12] <tzanger> now you will have interrupts every 99 timer ticks, which at 9.6MHz is 1/9.6MHz * 2 * (256-99) or 32.7us
[10:02:15] <tzanger> which is a little slow
[10:02:22] <tzanger> you might want to tweak that, we had a lot of rounding
[10:03:12] <tzanger> try loading with 102 instead, that gives you 32.08us which is closer
[10:04:26] <tzanger> it pays to carry a few decimal places, especially when you're counting so many times
[10:07:55] <Fleck> ok
[10:09:51] <tzanger> so how does it sound?
[10:10:36] <Fleck> I have a problem - I see only clk_io/1 and clk_io/8 - 1:2 I don't find
[10:11:04] <Fleck> ahh, 4.8Mhz ?
[10:11:59] <Fleck> never mind :D
[10:12:45] <tzanger> eh?
[10:13:49] <Fleck> tzanger: just ingore :)
[10:14:31] <tzanger> oh I see, you have 1:1, 1:8 are the options
[10:14:38] <tzanger> so set it for 1:8 and see if we can get 32us
[10:14:40] <tzanger> same process
[10:15:01] <Fleck> no, I have 1:2
[10:15:21] <tzanger> on attiny13a? I'm looking at the datasheet
[10:15:58] <Fleck> http://www.atmel.com/Images/doc2535.pdf
[10:16:41] <tzanger> what chip are you using?
[10:17:04] <Fleck> ATtiny13
[10:17:24] <thetruthisoutthe> h
[10:17:36] <tzanger> I do not see a 1:2 prescaler there
[10:19:36] <Fleck> tzanger: yep, but you can set fuses to 4.8MHz
[10:21:10] <tzanger> ah you're working around it that way. that works well. :-)
[10:21:26] <tzanger> I'm using the tiny13a at 128kHz in a low power design
[10:21:44] <thetruthisoutthe> beaky <= lol use a prescaler, and a timer interrupt to get 0.5ms timing intervals, 8MHz should be fine, this does not require to use another clock frequency
[10:22:14] <tzanger> thetruthisoutthe: amazing... it's almost like there is a consensus among developers
[10:24:15] <Fleck> tzanger: meh, kinda sounds better, but there is something else wrong... :/
[10:24:32] <tzanger> depends on what all is going on in the code
[10:24:54] <Fleck> original code was for attiny9, I guess I made some mistakes converting to attiny13
[10:24:56] <tzanger> if everything is based off the timer then great, but if it's relying on a minimum 8MHz clock to do somet iming loops,e tc. then you're gonna have to stay up at 9.6 and use an 8:1 prescaler
[10:25:11] <Fleck> ohh
[10:25:16] <Fleck> ok, ill try 1:8
[10:30:47] <thetruthisoutthe> tzanger <= i believe the best solution survives, this is how evolution works :)
[10:41:53] <Fleck> meh, attiny13 died :D
[10:42:14] <tzanger> died?
[10:42:31] <Fleck> Chip Enable Program Error
[10:42:31] <Fleck> can't reflash
[10:48:10] <beaky> why would one want to connect an external clock?
[10:48:17] <beaky> for ADC or for DAC?
[10:48:27] <beaky> or for making the mcu faster?
[10:51:54] <tzanger> Fleck: did you disable reset somehow?
[10:52:28] <beaky> I've powered on my STK500, and I get a LED that turns on
[10:53:19] <beaky> but my STK500 came with a RS232 connector thingy; how do I fit that into my laptop? :D
[10:53:35] <tzanger> heh
[10:53:42] <tzanger> usb rs232 port
[10:55:29] <beaky> damn why doesn't the STK500 come with that (and a proper PSU) :( now I have to visit all the local electronics shops hunting for all that
[10:55:54] <beaky> I guess it was made in an age before the advent of USB
[10:57:47] <megal0maniac_afk> beaky: If buying from China is an option for you, then you can pick one up for like $2
[10:58:07] <tzanger> I think he's just more upset that he has to go find one
[10:58:09] <tzanger> not that they're unavailable
[10:58:25] <megal0maniac_afk> Someone should have warned him :)
[10:58:35] <beaky> I thought the STK500 was the one to go for
[10:58:40] <beaky> (over the STK600)
[10:59:06] <tzanger> I think both are old
[11:00:11] <beaky> hmm I did recall some "evaluation kits" being shown while I was lookig for the stk500, are those the newest ones?
[11:00:29] <megal0maniac_afk> Are you just using it for programming?
[11:00:40] <beaky> yes
[11:01:27] <beaky> just for programming or debugging
[11:03:46] <megal0maniac_afk> stk500 doesn't debug
[11:04:34] <beaky> argh I got the wrong board :(
[11:04:49] <megal0maniac_afk> dragon is cheapest programmer/debugger (and it's usb) and avrisp mkii is the most recent usb programmer (Tom_itx makes a clone of it)
[11:05:13] <megal0maniac_afk> The stk500 is still a programmer, it just needs that adapter and won't debug
[11:05:20] * megal0maniac_afk is really afk now
[11:05:20] <beaky> ah I got a dragon and avrisp mkii :D
[11:05:31] <megal0maniac_afk> Then what's the stk500 for? :P
[11:05:39] <beaky> for sticking my chips in
[11:05:47] <megal0maniac_afk> Oh. Okay :)
[11:06:10] <megal0maniac_afk> Well then if there's an ISP header then you're good to go
[11:06:17] <beaky> maybe I can stick my chips on the stk500, and then use a dragon on the stk500
[11:06:23] <megal0maniac_afk> Exactly
[11:06:30] * megal0maniac_afk is really really afk now
[11:29:08] <thetruthisoutthe> beaky <= to make it faster, or to have <500ppm accuracy
[11:29:52] <thetruthisoutthe> or just to keep accurate time... with a 32768Hz watch crystal
[11:32:17] <beaky> ah nice
[11:32:34] <beaky> alright my chip is in the STK500 :D
[11:33:03] <beaky> how do i remove the ATmega8515L that's already in there though :(
[11:34:52] <thetruthisoutthe> screwdriver?
[11:36:03] <abcminiuser> GODDAM DOXYGEN
[11:36:10] <abcminiuser> I think Doxygen's motto should be "four unique XML IDs should be more than enough for everybody"
[11:36:14] * abcminiuser raagghhh
[11:36:15] <beaky> lol
[11:38:41] <l9> I have a stk500 have not felt the need for anything else yet
[11:39:18] <beaky> I got the ATMega8515L out, but I ended up bending some of the pins :(
[11:39:21] <tzanger> heh. I've got the dragon that I use only for one specific project and an arm-usb-jtag which I use for most others
[11:40:45] <l9> guessing you get more than flashing ligths of the chips too :P
[11:41:17] <l9> still a beginner when it comes too this :p but slowly learning
[11:41:27] <tzanger> everyone starts out a beginner
[11:41:50] <l9> and one hell of a ladder too climb it is
[11:45:13] <beaky> yes! I finally got my isp to work
[11:45:38] <beaky> no need to hunt down a serial-to-usb thing
[11:46:02] <beaky> but getting chips in and out of the STK500 is hard :( aren't there specialized tools for that kind of thing?
[11:46:51] <l9> beaky: just be carefull and loosen both sides litle first
[11:47:00] <l9> lettel
[11:47:02] <l9> argh
[11:48:02] <thetruthisoutthe> beaky <= that does not happen with soic, or tqfp
[11:50:14] <tzanger> there are chip pullers for DIP packages but really they're no better and tend to slip
[11:50:24] <tzanger> beaky: the socket will loosen up with a few more insertions
[11:52:00] <Fleck> tzanger: btw, when that att13 chiptuned - serial reading was bad... had to tap few times to reflash... (until got correct SN...) Could this be the reason it died? Like... set fuses by mistake? I didn't have checked "program fuses" though
[11:52:28] <tzanger> there are a few possibilities
[11:52:39] <Fleck> ok, will try to reset with HVP
[11:52:43] <tzanger> I tend to always give the longest startup times for hte clock settings
[12:02:51] <MrM0bius> hello
[12:07:39] <beaky> ah thanks
[12:09:56] <beaky> hmm my stk500 is reversed: why does it turn on the leds when my MCU resets the port?
[12:11:20] <tzanger> guessing that active low lights the led?
[12:22:42] <MrMobius> would this work for making sure IC1 and IC2 never transmit at the same time?
[12:22:43] <MrMobius> https://www.circuitlab.com/circuit/9dkv32/screenshot/1024x768/
[12:39:10] <tzanger> is there a reason you have to make sure it never happens?
[12:40:35] <tzanger> why use the transistors and not just a NOT gate?
[12:41:01] <jacekowski> component count
[12:41:32] <tzanger> you can also just put 100 ohm resistors on the data lines of IC1 and IC2; if they *do* contend you'll get (Voh-Vol)/100 as the maximum current and it's likely to be only for a few microseconds anyway
[12:41:40] <tzanger> jacekowski: an inverter is one component vs 7
[12:42:24] <MrMobius> tzanger, one of the ICs is an SRAM chip and apparently you can damage them like that
[12:42:39] <twnqx> umm
[12:42:43] <tzanger> MrMobius: ok but are you not in control of their OE?
[12:42:47] <MrMobius> yeah, like 7404 or something right?
[12:43:01] <twnqx> smaller, single gate
[12:43:22] <tzanger> something about the design is not making sense
[12:43:51] <MrMobius> tzanger, i am in control of their OE but when i program my microcontroller the pins flash randomly so during that time they could both be on. also, id like to make sure it is not physically possible for them to be on in case i get a bug in my code
[12:44:03] <MrMobius> tzanger, hmm, what do you mean?
[12:44:22] <tzanger> MrMobius: you have CS and OE; don't put them both on the programming pins and use a pullup to make sure they don't float to an on state
[12:44:24] <twnqx> does ti.com work for any of you? :X
[12:44:42] <tzanger> works for me
[12:44:50] <twnqx> so it's only me, great
[12:44:51] <tzanger> I'd just use 100 ohm resistors
[12:44:54] <twnqx> "internal server error"
[12:45:34] <MrMobius> tzanger, so transistors like this and the 100 ohm resistors?
[12:45:41] <twnqx> what
[12:45:48] <twnqx> only the 100ohm
[12:46:16] <MrMobius> twnqx, and if something craps out and it gets stuck on for 10 seconds i probably wont fry anything?
[12:46:30] <MrMobius> ti.com works for me btw
[12:46:34] <tzanger> no transistors
[12:46:42] <twnqx> there's maximum current listed in the sram's data sheet
[12:46:47] <tzanger> just 100 ohm resistors, although again it sounds like you've got some bad pin selections
[12:46:54] <twnqx> size the resistor so you stay below that
[12:47:44] <MrMobius> twnqx, alright. is there any chance it will slow things down if i starting going near the max speed of the sram?
[12:47:49] <tzanger> or do the right thing and put CS or OE on a pin that doesn't double as a programming pin and pull it up
[12:47:53] <MrMobius> tzanger, bad pin selections? pleas explain
[12:48:15] <MrMobius> tzanger, none of them double as programming pin. they all flash randomly sometimes.
[12:48:25] <twnqx> pins don't flash randomly
[12:48:33] <tzanger> MrMobius: your MCU I/O should be sitting still (most likely floating) when programming. If you've put OE and CS on the programming pins then they can activate on programming
[12:48:52] <twnqx> they are even in high impedance (inputs) during programming
[12:49:09] <tzanger> if they're flickering then you've got another issue somewhere... bad startup code maybe
[12:49:21] <MrMobius> im using a ti launchpad btw
[12:49:29] <tzanger> ti launchpad doesn't sound like AVR
[12:49:34] <MrMobius> i like to ask about more general stuff here since people are usually more helpful
[12:49:36] <twnqx> no
[12:49:37] <MrMobius> indeed it is not
[12:49:43] <tzanger> which MCU?
[12:49:48] <twnqx> msp 430
[12:49:52] <MrMobius> but resistor on sram chips arent specific to ti or avr
[12:49:54] <MrMobius> msp430
[12:49:54] <MrMobius> yes
[12:49:55] <tzanger> MSP430 should not have any weirdness like that teither
[12:50:13] <MrMobius> i dont know what to tell you
[12:50:16] <tzanger> but look at the datasheet and make sure that you aren't using a pin for CE or OE that does something funky
[12:50:24] <tzanger> post your schematic
[12:50:30] <tzanger> make sure your hardware matches
[12:50:40] <twnqx> i did not need any resistors with my sram + avr :P
[12:50:51] <MrMobius> i had LEDs hooked up to about 6 of the pins to make sure data was being transfered to an LCD i was having problems with. the flickered on and off during programming
[12:51:02] <tzanger> you shouldn't. proper driving of the control lines ensures no contention :-)
[12:51:12] <MrMobius> tzanger, no schematic. im trying to figure out how to do it correctly. i have heard sram chips can be fragile sometimes
[12:51:24] <tzanger> oh so this isn't a real problem yet
[12:51:43] <MrMobius> no, i just dont want to make a mistake and ruin the chip
[12:52:03] <tzanger> I have a hard time believing the pins flicker during programming, but you may want to look around on the MSP430 forums/etc and see. I have not use an MSP430 for years
[12:52:53] <MrMobius> youre just going to have to believe me then. besides, having a hardware safety so a software bug doesnt put both devices on at the same time should be reason enough
[12:53:06] <tzanger> MrMobius: I don't have to believe anything. :-)
[12:53:19] <tzanger> MrMobius: you're asking us for help, not the other way around, and we made some suggestions
[12:53:33] <MrMobius> yes, thank you for yor suggestions
[12:53:44] <MrMobius> im just teling you what i see
[12:53:50] <tzanger> 100 ohm resistors on the data lines will help (hell it will also help with reflections should you need to worry about that) but there should be no need to try and prevent contention
[12:53:57] <MrMobius> i thought it would be relevant to the porblem even though you deny what i see with my own eyes
[12:54:01] <MrMobius> no reason to argue though
[12:54:04] <tzanger> right, and I think we're saying that there is something else contributing to it
[12:54:10] <tzanger> agreed, we're not arguing
[12:54:47] <MrMobius> alright then
[12:55:11] <MrMobius> well just for learnings sake, if this were a different set up and the contention were a big problem
[12:55:27] <twnqx> MrMobius: anyway your schematic is about two devices on the same bus, not device + mcu
[12:55:28] <MrMobius> could you count on transistors like that to keep them from going at the same time?
[12:55:46] <twnqx> you would not use transistors in any deisgn like that
[12:55:48] <tzanger> I would not use the transistors how you have it
[12:55:59] <tzanger> that doesn't guarantee that during turnon/off that both will never be on
[12:55:59] <MrMobius> it seems like me if the signal was oscilating wildly the transistors might not have time to turn on and back off again so they would kind of be in flux, like in an analog state before saturation
[12:56:17] <MrMobius> ahh ok, thats what i was afraid of
[12:56:38] <MrMobius> yeah, im trying to use shift registers to read and right to this RAM
[12:56:49] <tzanger> I would have one transistor connected to an I/O pin and the output of the transistor feeding an OR gate that goes to one of the devices
[12:57:07] <tzanger> the other leg of the OR gate would go to the MCU's CE or OE for the that device
[12:57:18] <tzanger> that way the device can never ever be selected unless whatever pin is driving the transistor is high
[12:57:36] <tzanger> and I'd set up the biasing on the transistor so that it needs a strong positive voltage
[12:58:18] <tzanger> but again there are likely a dozen or more things to be more vigilant about
[12:58:50] <MrMobius> wait, you would use a transistor and an OR gate?
[12:59:09] <tzanger> yes, but not in the configuration you did
[12:59:31] <tzanger> I would use the transistor to provide a positive "I want external device access" signal
[12:59:31] <MrMobius> i think i could just use an inverter instead of what i did. why the OR gate and the transistor?
[12:59:53] <MrMobius> ok
[12:59:54] <tzanger> the output of that transistor would be low when I want extenral device access, and float up to +v otherwise
[13:00:07] <tzanger> that signal can go to an OR gate on every device's CE line
[13:00:20] <tzanger> the other input of the OR gate would go to the normal MCU CE for that device
[13:00:35] <MrMobius> ah, so you can shut off all external access at once?
[13:00:37] <tzanger> that way unless that transistor is on, no external device will see CE low and will thus remain in HI-Z state
[13:01:27] <tzanger> then I would bias that transistor with a 10k pull-down and say a 4V zener diode in series with a 1k resistor
[13:01:32] <MrMobius> what happens when you enable external access with the transistor, turn on one device then an interrupt fires unexpectedly because you made a mistake and turns on another device?
[13:01:40] <tzanger> (anode of the zener going to the MCU, cathode going toward the transistor base)
[13:02:07] <tzanger> MrMobius: well that is it; you select an I/O pin that you don't normally use
[13:02:07] <MrMobius> woops, you werent done explaining your deisng
[13:02:32] <tzanger> or you can even remove the transistor and hook the OR gate output to an I2C I/O expander
[13:02:44] <tzanger> that way you have to perform a valid I2C transfer to get that logic state changed
[13:02:48] <tzanger> but again this is kind of ridiuclous
[13:03:06] <tzanger> just put 100 ohm resistors on the data bus of the SRAM and be done with it
[13:03:16] <MrMobius> lets keep it simple and say the transistor gets one pin and each of two devices has their own pin. you cant imagine a software bug turning on all three pins at once?
[13:03:18] <tzanger> What is Ioh/Iol for the SRAM data bus
[13:03:21] <MrMobius> alright, i will do that
[13:03:28] <tzanger> and what is VCC
[13:03:30] <MrMobius> but most of things i ask like this are just to know
[13:03:36] <tzanger> you can overcomplicate anything ;-)
[13:03:41] <MrMobius> Vcc is 3 - 3.6v
[13:03:43] <MrMobius> hehe
[13:03:49] <tzanger> ok so 3.6V is worst case
[13:04:00] <tzanger> what is Ioh/Iol on the sram data bus pins
[13:04:00] <MrMobius> im sure stopping two things from using the same bus would be very useful to know
[13:04:10] <MrMobius> lets looka t the dataseet
[13:04:13] <tzanger> it's just logic.
[13:04:13] <MrMobius> hold on
[13:06:18] <MrMobius> i dont see it. the sram is AS6C1008. i will google a datasheet
[13:06:58] <tzanger> any particular reason you chose that specific SRAM?
[13:07:15] <tzanger> holy fuck that thing can dissipate a full Watt
[13:07:23] <MrMobius> yes, it is in my parts box and there is no foreseeable use for it :P
[13:07:28] <MrMobius> not to be a smart aleck
[13:07:41] <tzanger> nope that's a perfectly valid reason
[13:08:12] <tzanger> well it says it can dissipate a full Watt. that's an extreme case but let's go with it
[13:08:37] <twnqx> better not touch it while it's doing that :O
[13:09:16] <MrMobius> hehe
[13:09:29] <tzanger> the datasheet is cagey
[13:09:35] <tzanger> but let's take its' typical use
[13:09:36] <MrMobius> ya, doesnt seem too in depth
[13:09:49] <tzanger> 30pF load, 2mA I/O pin
[13:10:10] <MrMobius> ohh, hmm what is 2ma listed under?
[13:10:28] <MrMobius> Iol?
[13:10:30] <tzanger> at 3.6V, you'd want a 3.6/2mA or 1800 ohm resistor to limit the current to 2mA
[13:10:37] <tzanger> that is not listed as a maximum, just a typical
[13:10:42] <tzanger> and 1800 ohms is unreasonable
[13:10:54] <twnqx> wait, it's i2c?
[13:11:10] <tzanger> 3.6/100 is 36mA, which for a glitch is probably perfectly fine
[13:11:21] <tzanger> you wouldn't want to source or sink that for any amount of time
[13:11:23] <tzanger> but still
[13:11:58] <MrM0bius> sorry got dc. what did you a after 1800 ohm and wouldt want to source or sink
[13:11:58] <MrM0bius> ?
[13:12:00] <tzanger> and since P=VI, that's 130mW you're dissipating under worst case conditions
[13:12:07] <tzanger> I said 1800 ohms is unreasonable
[13:12:13] <tzanger> and 2mA isn't listed as a maximum, just typical
[13:12:45] <tzanger> 100 ohms limits you to 36mA worst case (at 3.6V) and since P=VI that's 130mW you'd dissipate per contended output
[13:13:00] <RikusW> http://www.buybuyfast.com/hcsr04-ultrasonic-ranging-module-color-blue_p595.html
[13:13:17] <MrM0bius> times 8 :/
[13:13:23] <RikusW> my brother got 8 or so of those
[13:13:31] <tzanger> MrMobius: ONLY if all 8 are contending
[13:13:39] <MrM0bius> ya, worst case scenario
[13:13:50] <tzanger> and again how long does the flicker last? say 100ms
[13:14:16] <tzanger> but I bet those resistors would do plenty to protect you from everything but the most idiotic of problems
[13:14:27] <tzanger> RikusW: nice
[13:14:27] <MrM0bius> ya, thats just what ot me thinking about it. the scray thing is some bug in the code i dont realize for 3 or 4 minutes then its too late
[13:15:16] <MrM0bius> btw, 2ma is the minimum current it needs to register high?
[13:15:34] <tzanger> well I think the more likely problem is you forgetting to turn your data bus on the MCU back into inputs before asserting CE/OE
[13:16:13] <tzanger> or you not putting a few us of delay when switching direction on the bus
[13:16:39] <tzanger> an even better idea is to use something like a 74xx138 and configuring output 0 for one chip and output 1 for another
[13:16:45] <tzanger> no way you can have two CE# active at the same time
[13:17:05] <tzanger> the only issue is data bus contention between the MCU and external devices then
[13:17:19] <MrM0bius> well, ill be using shift registers but i suppose its the same idea
[13:17:19] <tzanger> but even then you can save yourself from yourself by inserting a 74xx245 inbetween the MCU and devices
[13:18:30] <tzanger> 138 protects the devices from each other. 245 protects the bus from the MCU; you drive the direction pin of hte 245 with a combination of the OE signals and the bus WR signal. that way you can't hurt the devices if you forgot to turn the bus off, and the 245 would probably be more than capable of cooking the MCU's drivers. :-)
[13:18:38] <tzanger> again, how far do you want to take the protection? it's a question of levels
[13:19:03] <MrM0bius> that does seem like a lot
[13:19:19] <MrM0bius> did we decide that using resistors only wouldnt work?
[13:19:50] <tzanger> no, it offers moderate protection and costs you some speed because now you're charging and discharging the bus capacitance through 100 ohms
[13:19:57] <MrM0bius> ya
[13:20:11] <tzanger> make it 330 ohms and you limit the current to about 10mA which is still lots of drive
[13:20:48] <MrM0bius> ill have to find some 74xx solution then. why wont a simple 7404 work? it would only allow one device to be on at a time, not counting whatever time it needs to transistion
[13:21:12] <tzanger> hell you can put a scope across any resistor and trigger at ~1.6V
[13:21:26] <tzanger> then you get an "alarm" that tells you if there was every any contention that caused more than ~5mA current draw on that pin
[13:21:34] <tzanger> that will tell you you have to delay a little more
[13:21:44] <RikusW> I got one of these
http://www.buybuyfast.com/epm240-altera-max-ii-cpld-development-board_p920.html
[13:22:17] <MrM0bius> ya thats one idea
[13:22:27] <MrM0bius> a plain old 7404 wouldnt work though?
[13:22:29] <tzanger> once you're happy that there is no contention you can remove the resistors and start driving up the speed
[13:22:33] <tzanger> 7404 where
[13:23:20] <MrM0bius> well those transistors were essentially trying to replace one since i dont have one. it just invets the signal. one device gets the signal and the other gets the inverse of the signal
[13:23:35] <MrM0bius> get being to the chip select pin
[13:23:41] <twnqx> that means one chip is always active
[13:23:47] <twnqx> and can collide with the mcu!
[13:23:50] <tzanger> well no
[13:24:00] <MrM0bius> no, didnt you see where i said i was using shift registers?
[13:24:04] <twnqx> ah, no
[13:24:07] <tzanger> CE = chip selected, it's fine as long as OE is not active while the MCU is driving
[13:24:25] <tzanger> replace MCU with shift reg/whatever, doesn't matter the ocncept is the same
[13:24:35] <tzanger> except the shift registers probably have more I/O drive capability
[13:25:01] <MrM0bius> i would feel fine doing it with an inverter. im just concerned about the time it takes the inverter or transistors to transtion. thre should be a short time when neither line is fully on or off. thats what i was curious about
[13:25:07] <MrM0bius> yes, 35ma or so
[13:25:12] <twnqx> lol
[13:25:18] <twnqx> that time
[13:25:22] <twnqx> should be measured in ns
[13:25:23] <tzanger> I'd just use resistors and call it a day :-)
[13:25:37] <twnqx> and is totally irrelevant
[13:25:55] <twnqx> you should be more worried about the not-driving-at-all times
[13:26:05] <twnqx> (for OE, CE, etc)
[13:26:56] <MrM0bius> tzanger, i think some kind of 74xx logic will work. you were talking about hardwiring the 138 and using the line select so that two devices can never be on at the same time?
[13:27:21] <tzanger> MrM0bius: yeah an LS138 is your nicest solution
[13:27:30] <MrM0bius> LS doesnt work at 3v
[13:27:31] <tzanger> and even lets you select 5 more items for free
[13:27:36] <MrM0bius> thats hand
[13:27:42] <tzanger> MrM0bius: HC, AC, LV, whatever
[13:28:02] <twnqx> and nice 5pin single gate chips
[13:28:14] <twnqx> tzanger: i was using the same approach in my CAN design :>
[13:28:36] <MrM0bius> thats clever. why the 245 though? shouldnt the 138 be enough?
[13:28:38] <twnqx> though i use a nand and an and for address eelect
[13:30:16] <tzanger> MrM0bius: I thought I explained all of this
[13:30:22] <RikusW> heh, that ultrasonic module uses a max232 to drive the transducer
[13:30:27] <tzanger> MrM0bius: the 245 was there to protect the devices (the bus) from your micro/shift register
[13:30:45] <tzanger> in case of some software problem that caused you to drive the bus when you should be letting the other end drive it (i.e. a read)
[13:30:45] <MrM0bius> yes, you explained that but i dont see how that would work
[13:30:56] <tzanger> 245 is a bidirectional register
[13:31:07] <RikusW> LM324 for RX and X03 14 pin SOIC as controller, no idea what kind of uc that is...
[13:31:16] <tzanger> it would take the brunt of the current draw since it would always be "pointing" in the right direction based on the OE/WE signals
[13:32:05] <tzanger> it would always present a high impedance to the bus when the bus was told to write, and would always present a low impedance when the bus was told to read
[13:32:24] <tzanger> then put some 100 ohm resistors between it and the MCU/shift reg and you have a protected system
[13:34:33] <MrM0bius> i think you are picturing something different than i am. i am planning on having input shift registers and output shift registers hooked to the data bus. if i have the chip select of the reading sr hooked to the write enable of the SRAM, then what problem could happen?
[13:34:49] <tzanger> how do you "turn off" the output shift register?
[13:34:59] <tzanger> shifting zeroes out doesn't help, because it's DRIVING the bus to 0
[13:35:10] <tzanger> you need to turn the output shift register outputs off
[13:35:19] <MrM0bius> toggle the mcu pin so the output sr goes into z state
[13:35:26] <tzanger> that works
[13:35:35] <tzanger> but what if your code doesn't do itright?
[13:35:40] <tzanger> that was your big worry from earlier
[13:35:52] <tzanger> if that output SR doesn't go hi-z you're in for bus contention
[13:36:13] <MrM0bius> well, the worry was managing two pins at the same time because then you have to assume that those two pins will never be the wrong combination
[13:36:22] <MrM0bius> which is up to software
[13:36:42] <tzanger> you could have all even data lines pulled low and all odd data lines pulled high and then do not assert the bus oe# signal until you read back 0xaa :-)
[13:36:49] <MrM0bius> but with one pin and the reading/sram output and writing/sram input hardwired, there are only two states
[13:37:07] <tzanger> anyway... until you get figured out exactly what you want it's just talk and hypothesis
[13:37:15] <MrM0bius> not really
[13:37:28] <MrM0bius> i still have the same idea as when i asked. maybe i didnt really explain it right
[13:38:17] <tzanger> a schematic goes a long way to help
[13:38:20] <tzanger> I have a rough idea
[13:38:40] <MrM0bius> the first schematic with transistors was trying to control everything with one pin since that has only two states and neither is dangerous. if i use two pins then the possibility exists that i will enable both outputs and they will contend
[13:39:01] <MrM0bius> my idea to avoid contention was transistors. it sounds like your idea with a 138 is a better idea to use pone pin and avoid contention
[13:39:23] <MrM0bius> pone=one
[13:41:40] <MrM0bius> but i will see if i can make a schematic
[13:47:07] <beaky> should I clock my avr at 8MHz?
[13:47:14] <beaky> or will it waste power unless I sleep?
[13:55:39] <Xark> beaky: Lower clock will save power, but sleeping will save even more. Sleeping is generally easy (if you are waiting for interrupts or time to pass).
http://www.nongnu.org/avr-libc/user-manual/group__avr__sleep.html
[13:56:16] <beaky> ah thanks
[13:56:35] <beaky> so high clock, but slow timers and sleeping will be best
[13:57:24] <MrM0bius> tzanger, like this?
https://www.circuitlab.com/circuit/2kxz4k/138/
[13:58:57] <tzanger> not quite
[14:02:06] <twnqx> most tiny arms are closer to 100
[14:02:16] <beaky> wow
[14:02:28] <twnqx> even avr32/pic32 are more like 80
[14:03:25] <twnqx> on the other hand, there is a lot of free software and cheap programmers around for arm
[14:03:40] <twnqx> for avr*
[14:03:43] <beaky> i thught arm was very proprietary
[14:03:44] <beaky> ah
[14:03:57] <twnqx> well, for arm too
[14:03:59] <twnqx> :P
[14:04:19] <MrM0bius> arm is harder if you are a beginner. there is also only one arm chip in dip format and it is not that impressive.
[14:04:41] <tzanger> most times you don't need a lot of MHz
[14:04:43] <tzanger> don't fall into that trap
[14:05:03] <MrM0bius> ya
[14:05:10] <twnqx> remember: the good old C64 had only 1mhz :)
[14:05:25] <MrM0bius> lol
[14:05:35] <MrM0bius> and a bus to external ram im guessing :P
[14:05:46] <twnqx> of course
[14:05:50] <twnqx> dip 40
[14:05:56] <twnqx> no internal ram or rom :P
[14:06:18] <MrM0bius> hehe
[14:07:09] <MrM0bius> i saw a guy in electronics put a dip40 z80, dip40 sram, and dip40 pic on one breadboard. the pic handled pc communication and bootloading so the z80 could run
[14:07:09] <beaky> is dip a bad format?
[14:07:56] <MrM0bius> its not really useful but pretty slick. that got me to thinking it would be cool to find a dip40 microprocessor but unless it is single cycle, i think it would be smarter just to get a microcontroller
[14:08:20] <twnqx> beaky: it is just large and old
[14:08:31] <MrM0bius> beaky, it is the biggest format and the easiest to work with. when you can it is btter to use smaler parts though
[14:08:46] <twnqx> hm, MrM0bius...
[14:09:13] <tzanger> lots of DIP40 packaged MCUs
[14:09:50] <MrM0bius> yeah but i dont know of any that are single-cycle
[14:09:51] <twnqx> http://imageshack.us/a/img443/2573/jtagg.jpg <- use that and build your own dip CPU with a spartan 3 fpga!
[14:09:55] <MrM0bius> i havent really looked hard though
[14:10:15] <twnqx> (the top board is just jtag & usb interface)
[14:10:15] <MrM0bius> tzanger, the way i ave it in the schematic is not really what you meant?
[14:11:46] <MrMobius> DC again. did you say anything?
[14:12:02] <twnqx> no he didn'T
[14:12:17] <twnqx> how do you dc all the time?
[14:12:27] <twnqx> it's more like your internet connection is AC
[14:13:21] <Fleck> tzanger: HVP helped, chip is alive :D
[14:14:06] <MrMobius> twnqx, i use a 3G modem and my ISP makes me reconnect every 60 minutes. i checked and the disconnect command comes from them.
[14:14:30] <twnqx> heh
[14:17:06] <MrMobius> anyway, i think i will give this a try with logic chips and try not to ruin any sram chips
[14:17:11] <MrMobius> thanks for your help guys
[14:21:57] <tzanger> MrMobius: have one output of the 138 drive cs/oe of the output shift reg
[14:22:08] <tzanger> MrMobius: have another output of the 138 drive the cs/oe of the sram
[14:22:26] <tzanger> MrMobius: the input shift reg doesn't have to be controlled because it will never drive the bus
[14:22:57] <tzanger> your sram write/read signals go to the mcu
[14:23:29] <tzanger> so you select the output shift reg. this automatically disables the sram from outputting on the bus
[14:23:55] <tzanger> shift out the data, when it's shifted, pulse the write signal of the sram, that will write what's on the data bus in
[14:24:14] <tzanger> to read from the sram you select the sram with the 138, this automatically disables the output shift reg
[14:24:33] <tzanger> hold the read strobe low and shift in the data
[14:25:04] <tzanger> so the 138 output goes to the sram's OE and the output shift reg's ce or oe (depending on what it has, don't know offhand)
[14:25:12] <tzanger> it is very strange that you do this this way
[14:25:29] <tzanger> I'd have the data bus on the mcu and the address bus of the sram in a shift reg if you're short on pins
[14:25:34] <MrMobius> ya hmmm, the read sr never needs to go into z state
[14:25:36] <tzanger> but whatever works for you
[14:25:57] <tzanger> read SR is always in Z state
[14:25:58] <MrMobius> tzanger, i am short on pins so both address and data buses are shift registers
[14:26:19] <tzanger> I'd use a wider mcu then :-)
[14:26:35] <tzanger> first get a schematic together. a proper one, not circuitlab garbage
[14:26:49] <MrMobius> tzanger, what would be the fun in that? i could just hook the address and data bus to that mcu and avoid all shift registers
[14:26:50] <tzanger> grab eagle, it's free with restrictions you probably won't run in to
[14:27:49] <MrMobius> hey why would you have the 138 controlling the oe of the sram? why would it ever need to have high impedence?
[14:27:55] <beaky> http://ideone.com/wZRiln how do I improve my code?
[14:28:00] <tzanger> OE means output enable
[14:28:07] <tzanger> you want hte chip to be selected so you can write to it
[14:28:16] <tzanger> but you do not ever want its output enabled unless there is nothing else driving the data bus
[14:28:29] <tzanger> so you have the 138 control the hiz input on the shift reg and the oe input on the sram
[14:29:21] <MrMobius> ah ok, i think for the sram oe could be considered the same as write
[14:31:09] <MrMobius> honestly, i dont see a need to control the sram with an mcu pin. it doesnt need to be pulsed. just put it in write (to the SRAM) mode and then shift the data out. it doesnt matter what the old data in the sr was since new data is about to get written
[14:31:59] <tzanger> I would not design something where I hold write active while the data I'm going ot write is shifted out
[14:32:17] <tzanger> I would set up address and control, set up data, pulse write and be done
[14:32:59] <MrMobius> this sram doesnt need a pulse like a shift register. i just needs to be low
[14:33:33] <MrMobius> meaning oe of the write sr can be tied to the write of the sram
[14:34:26] <MrMobius> right?
[14:35:33] <tzanger> well there is propagation delay and setup and hold to think about, which is why I didn't recommend doing it that way
[14:35:36] <tzanger> you'll probably be fine though
[14:36:17] <MrMobius> so using the second pin would be good because it would give a small break where nothing is driving the bus?
[14:37:32] <tzanger> no, it gives the shift reg outputs time to settle on the correct values and the bus time to stabilize before you tell the sram "whatever's on the bus, that's what I want you to store"
[14:37:37] <MrMobius> i think i see what you meant before about the transistor and OR gate now
[14:38:13] <MrMobius> what do you mean by "stabilize"? the sr can write whatever it wants to the SRAM. i dont really car as long as the last thing it writes is what i want.
[14:38:24] <tzanger> nothing is instantaneous
[14:38:32] <tzanger> at t=0 you have a bus that is floating
[14:38:43] <MrMobius> sure
[14:38:44] <tzanger> at t=1 you tell the shift reg to enable its outputs
[14:39:02] <tzanger> at t=1+n the bus will finally settle to the new values
[14:39:14] <tzanger> so at t=1+n+1 you want to tell the SRAM to read
[14:39:21] <tzanger> the timescale is nanoseconds for sure
[14:39:33] <tzanger> but there are also setup and hold times you want to observe that are right on the datasheet
[14:39:47] <tzanger> the bus needs to be stable for x ns before you tell the SRAM to read
[14:39:59] <MrMobius> why? tell it to read at t=1. as i understand it t continuously reads the value. it doesnt take a snashot when it gets a pulse. it will continute to read as long as its in that mode
[14:40:01] <tzanger> then the bus needs to KEEP those values for y ns after you tell the SRAM to stop reading
[14:40:45] <tzanger> when you connect the shift reg OE and the SRAM WR together you are not ensuring that the timing is being met
[14:40:51] <tzanger> it will likely work most of the time
[14:41:13] <tzanger> but you will end up driving yourself insane wondering why once in a while it just doesn't work
[14:41:33] <tzanger> and you'll come here asking for help, and we'll have this discussion all over again ;-)
[14:41:42] <MrMobius> hehe
[14:42:10] <MrMobius> i honestly dont see why it wont work sometimes like that
[14:42:20] <MrMobius> you know the sram doesnt eed a pulse, right?
[14:42:59] <tzanger> look at the data sheet
[14:44:33] <MrMobius> i am looking at th timings. maybe i dont understand but it really looks like it reads as long as the read pin is enabled and writes as long as the write pin is enabled. i dont see it pulsing anything
[14:44:55] <tzanger> each read or write cycle is a pulse
[14:46:05] <tzanger> tdh is 0ns so you have no issues releasing at the same time
[14:46:35] <MrMobius> hmmm
[14:46:40] <MrMobius> what do you need to pulse?
[14:47:44] <tzanger> every write is a cycle
[14:47:57] <tzanger> you set up the address, pulse WP, set up the next address, pulse WP, etc.
[14:49:09] <MrMobius> WP?
[14:50:08] <MrMobius> write pulse
[14:50:09] <MrMobius> i see now
[15:02:47] <MrMobius> tzanger, why are there 2 different write cycles?
[15:02:54] <MrMobius> this dasheet is not too impressive :/
[15:09:58] <tzanger> the datasheet is good
[15:10:09] <tzanger> the read and write cycles are defined
[15:10:22] <tzanger> one is "CE-driven" and the other is "WE-driven"
[15:13:23] <OndraSter__> http://img.thedailywtf.com/images/13/amazing.png
[15:16:23] <MrM0bius> tzanger, so you can pick which one youd rather use?
[15:33:59] <beaky> my atmega16a only has two interrupts
[15:34:23] <beaky> two external interrupts*, but I have 8 pushbuttons; what should I do?
[15:35:36] <thetruthisoutthe> hey
[15:35:39] <beaky> I am thinking of connecting all my pushbuttons to an interrupt, then in the ISR I poll each pin to check which pushbutton was pressed
[15:35:42] <beaky> hello
[15:36:31] <thetruthisoutthe> you probably don't poll in an interrupt.
[15:36:38] <thetruthisoutthe> use PCINT
[15:36:49] <thetruthisoutthe> that triggers when a pin change occured
[15:37:28] <dfletcher> I'd hook them all up to one interrupt and each one also to another input pin beaky. so the interrupt tells you something happened and then you check 8 other input pins to find out which got pressed.
[15:37:46] <dfletcher> could use an io expander to save pins
[15:38:44] <dfletcher> probably best really to poll rather than that though
[15:39:07] <dfletcher> find an io expander with 8 interrupts :P
[15:39:25] <thetruthisoutthe> dfletcher<= the PCINT does that.
[15:40:02] <l9> could pcint be used on a attiny too?
[15:40:04] <dfletcher> thetruthisoutthe, well I was suggesting hooking multiple buttons to it. you would not be able to tell which one was pressed from just that, and if another got pressed while one was already down it wouldn't trigger
[15:40:43] <dfletcher> he's asking how to deal with more buttons than interrupts
[15:41:04] <thetruthisoutthe> dfletcher <= there are already 8 port pins hooked up to the PCINTs.
[15:41:22] <thetruthisoutthe> hence your dream came reality
[15:41:44] <beaky> aww I don't think atmega16a has PCINT :(
[15:41:45] <dfletcher> thetruthisoutthe, you came in after this: <beaky> my atmega16a only has two interrupts
[15:41:46] <dfletcher> <beaky> two external interrupts*, but I have 8 pushbuttons; what should I do?
[15:42:33] <dfletcher> so you're not helping to answer that question.
[15:42:49] <thetruthisoutthe> atmega48 has PCINT
[15:43:04] <thetruthisoutthe> i don't seee a reason why atmega16 don't
[15:45:29] <megal0maniac> Because 16 != 48
[15:46:40] <thetruthisoutthe> i never used that, checked the datasheet?
[15:48:55] <megal0maniac> I'm just saying they aren't the same chip, or even from the same family. There's the 48/88/168/328 and then there's the 16/32/64
[15:49:09] <thetruthisoutthe> well they are both mega no?
[15:49:20] <beaky> ah i guess I need to get a differnet atmega
[15:49:35] <megal0maniac> The mega1284 is also a mega, but that doesn't mean that the 328 also has 2 uarts
[15:50:04] <megal0maniac> And the 32u2 doesn't have i2c or adc while the 32u4 does. You can never assume anything ;)
[15:51:07] <thetruthisoutthe> hm ;/
[15:51:21] <thetruthisoutthe> seems like the mega16 does not have pcint
[15:51:34] <megal0maniac> That would be correct
[15:51:36] <OndraSter__> yes
[15:51:46] <OndraSter__> (why are people spending time on mega, when there is xmega? :P)
[15:51:54] <OndraSter__> even the cheapest xmega d4 series has got a lot of peripherals
[15:51:58] <megal0maniac> Was just about to mke fun of you
[15:51:59] <thetruthisoutthe> OndraSter__ <= no idea
[15:52:10] <thetruthisoutthe> btw i got my megas for about half price
[15:52:23] <megal0maniac> < OndraSter__> and the xmega has interrupts on all pins and even built in LEDs!
[15:52:38] <beaky> I am using mega because I don't know any better
[15:52:38] <megal0maniac> I lies about the LEDs... :)
[15:52:40] <thetruthisoutthe> xmega is x2 price, and xmega is not well suited for micropower i think
[15:52:45] <OndraSter__> xmega is not x2 the price
[15:52:50] <beaky> xmega costs as much as atmega
[15:52:51] <OndraSter__> and it can do same sleep as mega
[15:53:03] <OndraSter__> xmega costs less than mega
[15:53:08] <thetruthisoutthe> ;/
[15:53:13] <beaky> more bang for your buck :D
[15:53:17] <OndraSter__> much more
[15:53:22] <OndraSter__> a4u are very nice and cheap chips
[15:53:30] <beaky> but xmega doesn't come in noob-friendly DIP format?
[15:53:33] <OndraSter__> nope
[15:53:34] <beaky> unlike atmega
[15:53:36] <megal0maniac> beaky: The 328 is good, if you get a mega. Cheap and pretty capable
[15:53:37] <OndraSter__> my board does though :)
[15:53:39] <thetruthisoutthe> well ok, i could get xmega for $3
[15:53:44] <megal0maniac> OndraSter__: Pffft!
[15:53:53] <megal0maniac> Your xboard doesn't exist
[15:54:03] <megal0maniac> There are 3 and one is here and one is on a farm somewhere
[15:54:04] <OndraSter__> :(
[15:54:17] <megal0maniac> I do understand though
[15:54:27] <dfletcher> heh it's not real until you've made a hundred of em ;p
[15:54:27] <megal0maniac> 3 hour maths lecture tomorrow. Care to join? :P
[15:54:29] <OndraSter__> people want ARMs
[15:54:30] <OndraSter__> haha
[15:54:39] <megal0maniac> I like my xboard
[15:54:49] <OndraSter__> sitting on a shelf?
[15:54:56] <OndraSter__> btw somebody "stole" my name
[15:54:59] <megal0maniac> Right now everything is, yeah
[15:55:02] <OndraSter__> either you or rikus posted it
[15:55:09] <megal0maniac> I heard. Was Rikus
[15:55:13] <OndraSter__> hehe
[15:55:18] <OndraSter__> I want a different name for it anyway though
[15:55:26] <megal0maniac> http://i.imgur.com/sI4Givx.jpg
[15:55:27] <OndraSter__> something that hasn't got (c) or (tm) or (r) already
[15:55:36] <megal0maniac> Tell me that doesn't look like a perfect match :)
[15:55:40] <dfletcher> call it OndraSter's Super Mega Dope XMega Thing.
[15:55:45] <OndraSter__> haha megal0maniac
[15:55:46] <OndraSter__> no dfletcher
[15:56:05] <thetruthisoutthe> OndraSter__ <= happens
[15:56:11] <beaky> so even though xmega doesn't come in a DIP package, they are still easy to play with on a breadboard?
[15:56:13] <thetruthisoutthe> if you have it registered then
[15:56:16] <thetruthisoutthe> ghost it
[15:56:25] <megal0maniac> beaky: No :(
[15:57:06] <dfletcher> OndraSter__, got a link to pics, info?
[15:57:13] <megal0maniac> Until OndraSter__ gets his act together:
http://www.batsocks.co.uk/products/BreadMate/XMega%20PDI.htm
[15:57:33] <dfletcher> cute! looks familiar :P
[15:58:01] <OndraSter__> looks very similar (the breadboard version), but with bigger chip (64 pins)
[15:58:04] <OndraSter__> and built in USB
[15:58:06] <dfletcher> is that a power jack?
[15:58:09] <OndraSter__> not some crappy RS232 adapter
[15:58:09] <megal0maniac> OndraSter__: How much did I pay for xboard?
[15:58:13] <OndraSter__> 20€
[15:58:23] <OndraSter__> note that you got bigger chip :P
[15:58:41] <dfletcher> oh it's a/v out? neat.
[15:58:58] <megal0maniac> dfletcher: Yeah. They made TellyMate
[15:59:23] <megal0maniac> Serial - video on a mega328 :)
[15:59:33] <megal0maniac> Turn your tv into a console, sort of
[16:00:12] <megal0maniac> beaky:
http://i.imgur.com/Bk7ZX.jpg
[16:00:24] <megal0maniac> The original xboard coco
[16:00:49] <megal0maniac> Lots and lots of IO
[16:00:53] <dfletcher> heh breadboard hog =)
[16:01:05] <megal0maniac> It is a little, but it works
[16:02:17] <megal0maniac> OndraSter__:
http://myxboard.net/software.html :(
[16:02:33] <dfletcher> btw donno if you guys know but I used to make a similar board. closer to a teensy though. BumbleB :)
http://wtfmoogle.com/wp-content/uploads/2009/08/bumbleb-300x162.jpg
[16:02:34] <megal0maniac> Why don't I have that? Where's the customer support, man?
[16:02:56] <dfletcher> that was fun I should design something new
[16:05:23] <dfletcher> still think it would be cool to make a board with
https://www.sparkfun.com/products/11025 and battery circuitry. home brew mp3 kit.
[16:05:49] <OndraSter__> I had issues getting these mp3/midi decoders off any regular site (mouser/digikey/farnell) I think
[16:06:04] <dfletcher> yeah
[16:06:21] <dfletcher> think you have to contact vlsi and go through licensing deals etc. yuck.
[16:06:49] <megal0maniac> dfletcher: Looks a bit like this:
http://tom-itx.dyndns.org:81/~webpage/boards/USB_Breakout/USB_Breakout.jpg
[16:07:14] <dfletcher> yep close. it's an atmega32u2 breakout.
[16:07:27] <megal0maniac> So is that :)
[16:15:00] <beaky> what are the picopower avrs?
[16:15:07] <beaky> are they like ultra-low-power variants?
[16:17:08] <megal0maniac> They can be
[16:17:33] <megal0maniac> Normally they're exactly the same, but they can sleep "deeper"
[16:17:43] <beaky> ah
[16:18:50] <beaky> http://electronics.stackexchange.com/questions/52915/whats-the-difference-between-atmega1284-and-atmega1284p I guess that explains it :D
[16:19:09] <megal0maniac> Yip. Nothing you need to worry about unless you're designing for battery-powered applications
[16:19:49] <megal0maniac> "Atmega1284-pu has the window to clear the memory using UV light"
[16:19:56] <megal0maniac> Where the hell did he see that?
[16:21:03] <beaky> lol that's probably some stock image he saw from the seller website
[16:22:57] <megal0maniac> Likely. RS has been known to get it wrong from time to time
[16:23:54] <megal0maniac> The 1284p is the largest DIP chip available from Atmel. They 328 is much the same, but a single UART and less flash (and obviously far smaller)
[16:24:05] <megal0maniac> I haven't found a use for my 1284p yet
[16:24:55] <megal0maniac> In fact my favourite beginners combo is mega328p + t85
[16:25:59] <beaky> right the atemga328 is nicer
[16:27:10] <beaky> btw have any of you guys destroyed anything with static?
[16:27:32] <kline> beaky: no
[16:27:36] <megal0maniac> Not me
[16:32:08] <megal0maniac> Goodnight!
[16:42:03] <beaky> How do you pronounce ATmega328?
[16:43:16] <inkjetunito> AMIGA
[16:43:32] <beaky> ha
[16:57:51] <TechIsCool> why does this not work? pwm1 == true && TCD0.CCABUF <= 255
[16:59:03] <TechIsCool> I have also tried cca without buffer
[17:08:05] <vectory> because a left shift of 255 binary digits is is only usefull on a 256 bit variable
[17:08:41] <vectory> no wait, what? what is <= supposed to do anyway, what language is this?
[17:09:36] <kline> vectory: C(++) less than or equal too
[17:09:44] <kline> <<= 255 is the shift
[17:09:58] <kline> to*.
[17:10:42] <TechIsCool> yes
[17:11:18] <kline> TechIsCool: perhaps you should say whats not working
[17:11:32] <TechIsCool> kline: It does not evaluate as true
[17:11:45] <TechIsCool> Right now I don't have serial setup so I can't print
[17:11:56] <TechIsCool> I thought it might have been soemthing simple
[17:12:39] <kline> first thing id do personally is wrap it in (), so (pwm1 == true) && (blah <= 255)
[17:13:11] <kline> if you can use serial, use it if you dont have any other way of debugging
[17:13:47] <TechIsCool> yes
[17:55:04] <speccy88> Hey
[18:06:41] <beaky> hello
[18:44:53] <thetruthisoutthe> beaky <= ate MIG treehundredtwentyeight ?
[18:44:55] <thetruthisoutthe> :)
[18:48:18] <thetruthisoutthe> vectory <=
http://en.wikipedia.org/wiki/VHDL
[18:55:53] <sabesto> eh
[19:08:48] <Badaboom> Good evening
[19:09:19] <Badaboom> twnqx: are you here?
[19:10:25] <jadew> final version of the SPI modes explanation:
http://eenoob.com/ I know my writting isn't exciting, but I hope it's good enough to put everything in perspective
[19:11:14] <Badaboom> jadew: that actually will help me,, ty
[19:11:22] <jadew> heh, nice
[19:11:22] <jadew> np
[19:12:45] <Badaboom> Its the month of Mai?
[19:12:48] <Badaboom> lol
[19:13:07] <Badaboom> sorry,, had to point that out
[19:13:13] <jadew> hehe, thanks for pointing it out :)
[19:13:17] <Badaboom> lol,, np
[19:13:18] <jadew> will fix that function
[19:13:23] <Badaboom> rgr
[19:15:31] <jadew> fixed, it was in romanian
[19:17:27] <Badaboom> lmao
[19:17:58] <Badaboom> so i got to spend all day working on a tube power supply and pre for a local musician
[19:18:07] <Badaboom> exciting i know
[19:18:08] <jadew> w|zzy, I made a small help file documenting the JS API for the OLSFront, in case you're interrested in making your own parsers:
http://dumb.ro/lafront/OLSFront.chm
[19:18:36] <jadew> since they posted that thing on the blog, I got quite a few downloads and someone complained about the lack of API documentation :P
[19:18:47] <jadew> Badaboom, hah
[19:19:00] <w|zzy> Awesome :D
[19:19:18] <jadew> tubes as in
http://img.diytrade.com/cdimg/855015/7894486/0/1233356404/Vacuum_tubes_and_Sockets.jpg
[19:19:21] <jadew> ?
[19:21:53] <jadew> the guy who complained about the missing API docs actually went ahead and figured out how to build a parser by himself, which is pretty cool
[19:30:27] <w|zzy> indeed
[19:32:02] <w|zzy> gues he had access to a few examples
[19:32:50] <jadew> yeah, I threw a few comments in the protocol parsers just for that
[19:33:19] <Badaboom> jadew: lol
[19:35:13] <Badaboom> jadew: yep,, those kinds
[19:35:26] <Badaboom> 208a power supply
[19:35:26] <jadew> didn't know people are still using them :)
[19:35:36] <Badaboom> oh yeah,, huge in the musical world
[19:35:46] <Badaboom> this guy insists on them
[19:36:15] <jadew> my on board audio card sounds just fine :P
[19:36:15] <Badaboom> high voltage tho:(
[19:36:20] <Badaboom> lol
[19:36:47] <jadew> well, it's not on board, but it's a cheappie
[19:38:26] <jadew> Badaboom, are they used in studios and stuff? or just in high-end consumer stuff?
[19:38:52] <jadew> using the same word, twice in a sentence == I'm tired
[19:39:30] <Badaboom> studio
[19:39:37] <jadew> I see
[19:39:40] <Badaboom> ill show u,, one sec
[19:40:02] <jadew> well, it kinda makes sense for high voltage stuff to produce less noise
[19:41:04] <jadew> 50mV of noise is a lot more in a 3.3V system than it is in a 20V one
[19:41:16] <Badaboom> longevin 208-a power supply and...
[19:42:28] <Badaboom> http://www.google.com/imgres?imgurl=http://auxsend.net/preampsandeqs/wp-content/uploads/2011/06/RCA-BA-21A-_02.png&imgrefurl=http://auxsend.net/preampsandeqs/tag/rca-ba-21a/&h=544&w=722&sz=490&tbnid=Q-A0g8jKd7vJEM:&tbnh=112&tbnw=149&zoom=1&usg=__bejuS5kxlfB_mRQMyKTi-FiH86g=&docid=wB_Y8hN389z5RM&sa=X&ei=oAWgUf-fMoSo9gSS04HICA&ved=0CDQQ9QEwAg&dur=453
[19:42:37] <Badaboom> lol,, wow thats a long link
[19:42:50] <jadew> works tho
[19:43:32] <jadew> looks old school
[19:43:38] <Badaboom> very:)
[19:44:01] <Badaboom> mounted it with a voltage divider then out to that form the power supply
[19:44:08] <Badaboom> from
[19:44:35] <Badaboom> kept wondering where the hell the hex file goes
[19:44:38] <Badaboom> lmao
[19:44:47] <jadew> heh
[19:52:19] <Badaboom> I need to knuckle down this weekend and print up some boards,, but with a good method
[19:52:34] <Badaboom> gonna need some fine drill bits too
[21:49:19] <Badaboom> SPCR= SPIE SPE DORD MSTR CPOL CPHA SPR1 SPR0 corretc?
[22:12:09] <robotustra_> hello
[22:12:51] <robotustra_> I have a question about Atmega32U4 breakout sparkfun board
[22:13:02] <robotustra_> anybody can help me with it?
[22:13:02] <Badaboom> Ill try:)
[22:13:11] <Badaboom> whats up?
[22:13:34] <robotustra_> 1 moment
[22:14:05] <robotustra_> It's with ISP inside
[22:14:18] <Badaboom> let me pull it up
[22:14:42] <robotustra_> I uploaded demo blink hex file with the use of AVRDUDE
[22:14:59] <robotustra_> and I tested the output PORTD5
[22:15:04] <robotustra_> it works
[22:15:05] <robotustra_> but
[22:15:30] <robotustra_> if I unplug it and plug USB again - there is no activity
[22:15:35] <Badaboom> well ISP refers to IN System Programming which all avr's have
[22:15:52] <robotustra_> it's LUFA
[22:16:02] <robotustra_> ISP I think
[22:16:06] <Badaboom> the USB is providing the power
[22:16:13] <Badaboom> lemme look at the schematic
[22:16:13] <robotustra_> yes
[22:16:23] <robotustra_> 1 sec
[22:16:46] <robotustra_> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/AVR/32U4_Breakout-v11.pdf
[22:16:53] <Badaboom> I have it already:)
[22:17:43] <robotustra_> If I unplug USB and put 5 VDC from external power supply - the situation is the same
[22:17:58] <robotustra_> I press reset - no activity
[22:18:16] <robotustra_> If I reprogram it - evrything works fine
[22:18:59] <robotustra_> until I reset or retconnect power
[22:19:33] <Tom_itx> does the bootloader twiddle with the wdt
[22:19:44] <Tom_itx> it may be resetting
[22:20:16] <robotustra_> 1 sec
[22:20:21] <Tom_itx> also what's the state of the HWB pin?
[22:20:23] <Badaboom> I ran into this recently
[22:20:37] <robotustra_> When you power the board on, your application will run by default. If there's no application in program memory then the bootloader will run. If you have an application already on the IC and you want to reprogram, simply press the on-board reset button and the bootloader will run for 7 seconds to allow time for programming.
[22:20:48] <robotustra_> this is written on the site
[22:21:10] <robotustra_> but I don't see this behaviour
[22:21:38] <robotustra_> hm
[22:22:10] <robotustra_> Tom_itx my watchdog is disabled
[22:22:13] <Tom_itx> did you overwrite the bootloader by uploading the program with avrdude?
[22:22:16] <Badaboom> Ide have to say wdt
[22:22:35] <robotustra_> Tom_itx no
[22:22:47] <Tom_itx> how do you know?
[22:23:28] <robotustra_> because if I unplug and plug the board again - windows recognize LUFA CDC
[22:23:37] <robotustra_> and load virtual com port
[22:23:44] <Tom_itx> MCUSR &= ~(1 << WDRF);
[22:23:44] <Tom_itx> wdt_disable();
[22:23:51] <Tom_itx> should be in your file
[22:24:06] <Tom_itx> Disable watchdog if enabled by bootloader/fuses
[22:24:14] <robotustra_> I'll try
[22:24:24] <Tom_itx> at the top of main
[22:24:30] <robotustra_> ok
[22:24:38] <Tom_itx> also
[22:24:48] <Tom_itx> #include <avr/wdt.h>
[22:24:53] <Tom_itx> above main
[22:25:16] <Badaboom> Tom_itx: is the attiny2313 a software spi ?
[22:25:25] <robotustra_> thanks, I'll try
[22:25:51] <Tom_itx> Badaboom, i dunno without looking
[22:26:00] <inflex> lo there Tom_itx
[22:26:05] <Tom_itx> hi inflex
[22:26:38] <inflex> how's things going for you over tehre?
[22:26:52] <Badaboom> yeah,, ilooked at several datasheets including the 2313 and it will work with utility mode but i dont believe it to be a true hardward spi
[22:27:41] <Tom_itx> inflex, doin ok i guess
[22:27:57] <robotustra_> Tom_itx - didn't help
[22:28:06] <robotustra_> the same behavior
[22:28:37] <Tom_itx> MCUCR = (1 << JTD); // disable jtag MCUCR = (1 << JTD); // disable jtag
[22:28:42] <robotustra_> after reset or disconnect of the power does not bypass loader
[22:28:50] <Tom_itx> try that then
[22:28:59] <Tom_itx> just below the wdt disable code
[22:29:15] <robotustra_> sec
[22:29:27] <Tom_itx> needs to be there twice
[22:31:43] <Badaboom> Im wondering if i shoouldnt just migrate to the atmega328
[22:31:53] <Tom_itx> why?
[22:32:28] <robotustra_> nothing
[22:32:38] <Badaboom> Well, i have this one working,, problem is i think it might be limited after i get all the code in
[22:32:41] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/atmega32U4/
[22:32:48] <Tom_itx> robotustra_, those work on the U4
[22:32:51] <Tom_itx> i've tried them
[22:35:03] <robotustra_> the same thing
[22:35:12] <robotustra_> I get hex file - upload
[22:35:29] <robotustra_> after power retraction - doesn't work
[22:36:00] <robotustra_> let me read something form memory
[22:36:56] <robotustra_> If I burn the board - and try to burn it again without retracting USB it say could not find port bla bla bla
[22:37:26] <robotustra_> it means that bootloader stops working
[22:37:53] <robotustra_> I think it stuck somewhere in ISP
[22:38:12] <robotustra_> but I don't know yet how to bypass it
[22:38:15] <Tom_itx> is HWB tied to gnd?
[22:38:47] <Tom_itx> if it is and you push reset, it will put it into bootloader mode
[22:38:50] <robotustra_> what is HWB
[22:38:57] <Tom_itx> read the data sheet
[22:39:03] <robotustra_> ok
[22:39:12] <Badaboom> needs to be tied to + with 10k
[22:39:18] <Tom_itx> it's how you get it into bootloader mode by default
[22:39:34] <robotustra_> what pin?
[22:39:35] <Tom_itx> Badaboom, not necessarily
[22:39:40] <Tom_itx> HWB
[22:40:08] <Badaboom> oh ,,ok
[22:40:25] <Tom_itx> PE2
[22:41:00] <robotustra_> pin 33
[22:42:27] <Badaboom> correct
[22:43:28] <robotustra_> it shows 0
[22:43:32] <robotustra_> gnd
[22:43:52] <Tom_itx> so if you push reset, it will go into bootloader mode
[22:44:52] <Tom_itx> if you remove that connection you will need to manually put it to gnd and push reset to enter bootloader mode
[22:45:22] <Tom_itx> i tie it to gnd on my programmers and use reset as the 'program' button
[22:46:03] <Tom_itx> but that's not always desireable
[22:46:24] <robotustra_> hm
[22:46:40] <robotustra_> I don't think I can do this on this board
[22:46:40] <Badaboom> Tom_itx: im gonna make this work,, ill just leave ss as pb4 to the load (cs)
[22:46:49] <Tom_itx> check your schematic and read the data sheet
[22:50:43] <Badaboom> He can't do that on that board i dont believe
[22:50:52] <Badaboom> im looking at the schematic
[22:51:18] <robotustra_> oh
[22:51:24] <robotustra_> I have one idea
[22:51:40] <robotustra_> what If overwrite bootlaoder
[22:51:54] <robotustra_> but this memory is protected
[22:52:06] <Badaboom> robotustra_: is there a switch on the reset line?
[22:52:06] <robotustra_> and after reboot it's restored?
[22:52:12] <robotustra_> yes
[22:52:19] <Badaboom> what position is it in?
[22:52:28] <Badaboom> and have you changed it?
[22:52:34] <robotustra_> oh no it's a button
[22:52:39] <Badaboom> hmm
[22:53:23] <robotustra_> but butloader should write program to higher adresses
[22:53:40] <robotustra_> I don't know
[22:53:46] <robotustra_> have to think
[22:54:31] <Badaboom> ok,, nme,, its s1 in the schematic,, but its the reset button
[22:54:50] <robotustra_> The HWB mode of this pin is active only when the HWBE fuse is enable.
[22:55:41] <robotustra_> how to check my fuse?
[22:56:41] <Badaboom> Im no expert but ide leave those for now
[23:00:04] <robotustra_> I use avrdude from console
[23:01:06] <Badaboom> robotustra_: i looked at both the schematic and brd file and HWB is NOT connected
[23:01:56] <robotustra_> I touch it with the probe
[23:02:04] <robotustra_> with oscilloscope
[23:02:30] <Badaboom> ok well,, its not connected to anything according to the schematic and eagle file
[23:02:40] <robotustra_> avrdude gives me:
[23:02:41] <robotustra_> avrdude.exe: safemode: lfuse reads as DE
[23:02:41] <robotustra_> avrdude.exe: safemode: hfuse reads as D8
[23:02:41] <robotustra_> avrdude.exe: safemode: efuse reads as FB
[23:02:41] <robotustra_> avrdude.exe: safemode: lfuse reads as DE
[23:02:41] <robotustra_> avrdude.exe: safemode: hfuse reads as D8
[23:02:41] <robotustra_> avrdude.exe: safemode: efuse reads as FB
[23:03:01] <robotustra_> What the hell safemode
[23:03:38] <robotustra_> I use avrdude.exe -p m32u4 -c avr109 -P com16 -C avrdude.conf -U flash:w:a32u4.hex -v -v -v -v
[23:05:03] <Badaboom> ok actually,, the print was small but it does show it going to ground but couldnt see it in the brd file
[23:05:53] <robotustra_> Found programmer: Id = "LUFACDC"; type = S
[23:05:53] <robotustra_> Software Version = 1.0; No Hardware Version given.
[23:07:57] <robotustra_> thank you for your help
[23:09:07] <robotustra_> I think it will be long debug
