Back
[00:29:41] <ziph> Those multi-word register tricks are annoying.
[00:30:01] <ziph> They should just burn a few flip flops having an intermediate register and a control bit to transfer that to the real one.
[00:34:41] <jadew> any idea how you do a jnz in avr asm?
[00:35:19] <jadew> I only see rjmp and ijmp in the instructions list
[01:02:19] <nevdull> jadew: maybe like CP r1, r2 then BREQ addr
[01:03:47] <jadew> I think the one I'm looking for is BRNE
[01:03:53] <jadew> weird names
[01:04:27] <jadew> thanks for that, I completely ignored that section
[01:05:05] <Kevin`> how do you plan to better code than a compiler if you don't know ALL of the instructions? ;p
[01:05:34] <bemasher> i'm wondering, is there a simple metric to figure out how much flash you might need for a particular program to fit into an ATtiny##?
[01:05:41] <jadew> not planning to better code, just testing
[01:05:46] <nevdull> jadew: BREQ jumps if Z = 1 and BRNE if Z = 0
[01:05:54] <nevdull> jadew: oh sure thing
[01:05:56] <jadew> and I don't have to know the instructions, I already know what I want to do ;)
[01:06:03] <jadew> I can look up how to do it after
[01:10:02] <jadew> about the debug wire protocol
[01:10:18] <jadew> it's not implemented in any DIY programmers, is it?
[01:11:00] <Kevin`> I think there's one guy here who reverse engineered that
[01:11:08] <jadew> oh, he succeded?
[01:12:15] <jadew> I was the impression he gave up, if nobody did it, maybe someone would like to take out the firmware out of a simple but dW enabled programmer
[01:12:43] <jadew> it should be fairly easy to figure out how to work with it from that
[01:13:59] <Kevin`> he had notes on the protocol and instructions
[01:14:18] <Kevin`> i'm not sure whether he made an avrstudio-compatible debugger device or such
[01:15:38] <jadew> would be cool to have that functionality in usbtiny
[03:51:43] <pingec> how would I negate (toggle) the third bit in PORTB in asm?
[03:57:07] <grummund> pingec: on most atmega you can sbi the relevant bit in PINB
[03:57:28] <ziph> He wants to toggle it, not set it.
[03:57:34] <grummund> yes
[03:59:17] <grummund> setbit PINx avoids the read-modify-write on PORTx to toggle an output.
[04:00:22] <pingec> I'm just learning this, is there an easy way to find out which registers support a certain operation?
[04:01:21] <grummund> the datasheet?
[04:01:47] <pingec> teh datasheet is quite big
[04:01:58] <ziph> grummund: SBI makes the register bit 1 regardless of if it is 1 or 0. Toggling implies both 0 -> 1 and 1 -> 0.
[04:02:29] <pingec> I mean, couldn't avr studio suggest a list of registers, when i type in "mov" ?
[04:02:40] <pingec> :D
[04:02:51] <grummund> ziph: i know.
[04:03:18] <grummund> ziph: on most atmega you can set bit in PINx to toggle PORTx.
[04:03:29] <ziph> pingec: There aren't that many restrictions, it isn't like x86.
[04:03:54] <ziph> Oh, I was looking at where you said PORT.
[04:04:12] <ziph> pingec: MOV should work for any register for instance.
[04:04:25] <pingec> ok
[04:04:34] <pingec> what is PORTB ?
[04:04:37] <pingec> is it not a register?
[04:04:44] <ziph> No, it isn't/
[04:04:45] <ziph> .
[04:05:03] <pingec> what is it?
[04:05:22] <pingec> grummund thanks, i will try it now
[04:05:52] <ziph> It's a port.
[04:06:32] <Kevin`> it's a register that controls a port, but it's no a cpu register
[04:06:48] <pingec> I see
[04:07:09] <ziph> It may not be a register though.
[04:07:13] <pingec> So I can only set or clear it?
[04:07:17] <pingec> That's it?
[04:07:35] <ziph> You can have ports that just work on the fact that there's a write or read cycle to them.
[04:07:58] <Kevin`> pingec: you can define it, and toggle it in some cases. also you can use memory operations on it
[04:08:36] <pingec> How would I get the values in PORTB into a cpu register?
[04:11:15] <Kevin`> lds? iono, I don't do asm
[04:15:23] <grummund> ldi r25,0x08; in r24,PORTB; eor r24,r25; out PORTB,r24;
[04:15:38] <grummund> at a guess...
[04:16:25] <ziph> pingec: Making GCC compile small code snippets and looking at the assembler output is a good way to go about this.
[04:16:34] <ziph> pingec: Are you using assembler for some specific reason?
[04:17:35] <pingec> yes, I want to learn it
[04:17:53] <grummund> but equally you could do sbi PINB,3;
[04:18:08] <pingec> kk
[04:18:11] <Kevin`> grummund: ah, I wonder how I missed "IN" :)
[04:18:35] <ziph> pingec: You could either get some small well documented assembler samples (e.g. from application notes) or look at the compiler output.
[04:18:57] <Kevin`> pingec: not all of the not-cpu-registers can be accessed by the io-specific functions, btw. use them when possible of course
[04:19:31] <pingec> ok
[04:19:51] <pingec> I wish there were smart intellisense :D
[04:20:07] <grummund> Ahem. :P
http://pastebin.com/iDdwNw9f
[04:21:05] <Kevin`> grummund: what does it generate for PINB=0x08; ?
[04:22:02] <pingec> nice
[04:22:07] <pingec> how do I do this?
[04:22:24] <pingec> Do i just create a C project and then open the generated .asm?
[04:22:39] <grummund> pingec: are you using avrstudio?
[04:22:39] <pingec> I better try it
[04:22:42] <Kevin`> grummund: do you know how to generate that output with the CLI utilities, btw?
[04:22:42] <pingec> yes
[04:22:45] <pingec> avr studio 5
[04:23:14] <grummund> pingec: the default Makefile should cause a .lss file to be generated, look at that.
[04:23:34] <pingec> one more question
[04:23:50] <grummund> only one?
[04:24:00] <pingec> I see I can create conditional breakpoints
[04:24:17] <pingec> what expression do I write
[04:24:26] <pingec> to check for a value in r25 ?
[04:24:39] <pingec> r25 == 0xFF ?
[04:25:00] <grummund> pingec: sounds like you need to look for an asm tutorial
[04:25:23] <grummund> pingec: did you look at the tutorials forum at avrfreaks.net ?
[04:25:28] <pingec> no i mean in the conditional breakpoint expression
[04:25:47] <grummund> Kevin`: avr-objdump -h -S file.elf > file.list
[04:26:15] <pingec> ok "r25 == 0xFF" does work
[04:26:18] <pingec> sweet
[04:31:00] <Kevin`> http://pastebin.com/VXxfaZ7W - this is why you use c. you can tell it to do crazy shit and it just works (32bit numbers). yeah, it's not super efficient, but you don't have to spend an hour trying to optimize something that only runs a few times
[04:31:52] <Kevin`> the whole application is full of stuff like that actually. I wonder what the average instructions-per-line is
[04:39:42] <pingec> :o
[04:39:55] <pingec> now i am scared :(
[04:41:27] <Kevin`> don't be too scared, it's easy to avoid stuff like that happening if you don't want it
[04:42:05] <pingec> I want to make it echo stuff via usart
[04:42:21] <pingec> this will be my next goal
[04:42:23] <Kevin`> the usart is pretty easy to control
[04:42:55] <pingec> I am reading the website from the topic
[04:43:05] <pingec> it's very nice to read
[04:43:21] <Kevin`> you have the datasheet open too, right?
[04:43:36] <pingec> Well I printed out the instructions
[04:43:47] <pingec> yes i have it open
[04:44:43] <pingec> For usart I should use an external crystal?
[04:44:49] <Kevin`> you can probably get it sending data easy enough from just the datasheet. assuming you got your blinky port from before working
[04:44:58] <pingec> :D
[04:45:59] <pingec> I've read there's some % of error on uart when using the internal oscillator
[04:46:06] <pingec> what does that mean in practice?
[04:46:20] <pingec> If the error is let's say 0.2%
[04:46:34] <Kevin`> 0.2% is within the acceptable range, and data will flow properly
[04:46:54] <Kevin`> the error is about frequency offset, not bit loss or something
[04:47:05] <pingec> Cause I've bought an external crystal
[04:47:14] <pingec> But not really sure how to connect it
[04:47:19] <pingec> looking at the datasheet
[04:47:23] <ziph> Use the external crystal if you've got it.
[04:47:55] <Kevin`> do you have something to generate a clock signal if you screw up the crystal connection or configuration?
[04:48:04] <ziph> Although at 0.2% and given that you sound new to it you might want to stick with the internal one to avoid having to set fuses. ;)
[04:48:32] <pingec> Hmm ok
[04:48:42] <pingec> But just to know
[04:48:49] <pingec> I just need the crystal and 2 caps?
[04:48:54] <ziph> Yeap.
[04:49:06] <ziph> Are you using the Windows IDE?
[04:49:16] <pingec> yes
[04:49:30] <ziph> You should be fine then with fuses, just make sure you've read the datasheet carefully about them first.
[04:50:12] <pingec> In the datasheet it mentions full swing and low power crystals
[04:50:20] <pingec> but I have no idea which one I have
[04:51:37] <grummund> pingec: btw, which AVR and what are you using for a programmer?
[04:52:15] <pingec> ATmega168A
[04:52:18] <pingec> AVR Dragon
[04:53:06] <Kevin`> avr dragon you can recover from anything, with varying annoyances in connecting wires
[04:53:21] <pingec> good to know
[04:53:21] <grummund> i can't remember, does the dragon do HV programming?
[04:53:30] <Kevin`> yes
[04:53:45] <pingec> it says HVPP
[04:54:03] <grummund> in that case it can recover if you bork the fuses :)
[04:54:14] <pingec> Why is that?
[04:54:23] <pingec> Is there a simple way of explaining why :D?
[04:54:43] <pingec> I mean what's the difference between ISP and HVPP
[04:54:48] <grummund> the conventional method of programming is using ISP
[04:54:49] <Kevin`> pingec: the high voltage programming interface will work even if isp is disabled, the reset line is disabled, and the chip is set to use an external clock input that doesn't exist
[04:55:04] <pingec> oooh
[04:55:06] <Kevin`> speaking of, don't disable isp or the reset line
[04:55:16] <grummund> it's possible to disable ISP by setting wrong fuses, so HVPP can recover from that.
[04:55:26] <pingec> I can do that by messing with fuses?
[04:55:32] <Kevin`> yes
[04:55:35] <pingec> ah
[04:55:38] <ziph> Linux freetard newbies often mess up setting the fuses and put their AVR in a state where only HV or an external clock source will work.
[04:55:55] <pingec> :(
[04:56:04] <pingec> I'm happy I got the Dragon then
[04:56:05] <scuzzy> gotta start learning somewhere
[04:56:21] <grummund> pingec: people often mess up the fuses. although with avrstudio it is less easy to get wrong.
[04:56:21] <pingec> I bought it because it said it supported debugwire
[04:56:36] <ziph> People that use the Windows tools don't seem to have the same issue learning though, scuzzy. :)
[04:56:40] <scuzzy> calling people retards for making mistakes in the early stages is hardly fair
[04:57:06] <pingec> kudos to them for using linux
[04:57:07] <Kevin`> debugwire is kind of nice, only the isp connector needed (less technically). jtag works fine too though.
[04:57:09] <ziph> scuzzy: Are you calling freetards retards? I'm not sure they'd be happy with that.
[04:57:19] <ziph> pingec: Yeah, DebugWIRE is really worth it.
[04:57:53] <scuzzy> ziph: no, I'm just pointing fingers at you
[04:57:55] <ziph> pingec: Especially since if you can use ISP like you are now, you're already set up for DebugWIRE.
[04:58:08] <pingec> Really?
[04:58:13] <ziph> pingec: Yeap.
[04:58:15] <pingec> How do I "launch" it ?
[04:58:32] <pingec> run
[04:58:45] <ziph> pingec: You enable DebugWIRE on the specific AVR and the hit the run button.
[04:59:08] <pingec> Under debugging
[04:59:13] <ziph> pingec: (And you have to switch the target to DebugWIRE, otherwise it'll use the simulator).
[04:59:13] <pingec> I can select AVR simulator
[04:59:14] <ziph> Yeap.
[04:59:14] <pingec> or
[04:59:20] <Kevin`> you don't enable the debugwire fuse manually with avrstudio btw. it'll git into a semi-confused state from that. it does it itself
[04:59:25] <ziph> scuzzy: I didn't call anyone a retard.
[04:59:29] <ziph> scuzzy: You did.
[04:59:40] <pingec> So I just select the right debugger?
[04:59:52] <scuzzy> my missunderstanding of the term "freetard"
[04:59:59] <pingec> AVR Dragon (some numbers) instead of AVR simulator ?
[05:00:06] <inflex> lo folks
[05:00:22] <pingec> Well I have a lot of things to try now
[05:00:22] <ziph> Speaking of freetards (*grin/duck/run*)
[05:00:25] <ziph> ;)
[05:00:32] <pingec> Thank you all for the info
[05:00:33] <ziph> pingec: Yeap, plus you have to set the AVR to use DebugWIRE too.
[05:00:40] <ziph> inflex: 'lo
[05:01:37] <scuzzy> you talkin to me?
[05:01:46] <scuzzy> have I ever expressed freetard tendencies?
[05:02:02] <ziph> scuzzy: Did you wife leave you an hour ago or something?
[05:02:19] <scuzzy> Uhhhh nope...
[05:02:29] <scuzzy> it was a genuine question
[05:02:34] <scuzzy> I basically don't wanna be an ass
[05:02:42] <Kevin`> what's a "freetard"? I use linux most of the time, but I use it because it works, and I also have windows
[05:02:46] <scuzzy> tell me if I am expressing freetard tendencies, and I'll try stop
[05:02:47] <scuzzy> (;
[05:03:17] * inflex looks for more stuff to flog off on eBay
[05:03:48] <ziph> What kinda stuff?
[05:09:51] <pingec> these lockbits are a mechanism to prevent some third party from reading the code from the chip?
[05:10:19] <grummund> yes
[05:10:28] <pingec> Is this hackable?
[05:10:31] <Kevin`> yeah, some companies do that because they think uc code is worth something. or to make it take a day longer for china to clone it :)
[05:10:48] <pingec> So there are ways to still read it?
[05:11:16] <Kevin`> pingec: you have to open the chip and manually modify parts of it with a laser
[05:11:25] <pingec> :O
[05:11:48] <pingec> And chinese labs can do that without damaging it?
[05:11:55] <Valen> or some duct tape and a light
[05:11:59] <Valen> you know whatever
[05:12:04] <pingec> lol?
[05:12:26] <Kevin`> Valen: that would be pretty hard to do without accidently erasing data instead of lockbits
[05:12:35] <Valen> thats how the guy did it the first time
[05:12:43] <Kevin`> lol
[05:12:44] <Valen> they have a metal shield over the lock bits
[05:12:59] <Valen> so he put some black electrical tape over the die
[05:13:01] <inflex> ziph: in all honesty, anything really that will sell
[05:13:17] <ziph> inflex: :(
[05:13:18] <Valen> and used a UV eraser at a big angle to bounce under the shield and erase the fuses
[05:13:47] <ziph> inflex: Is the cat concerned about this?
[05:14:12] <inflex> hahah, fortunately not - I won't be selling the kids :)
[05:14:29] <pingec> but you have to open the chip up to erase that?
[05:15:02] <ziph> You eat it away.
[05:15:06] <Valen> yeah they disolve the plastic(ish) part of the chip with a bunch of acids and such
[05:15:14] <pingec> oh
[05:15:17] <pingec> Very smart
[05:15:19] <Valen> put it this way, its not trivial
[05:15:23] <ziph> Fuming nitric works a treat.
[05:15:34] <pingec> I have that
[05:15:37] <pingec> could try :D
[05:15:38] <Valen> yeah don't slip or it'll be the last treat you ever see ;-P
[05:15:58] <Valen> if its got anything other than credit card information in it its probably easier to just re-write it
[05:16:02] <pingec> will the chip still work without the casing ?
[05:16:09] <inflex> Don't forget to use some hydroflouric acid too
[05:16:10] <Valen> for a while
[05:16:11] <Kevin`> credit card information is cheap
[05:16:20] <pingec> No it's empty
[05:16:27] <pingec> I just wonder what's inside
[05:16:35] <ziph> Kevin`: Trials involving AVR's and credit card information aren't cheap though.
[05:16:38] <Kevin`> pingec: yes, the chip will still work without the casing. be careful of uv light erasing eeprom/flash.
[05:16:48] <pingec> lol
[05:16:55] <Valen> Kevin`: yeah but cracking the crypto on the line from the bank to the POS terminals wouldn't be
[05:17:14] <ziph> You don't crack that part of it.
[05:17:15] <pingec> I will try dissolving one
[05:17:16] <pingec> one day
[05:17:32] <ziph> You crack it before it gets encrypted.
[05:17:35] <pingec> And make a custom casing
[05:17:43] <pingec> transparent
[05:18:28] <Kevin`> Valen: crypto is either an open standard or broken. and the keys are stored on chips with a bit more attention to physical security, if they are smart
[05:18:37] <pingec> Are there any photos of what an avr looks inside?
[05:18:41] <ziph> They aren't all that smart.
[05:18:53] <Valen> ziph: if you read the code out of the IC's you get the private keys, you can then read the traffic over the wire without being at the terminal
[05:19:04] <ziph> The weakest (which are usually the cheapest) bank terminals usually get picked on.
[05:19:20] <Valen> given a decent % of info goes over wireless these days there is room to make a decent chunk of coin on that
[05:19:20] <ziph> You don't usually have to try that hard.
[05:19:39] <Valen> whats the bet all the ATM's have the same private key in them? ;->
[05:19:44] <grummund> pingec:
http://blog.makezine.com/archive/2009/07/how-to-dissolve-ic-packages.html
[05:19:50] <ziph> The largest EFTPOS fraud in Australia required zero encryption or IC level reverse engineering.
[05:20:33] <pingec> grummund thanks
[05:20:35] <pingec> looks cool
[05:20:41] <pingec> but what happened to the pins
[05:21:16] <ziph> The pins don't go all the way into the package, they're connected by fine gold bonding wires.
[05:21:50] <inflex> ja, really, social engineering is a much easier way to make the $$$
[05:22:09] <Kevin`> pingec: don't dissolve the part of the package that holds the pins, if you want it to keep working
[05:22:23] <pingec> kk
[05:22:31] <Kevin`> (it will technically work, but you'll just have the bonding pads and wires)
[05:23:00] <pingec> so everything can be reversed
[05:23:04] <karlp> indeed.
[05:23:06] <pingec> good to know
[05:23:12] <karlp> except for the service you provide to your customers
[05:23:23] <pingec> yep
[05:23:29] <pingec> and remote services
[05:23:45] <karlp> so instead of spending two weeks reviewing lock bits and readout protection and debugging encrypted firmware updates,
[05:23:45] <pingec> well yea, what yo usaid
[05:23:55] <ziph> And women.
[05:24:01] <karlp> just focus on making a better product
[05:24:01] <ziph> No one has managed to reverse engineer those.
[05:24:08] <pingec> haha
[05:24:11] <karlp> realdolls? ;)
[05:25:03] <pingec> Well we have their code
[05:25:07] <ziph> Doing the woman thing right should involve less cleaning for you, not more. ;)
[05:25:08] <pingec> but it's too hard to debug
[05:25:11] <pingec> lol
[07:04:19] <jadew> hey guys, can someone walk me trough how debugWire gets enabled/disabled when debugging from avr studio? (I don't have a dW enabled programmer, but I want to enable DWEN to study it)
[07:05:03] <jadew> so, let's say you start debugging, it sets DWEN to 1, you do the debugging and when you're done it rewrites the fuses with DWEN to 0?
[07:05:31] <jadew> what happens if your PC crashes during debugging, can you still turn DWEN off with out a HVP?
[07:15:37] <ziph> jadew: It turns DWEN off via DW.
[07:16:16] <ziph> jadew: As soon as DWEN is on you can't use the normal ISP code or ISP fuse interfaces.
[07:16:22] <jadew> any idea if it does it by disabling it via dW and then writing the fuses or if it's doing it by actually setting the fuse trough dW?
[07:17:10] <ziph> I don't think there's some volatile DW enabled flag anywhere.
[07:17:21] <jadew> I see
[07:18:00] <ziph> Otherwise it wouldn't bother with the fuse.
[07:18:07] <jadew> true
[07:18:23] <jadew> I'm gonna try to play with it a bit later
[07:18:44] <ziph> Besides, DW uses the reset line for signaling.
[07:19:03] <jadew> yeah
[07:19:11] <ziph> (The fan out/fan in on the reset line of an AVR must be amusingly large)
[07:19:30] <jadew> wonder how hard would it be to write an emulator for one of the atmel programmers, to use with avr studio
[07:20:00] <ziph> Someone in here had DW fairly well reverse engineered.
[07:20:05] <jadew> I know
[07:20:12] <jadew> luckly I've been ideling here for about 2 years
[07:20:19] <jadew> and I just finished reading the log lol
[07:20:31] <jadew> rikusw
[07:20:41] <ziph> There are logs online by the way.
[07:20:49] <jadew> I like to keep my own
[07:21:28] <jadew> anyway, apparently communicating over dW isn't such a big issue, the question is how is avr studio communicating with the programmers
[07:21:46] <ziph> I don't, and I'm not sure 15 years of IRC logs would be that manageable anyhow. ;)
[07:21:51] <jadew> would it just send the commands that the programmers need to forward to the avr, or it would send something else and the programmers would translate them
[07:22:05] <ziph> jadew: USB eavesdropping is cheap now.
[07:22:29] <jadew> true, but I don't have a debugWire programmer to fiddle with
[07:22:32] <ziph> jadew: If you tap that plus the serial traffic (with an understanding of the serial traffic) I doubt you'd have much trouble.
[07:22:54] <ziph> jadew: Get USB dumps from someone with one then.
[07:23:54] <ziph> jadew: It wouldn't surprise me if it was just a thin framing around the DW traffic.
[07:24:08] <jadew> I'll deffinitely look into it, if I decide to go on with this, I'll ask for help, right now I don't even know what I might need
[07:24:13] <ziph> Or even just raw DW over a specific port.
[07:24:19] <jadew> ziph, that's what I'm thinking it is too
[07:24:43] <ziph> jadew: I can capture USB using a hardware analyzer if you think you're likely to get anywhere with it.
[07:25:11] <jadew> I'll have to take a look at avr studio, I'm sure I can find some useful info in their binaries
[07:25:41] <ziph> They use an off the shelf USB driver, you could probably intercept the API calls to that.
[07:25:44] <jadew> thank you for the support, I'll let you know when the time comes
[07:26:22] <jadew> would be a bit more difficult like that, than by sniffing their code
[07:26:37] <jadew> because by looking at the usb traffic, you'd have to first decode the message envelope
[07:26:44] <jadew> not such a big deal
[07:27:00] <jadew> but it's certianly easier to see the function they're using to send the data :P
[07:27:04] <ziph> USB formats tend to be very guessable though.
[07:28:11] <jadew> yeah, especially since they wanted to keep the protocol very brief, to leave room for other stuff
[07:28:31] <jadew> at least I hope they took that into account
[07:29:01] <jadew> (leave room in the controllers driving the programmers, not in the usb packets)
[07:29:19] <ziph> And make sure you write it for LUFA so that Tom_it*x can make his programmers support it. ;)
[07:30:45] <jadew> heh, I'll see where this goes, might have to attach it to an already existing project, or simply create a stand alone interface
[07:31:23] <jadew> anyway, if I get avrstudio to work with it, it can probably be implemented anywhere
[07:31:47] <jadew> my target device would be usbtiny, which uses v-usb tho
[07:32:33] <jadew> but the emulator would basically have to provide a set of api calls for avr studio and send the data to the programmer, whichever it is
[07:32:49] <jadew> and the programmer send it further over dw to the target
[07:32:55] <jadew> doesn't sound like much
[07:33:02] <karlp> famous last words :)
[07:33:06] <jadew> lol
[07:33:25] <ziph> Oh, you don't want to emulate it at the USB level?
[07:34:01] <jadew> not sure yet
[07:34:19] <jadew> will have to take a look around avr studio to see how it works with stuff
[07:34:23] <ziph> A software patch over AVR Studio would be kind of annoying.
[07:34:39] <jadew> I guess that's true
[07:36:51] <jadew> oh well, I'll start playing with it tonight or tomorrow, have to start work now
[07:36:57] <jadew> see ya later
[07:38:53] <ziph> Bye.
[07:41:20] <mapee> hi
[07:48:44] <ziph> Hey there.
[09:39:05] <eroomde> hello. does anyone know of a dev board for the AT32UC3C which includes ethernet?
[10:25:54] <magn0z_> hey. designing a circuit with an avr atmega328p. reading the avr hardware design considerations appnote, it states that if i want to share the SPI ISP pins (MISO, SCK, MOSI) with something else than the programmer, the programmer must be protected. the way they recommend doing this is putting in a resistor in series with each line going the other device. can anyone explain why this protects the programmer?
[10:29:20] <ben1066> Hey
[10:30:22] <magn0z_> hi
[10:30:23] <tobbor> hi magn0z_.
[10:38:03] <keenerd> magn0z_: It current limits the other device. So the programmer and the device will not short each other out. And since the programmer does not have limiting resistors, it will take priority and drown out the other device.
[10:38:52] <magn0z_> oh. so what value should i pick for the resistor? just a small one? i guess if its too large, a voltage drop will occur, and if its too small
[10:39:00] <magn0z_> the document doesnt specify a value
[10:39:37] <keenerd> You are moving very small currents over SPI. Voltage drop is not much of a problem.
[10:40:22] <keenerd> Off the top of my head, I'd guess 1K would be good. No idea, maybe someone else here will know better.
[10:42:39] <magn0z_> cool
[10:44:12] <magn0z_> for another problem, my avr runs at 3.7V, while the device im talking to wants 2.8V on some of its pins. I guess a resistor in series would suffice here, but what value should I pick? i don't know the current, so how can i calculate the resistor needed to lower 0.9V
[11:12:02] <keenerd> magn0z_: A single resistor won't do it. See
http://www.sparkfun.com/tutorials/65
[11:20:25] <Casper> magn0z_: 2 resistors is needed, make a resistor divider network. an input basically take zero current, so won't drop anything. consider the input to be 10Mohms minimum
[11:30:27] <keenerd> Well you can use just one resistor, but then you are putting a lot of faith in the clamping diodes.
[11:32:23] <Casper> if they even exists
[11:33:33] <keenerd> Just like most kinds of faith ;-)
[12:02:33] <_abc_> Do you find it reasonable that you need to install a 46MB library (libboost) to use srec_cat with avrdude? I think it is ridiculous.
[12:06:30] <keenerd> On top of the 90MB of the custom libc+binutils+gcc AVR already requires, it seems not so bad...
[12:07:06] <_abc_> I like your philosophy. Do you work for a hdd maker? >:~
[12:07:07] <keenerd> Kind of want to make my own lightweight C compiler and replace that whole mess. But not silly like TCC.
[12:07:16] <_abc_> lcc
[12:07:37] <keenerd> 100% ungoogalbe name.
[12:07:40] <_abc_> hehe
[12:08:01] <keenerd> lcc compiler though wins.
[12:09:43] <keenerd> And the AVR fork of it looks dead-ish.
[12:10:14] <karlp> just suck it up. hard drive space is not getting filled by libraries.
[12:10:23] <karlp> it gets filled by videos and photos
[12:10:53] <karlp> why do you need to use srec_cat with avrdude? can't you use the srec tools standalone?
[12:10:57] <amee2k> "the porn^Winformation superhighway(tm)"
[12:11:25] <keenerd> karlp: /usr is 20% of my drive. No videos or photos either, but another 20% is PDFs.
[12:11:48] <karlp> sure, but 20% that doesn't really grow an awful lot.
[12:12:03] <keenerd> *26%
[12:12:04] <amee2k> the MJPEG full hd videos that my camera makes suck pretty badly space wise
[12:17:25] <amee2k> 2GB for like 10 minutes of video and looks like the video was 2MB instead
[12:17:27] <amee2k> >_<
[12:18:04] <RikusW> DVI video is about the same size, much lower resolution though...
[12:18:44] <amee2k> the camera can do 720p which is pretty much wasted by the ridiculous MJPEG codec imo
[12:19:06] <amee2k> good that i bought it for making photos, not videos. otherwise that would have been a pretty rough disappointment i suppose
[12:44:59] <ecraven> hey :) quick question, using binutils-avr 2.22 and gcc-avr 4.6.2, i get a segfault when linking my (formerly working) program: collect2: ld terminated with signal 11 [Segmentation fault]
[12:45:17] <ecraven> this seems to be connected to a problem with ld and faulty elf files, any way to fix my program to make it work?
[12:46:40] <_abc_> ecraven: where did you get 4.6.2
[12:46:44] <ecraven> arch linux
[12:47:12] <ecraven> it seems to be the standard gcc-avr on that distro
[12:48:29] <_abc_> hmm
[12:48:38] <_abc_> Is there an arch live dvd?
[12:48:48] <ecraven> hm.. not sure, i think so
[12:49:00] <ecraven> though it probably includes an older version of that package
[12:49:48] <ecraven> i'm building gcc-avr-svn right now, see whether that helps
[12:50:31] <scuzzy> maybe you should try examining your code first
[12:51:04] <ecraven> the code used to work exactly like this a few months ago
[12:51:17] <scuzzy> yes, but that's not to say there wasn't a problem
[12:51:29] <ecraven> hm.. why would faulty code make collect2/ld segfault?
[12:51:37] <scuzzy> it's possible that the problem is just manifested with a compiler doing something in a different way
[12:51:38] <ecraven> and how would i find out what exactly the problem is?
[12:51:58] <ecraven> i'll try the teensy example problem
[12:52:03] <ecraven> eh, program
[13:00:47] <rue_house> ok if anyone wants anything from ruemohr.org get it now, site goes bye bye soon
[13:00:58] <amee2k> o.O
[13:01:03] <amee2k> how so?
[13:01:10] <rue_house> I'm canceling it
[13:01:14] <rue_house> it was a failure
[13:01:36] <amee2k> okay
[13:02:19] <amee2k> "we need submissions people..." << hehe :)
[13:02:54] <amee2k> from my exp, that almost never works >_>
[13:03:05] <rue_house> it definitly didn't
[13:03:28] <ziph> You'd be better having something sit in here that put every quoted link on a page, sorted first by number of mentions and then by date.
[13:14:18] <scuzzy> ecraven: sorry, I missunderstood your first comment
[13:15:54] <ecraven> np, i'm just compiling gcc-avr-svn, hope that solves it.. i tried a minimal program, still segfaulting.. maybe my Makefile is somehow causing this by passing incorrect parameters to gcc
[13:20:55] <nofxx> ecraven, I'm collecting / fixing / improving Rakefiles for AVR here
https://github.com/nofxx/avr_scaffold
[13:21:17] <ecraven> nofxx: thanks, i'll have a look
[13:29:26] <ecraven> hm.. seems to work better than my makefile :)
[13:29:51] <keenerd> ecraven: What is your Arch problem?
[13:33:12] <keenerd> rue_house: Why are you getting rid of it? It can't cost that much to host 1MB of stuff.
[13:33:26] <rue_house> it was a concept failure
[13:33:53] <keenerd> I dunno, I thought it was okay for a personal site.
[13:33:59] <rue_house> I was seeing if the members of the channel wanted to compile a common code resource
[13:34:08] <rue_house> for examples and libraries and information
[13:34:09] <ecraven> keenerd: it might only be a problem with the Makefile that pjrc (teensy) ships
[13:34:32] <keenerd> ecraven: Ah, Teensy. Yeah, that broke back around gcc 3.6.
[13:35:37] <rue_house> m32u2 or 4?
[13:35:42] <ecraven> m32u4 i think
[13:36:07] <keenerd> rue_house: Ah, did not know that was your intent. Not exactly clear there. Hrm. Maybe relaunch it on Github, something where user contribution is a bit easier?
[13:36:34] <rue_house> keenerd, go for it
[13:36:45] <rue_house> ecraven, do you want some help making it work
[13:36:53] <rue_house> I just got one going for myself
[13:37:11] <rue_house> ecraven, oh, win or lin?
[13:37:34] <keenerd> ecraven: I am sad to say that I just stopped updating avr-gcc instead of fixing the makefile. But I don't maintain Arch's avr stuff ;-)
[13:38:04] * Steffanx clones rue_house website
[13:38:12] <rue_house> pls do
[13:38:33] <ecraven> linux. but if the rakefile works, i don't need the makefile :)
[13:38:51] <keenerd> Steffanx: I got 968KB total. You?
[13:39:28] <Steffanx> I failed.. os x has no wget :P
[13:39:35] <rue_house> Steffanx, would you like the ftp access?
[13:39:51] <Steffanx> I'll install wget
[13:40:38] <rue_house> I';ll try to find the password
[13:41:05] <keenerd> Just make a zip of the site and link it on the homepage.
[13:41:18] <keenerd> No need to blast passwords over freenode.
[13:41:28] <ecraven> use curl?
[13:41:32] <rue_house> haha there is a tense moment, I used tail instead of cat on my password file and it looked almost enpty
[13:41:35] <ecraven> Steffanx: use curl instead of wget?
[13:41:53] <Steffanx> I don't know how to get everything with curl
[13:43:05] <rue_house> Steffanx, ftp.ruemohr.org
[13:43:12] <Steffanx> And i'm already done
[13:43:17] <Steffanx> Installed wget
[13:43:18] <rue_house> username ruemohr
[13:43:29] <rue_house> password ********
[13:43:57] <keenerd> ... why are you using my password?
[13:43:58] <rue_house> damn I forgot that irc stars out passwords
[13:44:31] <rue_house> :)
[13:45:35] <Steffanx> http://www.naffets.nl/ruemohr/ there it is :P
[13:45:43] <rue_house> Steffanx, get that? dont be posting any of those porn pics eh?
[13:45:58] <Steffanx> Nah, i have my own ftp for that :p
[13:46:00] <keenerd> Steffanx: 968KB?
[13:46:05] <rue_house> Steffanx, there ya go, now I dare ya to make it work conceptually
[13:46:24] <Steffanx> 933K keenerd
[13:46:28] <Steffanx> 12 files
[13:46:42] <rue_house> I object, there were a few directories in there too
[13:46:50] <keenerd> Hrm, I got 19.
[13:46:54] <Steffanx> Hmm
[13:47:01] <keenerd> Close enough :-)
[13:47:10] <rue_house> with the dirs it could be 19
[13:47:16] <Steffanx> Ah
[13:47:35] <Steffanx> Everythings works
[13:47:38] <Steffanx> -s
[13:47:49] <rue_house> yay I didn't hard site-link anything?
[13:48:00] <Steffanx> wget can convert it..
[13:48:04] <rue_house> cool
[13:48:17] <rue_house> the source wont be pretty, its konquerer
[13:48:41] <Steffanx> but it seems you didn't use 'hard site-links'
[13:48:59] <rue_house> I try to keep it all relaitve
[13:49:19] <ecraven> is there anything special about D6 on the atmega32u4?
[13:49:40] <rue_house> ecraven, does it hav3e the led on it?
[13:50:03] <Steffanx> It would be nice to make the concept work, but I won't do it rue_house :P
[13:50:09] <ecraven> indeed, just found that :) i'm trying to use it as an input
[13:50:20] <Steffanx> I just want a copy
[13:50:24] <ecraven> now, how do i disable the led.. :)
[13:50:35] <rue_house> ecraven, have a soldering ircn?
[13:50:39] <rue_house> )
[13:50:48] <rue_house> ^ missing p[iece of the o
[13:51:08] <rue_house> oh dear, what did that bracket fall off of...
[13:51:57] <ecraven> hm.. i'll just re-trace the wire to d7 instead of d6.. should have thought of that when ordering the prototype board :()
[13:56:36] <rvsjoen> what kind of clock drift is normal on a rzraven board
[13:57:11] <rvsjoen> we're seeing as much as 1 second drift every 500 second or so, which seems like a lot
[13:57:48] <rue_house> on what?
[13:58:38] <rvsjoen> well, its an atmel avr rzraven evaluation board, and its the atmega1284P MCU, but it is probably using an external clock source
[13:58:54] <rvsjoen> http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4291
[14:00:20] <rue_house> I'm not aware of any of us working with it
[14:02:24] <rue_house> http://www.pjrc.com/tech/8051/autobaud.html <-- someone port to an avr already!
[14:10:48] <karlp> rvsjoen: what are you counting time with?
[14:49:09] <ecraven> very nice, my chording keyboard mostly works now :) just need to connect the thumb unit, and finish the software
[14:51:36] <rue_house> a proper keyboard with diodes?
[14:53:20] <ecraven> a 7-key chording keyboard for one hand
[14:53:28] <ecraven> (though i plan to build two connected units for two-handed operation)
[14:53:32] <ecraven> like the BAT keyboard
[14:53:52] <ecraven> no diodes, but 7-key rollover (i.e. all-key rollover) :)
[14:57:31] <rvsjoen> karlp: i'm telling the node to send a packet every second
[14:57:46] <rvsjoen> and the node itself claims to send a packet every second, with a margin of aboug 300 microseconds
[14:59:46] <rvsjoen> so if I tell two nodes to do the same (1 packet every 1 second), I notice the relative time between two packets increase
[15:24:55] <karlp> no, I mean, how are you counting time. How do you know that one second has elapsed.
[15:26:13] <rvsjoen> that's handled by the avr2025 library
[15:27:11] <rvsjoen> it counts the timer ticks needed to count a second based on the configured clock rate
[15:29:26] <rvsjoen> i'm sorry if the explanation sucks, but it's kind of hard to explain :)
[15:30:12] <karlp> even if there's a single extra cycle somewhere, they will quickly drift apart.
[15:30:39] <karlp> just putting some crystals on and expecting to be able to keep independent perfect time is a recipe for unhappiness.
[15:31:09] <karlp> you need to not just _keep time_ but also need to make sure that the thing you want done on some interval also starts at exactly the right time.
[15:31:24] <karlp> it's not impossible, but you're probably better off relaxing something else to not require that.
[15:31:35] <rvsjoen> the plan is to make one node act as a time source for the others, just wondering if a drift between two nodes of 1-2 seconds in a period of 500 seconds is a lot, to me it seems excessive
[15:32:14] <karlp> not especially. that's only 0.2%
[15:32:16] <Tom_itx> .4%
[15:32:23] <karlp> yeah, what he said :)
[15:34:29] <rvsjoen> I read a little about RTC, which only allows a couple of seconds drift per day, but I guess these things are not that accurate
[15:34:34] <Tom_itx> 4000ppm
[15:37:53] <rvsjoen> found some documentation on calibrating the rc oscillator, i'll give that a run and see if it makes a difference
[15:41:29] <karlp> rvsjoen: that's only going to matter if the raven runs on the internal oscillator.
[15:42:59] <rvsjoen> probably won't help me then, cause I think timer0 is running on that, and that's not what is timing the packet transmissions
[15:43:03] <rvsjoen> need to look closer
[15:43:29] <karlp> avr don't run some timers on the internal oscillator and others on some other clock.
[15:45:13] <amee2k> oooh, does microchip semi sell to non-business customers??
[15:46:12] <amee2k> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en548014 << i just found this, which would be quite awesome, but from what i can see is not available as samples so i'd have to buy
[15:46:44] <karlp> amee2k: I've happily bought from microchip direct
[15:46:48] <amee2k> and 24USD would be an awesome price, even if it is excl. tax
[15:46:50] <karlp> singles and small volumes
[15:47:04] <karlp> you can also buy them from mouser/digkey
[15:47:11] <amee2k> i could show a student ID if that helps
[15:47:20] <amee2k> hmm digi has them too?
[15:47:35] <karlp> it's a newer bigger brother to the mrf24j40 that I use for 802.15.4
[15:47:47] <amee2k> quite interresting
[15:48:04] <karlp> they're front page on mouser, I can't honestly say I've looked for them explicitly on digikey
[15:48:25] <amee2k> a few weeks ago i was looking for wlan modules just like these but the only ones i could find were north of 60EUR or so and nowhere to be found for retail
[15:48:47] <amee2k> just searched, they're 26USD from digi (for singles)
[15:49:25] <amee2k> i was pretty pissed off how expensive adding wlan to an MCU project was, really
[15:49:39] <karlp> wireless is hard :)
[15:49:54] <amee2k> thats why i wanted a module for it >_>
[15:49:56] <karlp> also, don't forget you still need an IP stack at least,
[15:50:00] <amee2k> and not just the naked IC
[15:50:20] <amee2k> i'd need an ip stack for an ENC...err something wired ethernet mac as well
[15:50:31] <karlp> raspberry pi is only marginally more expensive than the module, when they finally come out.
[15:50:37] <karlp> openwrt routers too.
[15:51:16] <amee2k> well, the project i wanted them for is kinda on hold for the moment anyway because i'm working on another one
[15:51:54] <amee2k> so i can take my time and for that price i might just get one of these wireless mac modules to play around with it
[16:08:28] <OndraSter> I got those cheap nrf24l01 or smth chips
[16:08:31] <OndraSter> from ebay :D
[16:08:36] <OndraSter> but they are not wifi or anything
[16:08:40] <OndraSter> they connect only between each other
[16:08:46] <OndraSter> $2.5 per module is unbeatable though
[16:29:16] <karlp> yeah, writing your own link protocols is fun :)
[16:29:54] <keenerd> There is that AVR with ZigBee built in.
[16:30:07] <karlp> with an 802.15.4 transceiver built in.
[16:30:10] <LoRez> it's not ZigBee
[16:31:09] <keenerd> Now is 802.15.4 not zigbee?
[16:31:16] <keenerd> *How
[16:31:29] <LoRez> 802.15.4 is the physical layer ZigBee runs on.. that's like saying TCP is ethernet.
[16:33:11] <OndraSter> karlp, you can use it as a raw serial port, no need to "port" TCP on it lol
[16:33:41] <OndraSter> ergo you can use it as raw serial port
[16:33:42] <OndraSter> just wireless
[16:33:44] <karlp> if you are only interested in a serial port, between two nodes, that _might_ be enough
[16:33:47] <OndraSter> yes
[16:33:53] <OndraSter> that's what I am targetting
[16:33:59] <OndraSter> wireless temperature measuring stations :)
[16:34:06] <karlp> with just one node... :)
[16:34:18] <OndraSter> small boxes with one 3.7V battery (probably), small attiny and this small board on top of it
[16:34:26] <OndraSter> and some digital temperature sensor
[16:34:36] <OndraSter> I am gn
[17:08:58] <rue_house> anyone into code for talking to an isa ethernet card ?
[17:10:45] <specing> I don't even have one!
[17:10:58] <specing> But I do have a computer that can do ISA
[17:11:20] <rue_house> it would be funny really, a board half the size of the network card operating it
[17:11:45] <rue_house> what would you do with an ethernet enabled avr?
[17:11:50] <specing> lulz :D
[17:12:13] <specing> rue_house: I'd ping the **** out of everyone
[17:12:30] <Steffanx> With an AVR LOL
[17:12:44] <rue_house> hmm I wonder
[17:12:56] <rue_house> if a hand held wired network ping tester would be usefull
[17:13:16] <specing> rue_house: you can buy those for 10$
[17:13:30] <rue_house> no, you can buy a conductor tester for that
[17:13:40] <specing> well yes
[17:13:47] <rue_house> you have to unplug the cable and put a device on the other end
[17:13:48] <specing> Maybe they can ping too
[17:13:58] <rue_house> not for $10, prove it
[17:14:24] <rue_house> they are just wire testers
[17:14:33] <rue_house> they have no actual eithernet ability
[17:17:30] <rue_house> I'm talking about soemthing with only ethernet ability
[17:17:51] <rue_house> plug it in, input ip address, get ping confirmation
[17:18:18] <BrentBXR_> Any of you guys know if its possible to compile project a) and launch it as hex in project b) on command?
[17:18:48] <rue_house> "launch it as hex in project" <-- what?
[17:19:05] <rue_house> compile a project on command? yes, run the compile command
[17:19:48] <rue_house> wait, your not trying to run dynamically loadible applications on a microcontroller are you?
[17:20:29] <BrentBXR^> Sorry internet died
[17:20:30] <BrentBXR^> i missed everything past rue_house> "launch it as hex in project" <-- what?
[17:20:37] <BrentBXR^> and rue_house i mean if i compiled a project a) which was to simply flash an LED on portb for example
[17:20:42] <rue_house> !thislog
[17:20:43] <tobbor> This one:
http://rueshouse.dyndns.org:82/~ircjunk/irclogs/html/%23avr-2012-01-17.html
[17:21:18] <rue_house> you can write a program to flash a led and run it on an avr, yes
[17:21:47] <rue_house> thats the 'hello world' of microcontroller programming
[17:21:57] <rue_house> biab
[17:27:04] <BrentBXR__> ok fuck
[17:27:22] <Steffanx> No thanks
[17:27:29] <BrentBXR__> Anyways; this is the goal i have a peice of hardware and two firmwares for it
[17:27:44] <BrentBXR__> I would like to convert them into one and say, a jumper will choose which on startup
[17:27:50] <BrentBXR__> but theres a twist
[17:28:02] <BrentBXR__> its not as easy as just pasting the source or including
[17:28:27] <BrentBXR__> so i was hoping perhaps turn one or both into ASM or hex and somehow embedding them into a firmwar ethat just does the switch
[17:28:31] <BrentBXR__> ever heard of anything like that?
[17:49:32] <rue_house> you canty do that
[17:49:47] <rue_house> you have to make them one program with a 3rd program to jump to the part you want
[17:51:16] <rue_house> I should gut my alarm clock and make it a usb device so it tells the right stupid time
[18:04:02] <BrentBXR__> rue are you sure? or is that your guess?
[18:04:47] <karlp> you can do many things.
[18:04:54] <karlp> his way is one of the more straightforward ones.
[18:05:58] <BrentBXR__> lol...
[18:07:05] <BrentBXR__> you sure can
[18:07:19] <BrentBXR__> his way is not the most 'straightforward' ways
[18:07:42] <BrentBXR__> his way was the way I was specificly saying was not doable
[18:08:16] <BrentBXR__> I would think perhaps it could be put into the MCU at a differnt address then the main firmware
[18:08:20] <BrentBXR__> and perhaps jumped too
[18:08:39] <BrentBXR__> i dont know if thats possible but if it could be done, i think that would be the way
[18:08:40] <karlp> sure, if you don't want to use interrupts.
[18:08:49] <karlp> and you want the two programs to be aware of each other.
[18:08:57] <BrentBXR__> thats fine
[18:09:01] <karlp> but it seems like you know what to do anyway, so I'll just leave you to it.
[18:09:25] <BrentBXR__> your advice was so helpful i dont know how i could live without it
[18:49:34] <pingec> Is there a way in avr studio to have multiple .asm files in one project and compile each to its own hex ?
[18:56:23] <pingec> Hmm I think if i set the new file as entryfile it compiles that one into hex
[18:57:24] <Tom_itx> why would you want separate hex files in a project?
[18:58:54] <pingec> Well cause I'm learning asm and don't want to create a separate project for every variation of code I make
[18:59:26] <pingec> I'd like to have a project with code samples
[19:00:39] <pingec> But setting a specific .asm file as entryfile is good enough
[19:01:00] <pingec> So nevermind
[19:01:11] <timemage> pingec, you could use macros to conditionally assemble separate files.
[19:02:40] <pingec> I see that I can define Pre-build event commands
[19:03:26] <pingec> It's ok
[19:03:52] <pingec> multiple .asm files in one project looks cleaner to me :)
[23:39:04] <Roklobsta> for system time who has used DD:MM:YY:HH:MM:SS:MSEC with a big arsed cascading incremeter running ever millisecond or second and who has just used a 32 bit epoch counter?
[23:40:59] <Landon> I would imagine it depends on what you're using it for
[23:41:40] <Landon> all the leap* would make the first approach a pain if you were trying to track real clocks
[23:41:44] <Casper> Roklobsta: was that a question?
[23:42:00] <Roklobsta> er yes, sort of a survey
[23:42:03] <jd_ce> wat
[23:42:37] <Casper> your sentence is so broken that it's meaningless
[23:43:15] <Landon> for system time who has used X and who has used Y? it's just got a lot of subparts
[23:43:33] <Roklobsta> landon: right. the leap seconds get added whenever deemed necesary so there is no systematic way of putting it in. if you were synced to gps it's not a problem as leap second information is sent to the gps modules in order to correct UTC agains GPS time.
[23:44:20] <Roklobsta> i am asking, in general, what has been the approch with AVRs, a UTC format or epoch format?
[23:45:28] <Roklobsta> With an epoch start time of say Jan 1 2000.
[23:46:21] <Casper> depend on your need
[23:47:12] <Roklobsta> epoch is much tidier from a systems point of view.
[23:48:24] <Casper> yes, but may add complexity elsewhere in the code
[23:50:19] <keenerd> I use discordian date in my system clocks.