#avr | Logs for 2012-07-30

Back
[03:44:04] <Guest9775> hf
[03:44:06] <Guest9775> hmm he is gone
[04:17:48] <yashi> ive got a understanding problem with spi.i dont understand how miso/mosi use the SPDR (Dataregister)
[04:18:16] <yashi> example: my atmega works as a master. i write something into the SPDR and send it to the slave
[04:18:23] <OndraSter> yes
[04:18:33] <yashi> the slave then instantly sends a bit back whenever the master sends one, right?
[04:18:37] <OndraSter> yes
[04:18:54] <yashi> so how the fk can i know when the slave actually answers to my command?
[04:19:07] <OndraSter> you write dumb 00 :)
[04:19:17] <OndraSter> if it doesn't answer the first byte but requires one extra byte
[04:19:18] <yashi> :P
[04:19:19] <yashi> ty
[04:19:26] <OndraSter> so it goes:
[04:19:28] <OndraSter> master:
[04:19:37] <OndraSter> 57 - 00 - 00 - 00
[04:19:38] <OndraSter> slave:
[04:19:44] <OndraSter> 00 - ff - 53 - c1
[04:19:46] <OndraSter> (for example)
[04:20:23] <yashi> pretty inefficient, isnt it?
[04:20:38] <yashi> i waste a lot of time with sending 00
[04:20:46] <OndraSter> on the other hand you receive a lot of data
[04:21:36] <yashi> thanks
[04:21:40] <OndraSter> np
[04:21:41] <yashi> gonna try that now
[04:41:27] <sabesto> anyone messed with atmega32/16HVB/HVA and lipos?
[04:43:00] <sabesto> trying to figure out how to connect a thermistor to the darn thing, the SB202 (eval module) docs points to an appnote for connecting a thermistor, but its not mentioned in that appnote
[04:43:45] <sabesto> i dont have the device, nor the licensed firmware yet
[04:43:53] <sabesto> so i cannot test
[05:21:11] <RikusW> sabesto: I guess you'll probably connect Vcc -> resistor -> ADCin -> thermistor -> gnd
[05:21:55] <sabesto> RikusW: yeah, but i dont know which pins. since it only has 2 pins with adc i guess i could eyeball it
[05:22:12] <sabesto> i was hoping to use the firmware written by atmel
[05:25:32] <RikusW> using the ADC can't be that hard ? ;)
[06:06:06] <age> hi. I'm trying to recompile USBasp code for 20 MHz atmega48, and somewhy it's about 400 bytes larger that the precompiled version, not fitting the flash. any ideas on why is the code larger? avr-gcc 4.7.1
[06:07:10] <damjan> age: probably the original was not compiled with 4.7.1
[06:07:12] <CapnKernel> age: What optimisation are you using?
[06:08:03] <age> CapnKernel, tried the default O2 and Os, the 400 byte overhead is with Os
[06:08:28] <CapnKernel> Hmm
[06:08:54] <damjan> age: you can try with the -ftlo option, wait a sec to find my Makefile
[06:10:07] <damjan> so, -fwhole-program -flto and then you must list all the .c and .S files on a single line
[06:10:20] <damjan> it'll compile them at once so it can do some more optimizations
[06:10:32] <damjan> but 400 bytes is a bit much
[06:11:18] <age> hmm, give me a minute
[06:13:07] <age> about 80 bytes smaller
[06:13:17] <age> should I try an older version of gcc?
[06:13:46] <CapnKernel> Can't hurt.
[06:25:25] <OndraSter> hmm is it just me or is there no input impedance of digital pin?
[06:25:38] <OndraSter> analog has 100M
[06:26:12] <RikusW> age: the 20MHz version use different asm code..
[06:26:37] <RikusW> v-usb tailor the asm code for each frequency
[06:28:40] <age> RikusW, so it may be impossible to size it down to 4kb at all?
[06:29:10] <RikusW> try compiling to different crystals frequencies and see what happens ?
[06:29:23] <OndraSter> is the v-usb completely in asm?
[06:29:49] <age> big parts of it are.
[06:30:27] <age> RikusW, in a bit, I'm currently compiling gcc 4.5
[06:37:04] <CapnKernel> OndraSter: The timing critical parts are in asm, because bit-banging USB needs to be cycle-accurate.
[06:37:31] <OndraSter> I know that
[06:37:37] <OndraSter> that doesn't answer my question :)
[06:37:49] <age> RikusW, the 12 MHz version is even larger than the 20 MHz one
[06:38:08] <age> and both are much larger than precompiled hex file :|
[06:38:09] <CapnKernel> To answer your question, it's not completely in asm, because there's at least one line that's in C.
[06:38:50] <CapnKernel> You must be doing it wrong somehow. Maybe there's an ELF section you can drop out or something.
[06:39:14] <age> I'm just using the supplied makefile
[06:39:30] <age> and according to readme
[06:39:53] <RikusW> its probably compiler switches or version...
[06:40:42] <OndraSter> CapnKernel, my point is - C can get really big sometimes :P
[06:41:05] <age> RikusW, gcc 4.5.3 code is even a bit larger than 4.7.1 one
[06:41:22] <CapnKernel> I bet it's an ELF section
[06:41:41] <RikusW> hex files have no sections...
[06:45:03] <CapnKernel> Hex file is an encoding of a memory dump. A dump of memory that may have unneeded stuff in it, due to an unneeded section.
[06:49:00] <RikusW> then the problem is with avr-objcopy switches
[06:53:08] <CapnKernel> Nooo, don't force me to dig up my V-USB makefile! :-(
[06:54:36] <age> :D
[06:54:42] <CapnKernel> I'm producing my .hex file thus: avr-objcopy -j .text -j .data -O ihex main.elf main.hex
[06:54:49] <age> same here.
[06:55:28] <CapnKernel> I tried.
[06:55:30] <age> I guess I'll just have to change the crystal :|
[06:56:14] <RikusW> try compiling for 12MHz
[06:56:26] <RikusW> maybe 15MHz too
[06:56:34] <RikusW> v-usb give a list of supported crystals
[06:57:54] <age> RikusW, 12 MHz doesn't win any code size here, and there's a precompiled 12 MHz version
[07:13:18] <RikusW> for the megaXX8 series AVRs ?
[07:14:30] <age> hooray
[07:14:40] <age> RikusW, yes, for mega48 specifically
[07:14:52] <age> I have tried an older version of USBasp code, and it fits!
[07:16:12] <RikusW> good for you
[07:16:22] <age> :P
[07:16:49] <RikusW> why not use mega88 ? :-P
[07:19:05] <age> RikusW, I had a spare mega48 around
[07:20:02] * RikusW have 2 m168's and a m328P around ;)
[07:20:20] <RikusW> actually I have an AVR collections :)
[07:20:43] <RikusW> I used it to test http://sites.google.com/site/megau2s/home
[07:23:32] <age> nice :)
[07:23:43] * RikusW have t26 t261 t2313 t10 t11 t45 t24 m169 m16 m324A m644 m32u2 m32u4 m168 m328 m16u2
[07:23:58] <RikusW> more like 100x m32u2 ;)
[07:27:44] <age> omg
[07:33:50] <OndraSter> darn I am having hard time understanding the INT0/PCINT interrupts on the attiny13a. They say that when in sleep mode the tiny can be woken up only as "level interrupt" on INT0. Does that mean that only "low level interrupt" will work?
[07:34:17] <OndraSter> on the other hand there is PCINT which should be async for any level change
[07:34:45] <OndraSter> including sleep modes?
[07:35:02] <specing> OndraINT
[07:39:27] <OndraSter> specing, did you just try waking me up
[07:39:28] <OndraSter> ?
[07:40:05] <specing> No, it is set to active low
[07:41:24] <RikusW> there seems to be a wakeup delay of several minutes :-P
[07:44:52] <specing> He is running at 0.02 hz ;P
[07:48:34] <age> interesting
[07:49:09] <age> avrdude reports that extended fuse on my mega48 changes to 1 whenever I try to flash it
[07:49:40] <Kevin`> are you setting it to a valid value?
[07:49:57] <age> according to fusecalc, so probably yes
[07:51:16] <age> other fuses change fine, flash writes fine, but a very simple program doesn't seem to work :|
[07:51:37] <age> probably more bad soldering, already found some.
[07:55:27] <OndraSter> well atmel studio changes fuses to enable/disable OCD
[07:55:34] <OndraSter> what is the 1?
[07:57:17] <age> oh wait
[07:57:25] <age> there's a note at fusecalc
[07:57:32] <age> 1 is ok
[07:57:49] <age> "Note that some numerical values refer to fuses containing undefined bits (set to '1' here). Depending on the target device these fuse bits will be read either as '0' or '1'. Verification errors will occur if the values are read back with undefined bits set to '0'. Everything is fine if the values read from the device are either the same as programmed, or the following values (undefined set to '0'): Extended: 0x01."
[08:08:18] <yashi> if i write ldi R16, 0x0f it writes the value 0x0f into Register16 right?
[08:08:59] <yashi> but writing ldi R16, SPDR equals ldi R16, 0x0f.. but thats something totally different :/
[08:09:26] <RikusW> age, reading 1 there means self programming disabled
[08:10:29] <RikusW> yashi: you'll probably do in R16,SPDR
[08:10:52] <RikusW> ldi R16, SPDR --- this loads the address of SPDR into R16...
[08:11:34] <yashi> RikusW: yes i understand that. but the address of SPDR = 0x0f => m8def.inc
[08:12:08] <RikusW> to load the value in SPDR use: in r16,SPDR
[08:12:20] <RikusW> and out SPDR,r16
[08:12:52] <yashi> RikusW: how would you load SPDR into R16 if you want to use the adress only?
[08:12:54] <RikusW> take note, on extended registers use lds/sts (on bigger AVR's)
[08:13:49] <RikusW> load the address into Z like ldi r31,0 ldi r30,SPDR ld r16,Z
[08:14:53] <yashi> RikusW: but SPDR is just an .equ SPDR = 0x0f... so why isnt it allowed to just replace the spdr by 0x0f?
[08:15:58] <RikusW> its allowed, but not recommended, the code won't be easily readable
[08:16:59] <RikusW> in fact avr-objdump disassembly looks like that, only numbers and pointers, no constant names, and its fairly timeconsuming to understand....
[08:17:33] * RikusW reverse engineered over 15000 lines of disasm... so I know...
[08:19:05] <yashi> RikusW: im not planning to do that :P but if im allowed to replace it then ldi R16, 0x0f is something different than ldi R16,0x0f.. which obviously cant be
[08:19:32] <yashi> RikusW: or im not allowed to use ldi for both of those tasks
[08:19:45] <specing> wtf is your problem yashi ?
[08:20:05] <specing> THERE IS NO TYPE CHECKING IN ASM.
[08:20:18] <specing> meaning you can do whatever you want
[08:20:25] <RikusW> yashi: to get the value inside the SPDR register use -> in r16,SPDR
[08:20:36] <RikusW> ldi won't work for that
[08:20:37] <karlp> in vs ldi.
[08:20:47] <yashi> RikusW: thanks.
[08:20:49] <karlp> ldi is load immediate iirc
[08:20:54] <RikusW> it is
[08:20:57] <karlp> in for reading from a mem address
[08:21:01] <specing> Indeed!
[08:21:10] <OndraSter> yes :)
[08:21:11] <specing> karlp: false
[08:21:13] <OndraSter> well
[08:21:14] <RikusW> using asm you first have to build a gun to shoot yourself in the foot :-D
[08:21:22] <OndraSter> IN and OUT are reading from memory mapped IO
[08:21:25] <karlp> specing: ok fine, wasn'ts ure about "in" :)
[08:21:28] <OndraSter> and IN/OUT end at 0x3F address
[08:21:29] <specing> in is for reading from lower 64 (or is it 32) bytes of registers
[08:21:44] <RikusW> sts/lds for extended IO (mem mapped)
[08:21:55] <OndraSter> it is after stats reg
[08:22:14] <OndraSter> SREG
[08:22:18] <RikusW> though it can also be used for low IO, but the low IO constants are meant for in/out....
[08:22:46] <OndraSter> the difference between LDS and IN is that IN takes address as direct intermediate value but LDS requires have the memptr in Z
[08:23:12] <yashi> x.x maybe i should go back to C
[08:23:13] <yashi> :P
[08:23:20] <OndraSter> what's wrong on asm :)
[08:23:37] <yashi> if you want to learn stuff nothing
[08:25:12] <specing> if you want to do so in a short period of time, everything
[08:25:40] <RikusW> OndraSter: in and lds pointers differ, lds pointer is 0x20 higher than in
[08:25:54] <OndraSter> RikusW, obviously since lds actually takes into account the first R0 - R31 registers
[08:26:03] <OndraSter> plus they differ that one is addresssed immediatily and one is addressed via Z
[08:26:05] <OndraSter> or X or Y
[08:28:02] <RikusW> lds use an immediate address
[08:28:10] <OndraSter> hmm?
[08:28:48] <OndraSter> hmm LDS really has intermediate
[08:28:48] <RikusW> LDS – Load Direct from Data Space
[08:28:56] <OndraSter> LD/LDD doesn't
[08:29:02] <RikusW> its a 32bit instruction
[08:29:08] <OndraSter> sorry, I was wrong there :)
[08:30:01] <RikusW> bbl
[08:30:05] <OndraSter> bb
[08:42:43] <OndraSter> hmm has anyone ever tried doing simulation of sleep in avr simulator?
[08:43:00] <OndraSter> what should happen when you keep single stepping on SLEEP instruction?
[08:53:34] <Tom_itx> simulated sleep is a let down. i prefer the real thing
[08:53:54] <Tom_itx> i don't think some things simulate very well OndraSter
[08:54:08] <OndraSter> well I mostly forgot SEI instruction
[08:54:30] <OndraSter> the thing is - it is hardware choice whether I have to do external pullup or pulldown :o
[08:55:09] <OndraSter> hmm
[08:55:11] <OndraSter> PCINT won't fire
[08:55:13] <OndraSter> INT0 did
[08:55:28] <Tom_itx> what chip?
[08:55:32] <OndraSter> tiny13a
[08:55:38] <Tom_itx> i have samples of pcint but not for 13a
[08:55:45] <OndraSter> well I used it already few times
[08:55:48] <OndraSter> but never in simulator
[08:55:50] <OndraSter> and never on tiny
[08:56:05] <OndraSter> and never in conjunction with sleep mode
[08:56:22] <Tom_itx> simulators can't simulate everything as you expect
[08:56:27] <OndraSter> ye
[08:56:53] <Tom_itx> put a current meter on the supply and see how sleepy it gets
[08:57:06] <OndraSter> if I had the hardware already I wouldn't be using simulator
[08:57:16] <OndraSter> I suppose I will have to buy one attiny in DIP :)
[08:57:41] <Tom_itx> i'm not sure i've ever used a simulator
[08:57:51] <Tom_itx> if i did it was just a curiosity
[08:58:08] <OndraSter> also I can not find in the datasheet the input impedance of digital IO
[08:58:12] <OndraSter> is it the same as analog?
[08:58:20] <Tom_itx> i doubt it
[08:58:38] <Tom_itx> there's a young man with a lufa lib here that would know
[08:58:49] <OndraSter> he is not here :/
[08:59:17] <Tom_itx> i'm headin out the door too
[09:00:02] <OndraSter> well I just want to know - analog pins have input of 100M
[09:00:08] <OndraSter> digital should be the same or higher I presume?
[09:01:54] <Tom_itx> did you check the electrical spec section?
[09:01:59] <OndraSter> I did
[09:02:20] <Tom_itx> gotta go
[09:02:24] <OndraSter> bb
[09:08:14] <OndraSter> well this is weird
[09:08:18] <OndraSter> when I enable both INT0 and PCINT
[09:08:31] <OndraSter> (INT0 is "active low")
[09:08:55] <OndraSter> then when the INT0 fires the PCINT gets set when I put the PIN back to high
[09:10:14] <OndraSter> hmm
[09:10:26] <OndraSter> when I dont enter sleep it works
[09:17:41] <specing> OndraSter: there are different sleep levels ;)
[09:17:48] <OndraSter> yes
[09:17:50] <OndraSter> but PCINT should work anytime
[09:17:53] <OndraSter> and INT0 only on low-level
[09:18:02] <specing> OndraSter: obviously sinhronous stuff wont work while in sleep ;)
[09:18:10] <OndraSter> PCINT is async
[09:18:19] <specing> I dont know wherether it is or is not sync
[09:18:27] <specing> then it should just work
[09:18:27] <OndraSter> or at least datasheet says so
[09:18:29] <specing> (tm)
[09:32:20] <codematic> grr
[09:32:41] <codematic> has anyone gotten usb_bulk_read / writes to work with the LUFA usb stack ?
[09:32:53] <specing> yes
[09:33:03] <specing> abcminiuser did
[09:33:43] <codematic> well yea... can't seem to catch him ... :(
[10:10:06] <Posterdati> hi
[10:10:25] <Posterdati> is there any tutorial to program the atmega twi in c/c++? thanks
[10:10:53] <OndraSter> datasheet? :)
[10:10:55] <OndraSter> capn
[10:11:01] <OndraSter> where is capn' when you need him!
[10:13:24] <OndraSter> Power-down Mode
[10:13:24] <OndraSter> When the SM[1:0] bits are written to 10, the SLEEP instruction makes the MCU enter Powerdown
[10:13:24] <OndraSter> mode. In this mode, the Oscillator is stopped, while the external interrupts, and the Watchdog
[10:13:24] <OndraSter> continue operating (if enabled). Only an External Reset, a Watchdog Reset, a Brown-out
[10:13:24] <OndraSter> Reset, an external level interrupt on INT0, or a pin change interrupt can wake up the MCU. This
[10:13:25] <OndraSter> sleep mode halts all generated clocks, allowing operation of asynchronous modules only.
[10:13:35] <OndraSter> yet the diagram shows that pcint requires clock
[10:14:31] <Posterdati> is there any tutorial to program the atmega twi in c/c++? thanks
[10:20:58] <specing> Posterdati: go noob somewhere else
[10:21:42] <Posterdati> specing: who you?
[10:22:04] <specing> I master of universe and grammar
[10:23:15] <specing> and datasheets, mainly datasheets
[10:24:00] <specing> mmm
[10:24:16] * specing takes out his t2313 out of the drawer
[10:24:35] <Kevin`> :/
[10:24:49] * specing blows the dust of it
[10:24:57] <specing> off*
[10:26:54] <specing> I should get one of those coloured 15-column protoboards...
[10:27:04] <specing> They look damn sexy! :)
[10:28:48] <OndraSter> coloured? :o
[10:28:53] <OndraSter> picture!
[10:29:23] * specing tries to deliver
[10:30:24] <specing> http://www.seeedstudio.com/depot/mini-bread-board-45x35cmred-p-306.html?cPath=175
[10:30:50] <OndraSter> oh these
[10:30:54] <OndraSter> they are too small for me though :)
[10:31:00] <OndraSter> "that's what she said"
[10:31:03] <OndraSter> oh hey CapnKernel
[10:31:05] <OndraSter> wassup :)
[10:31:22] <smeding> why does a breadboard need to be sexy
[10:31:30] <OndraSter> everything has to be sexy
[10:31:32] <OndraSter> that's why I fail
[10:31:36] <specing> Heh
[10:31:42] <smeding> they just need to work for the first bit of prototyping
[10:31:51] <specing> Im still looking for pink CAT-5 UTP cables ;)
[10:32:02] <OndraSter> lol
[10:32:09] <OndraSter> pink rubber ends are not enough?
[10:32:13] <specing> no
[10:32:21] <specing> they must be pink all the way through
[10:32:30] <smeding> heh
[10:32:36] <specing> Im looking for a raw cable though
[10:32:39] <smeding> even the single wires must have pink insulation
[10:32:43] <smeding> and the copper must be pink too
[10:32:47] * specing has the equipment for making them
[10:32:55] <smeding> and, well, UTP is around for a longer time so i get that :p
[10:33:09] <specing> smeding: wires must be coloured so I know what to connect ;P
[10:34:13] <specing> A local distributor has red/yellow/blue/grey/white cables but not PINK!!!111oneone
[10:35:50] <specing> I found a shop in the US^W^Whell but it would probably fall under export restrictions
[10:36:05] <specing> and I'd have to pay massive shiping too
[10:42:48] <specing> man are those protoboards sexy.
[10:50:30] <tomatto> hi
[10:50:31] <tobbor> Hello tomatto
[10:51:24] <tomatto> please do you have any experience with this Converter from USB to Parallel? http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund um den PC/USB2LPT/ul-16.en.htm
[10:53:06] <specing> fail url
[11:02:48] <tomatto> specing: what about this http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/USB2LPT/ul-16.en.htm
[11:02:51] <tomatto> ?
[11:05:06] <specing> no
[11:08:09] <tomatto> onvalid url?
[11:11:38] <Kevin`> tomatto: usb is to slow to use for bitbanging io btw, if that's what you need a parallel port for
[11:13:34] <tomatto> Kevin`: i need full parallel port
[11:13:47] <Kevin`> for?
[11:15:44] <OndraSter> CapnKernel, you around?
[11:17:01] <tomatto> Kevin`: for printer etc.
[11:17:20] <Kevin`> tomatto: those will work for a printer, but they won't for some some other uses of a parallel port
[11:17:26] <tomatto> Kevin`: i made that device, but it doesn't work, when i connect it to usb, nothing happend
[11:17:51] <Kevin`> tomatto: how did you program the avr on it?
[11:18:26] <tomatto> Kevin`: how or do you mean with what equipment?
[11:19:14] <Kevin`> tomatto: just making sure you did it. is there really no crystal for that device btw? i'm suprised it can do usb on a chip with no pll and no crystal
[11:19:56] <tomatto> Kevin`: i tried it with crystal too, but no other results
[11:20:59] <Kevin`> what happens when you connect it to usb?
[11:22:03] <tomatto> Kevin`: nothing at all
[11:22:55] <Kevin`> tomatto: the initial device detection (before probing) is just based on the state of the control lines. if it's connected to the computer (and if the firmware is running, if there's no pull resistors), you should see messages
[11:25:57] <tomatto> Kevin`: only this http://pastebin.blesmrt.net/2609/
[11:26:40] <Kevin`> I would expect to see 'new low-speed device blah blah'
[11:26:48] <Kevin`> check your wiring
[11:27:37] <tomatto> Kevin`: i check it already more than twenty times. i made pcb exactly the same from his layout
[11:28:21] <Kevin`> does that device have pullup/pulldown resistors on the datalines or is the initial state driven from software?
[11:29:45] <tomatto> Kevin`: it has pullup 10k resistor to D- of USB
[11:30:47] <Kevin`> how's d+ handled
[11:33:15] <tomatto> Kevin`: directly to uP via 220R resister, same as D- and this resistor is that pullup 10k rezistor for D-
[11:33:34] <Steffanx> hi
[11:33:44] <Steffanx> tobbor ?!
[11:33:47] <Steffanx> :(
[11:41:14] <OndraSter> hmm did Atmel forgot to write what does "weak IO pin" mean?
[11:41:20] <OndraSter> is it 1mA? 5mA?
[11:45:24] <OndraSter> oh nvm
[11:45:26] <OndraSter> it is there
[11:45:28] <OndraSter> just well hidden
[11:45:35] <tomatto> Kevin`: what do you think?
[11:45:56] <Kevin`> tomatto: have a logic analyser>
[11:46:42] <tomatto> Kevin`: no, i haven't
[11:46:49] <OndraSter> wtf, supposedly they should differ but they do not
[11:46:54] <OndraSter> oh well, 5mA it hopefuly will do
[11:47:26] <OndraSter> http://clip2net.com/s/2a8Vc vs http://clip2net.com/s/2a8Vk
[11:48:06] <OndraSter> well, by a bit it differs
[11:51:36] <age> haha
[11:52:16] <age> so here I was wondering, why my own PCB for USBasp does program, but won't even light a led. turns out I pulled RESET to ground :>
[11:52:50] <age> I mean, the mega48 on it gets programmed.
[11:58:29] <specing> Has anyone ever changed the background of a pdf file?
[11:58:58] <specing> My eyes are annoyed when switching from terminal to the attiny pdf
[11:59:11] <tomatto> Kevin`: any idea without login analyser?
[12:00:46] <age> specing, your PDF viewer may have a negative mode. evince does.
[12:01:33] <CapnKernel> OndraSter: I'm here :-)
[12:02:13] <age> awesome, my 30x40mm USBasp PCB works! :P
[12:04:59] <age> just one question: why would one want to pull RESET up? can it spontaneously activate for some reason if not pulled up?
[12:05:44] <OndraSter> air can pull it down and reset it!
[12:05:49] <dirty_d> well if its low, it will reset
[12:05:55] <dirty_d> if its not driven it will float
[12:06:07] <age> ah, floating, yes.
[12:06:19] <OndraSter> well reset has internal pullup
[12:06:22] <OndraSter> 80k on attiny
[12:06:26] <age> oh
[12:06:48] <age> then I won't be fixing my PCB and just leave it as is.
[12:30:50] <CapnKernel> I believe the pull-up on RESET is somewhat weaker than the other pins, in order to allow HV programming. That's why a separate pull-up is recommended.
[12:34:01] <dirty_d> CapnKernel, are you still in china?
[12:35:14] <Steffanx> dirty_d his ip says: Yes
[12:35:26] <dirty_d> lol
[12:36:17] <CapnKernel> Yep still here.
[12:37:56] <Kevin`> tomatto: check with a multimeter. you won't be able to monitor much of the initialization, but you should see enough to get the device "detected"
[12:42:47] <CapnKernel> I have one more month here
[12:42:59] <CapnKernel> Then back to my family for a month.
[12:44:12] <tomatto> Kevin`: what should i see?
[12:44:47] <Kevin`> tomatto: you should see, before connection, one pin driven high and one pin driven low. I forget which
[12:47:01] <tomatto> Kevin`: D- ?
[13:04:09] <codematic> abcminiuser : you around ?
[13:04:23] <abcminiuser> Yeah just uploading the next LUFA release
[13:04:37] <codematic> sweet :)
[13:05:21] <codematic> i sent you an email at your fourwalledcubicle address...about how to get usb_bulk_read / writes working on Windows Libusb...
[13:05:37] <abcminiuser> Yeah got it, haven't had time to read through it yet
[13:05:42] <abcminiuser> If you give me 20 mins I can take a look
[13:05:59] <OndraSter> abcminiuser, while you are here - I couldn't find input impedance of digital IO pins?!
[13:06:02] <OndraSter> only analog one with 100M
[13:06:13] <abcminiuser> OndraSter, hrm
[13:06:19] <abcminiuser> Not in the electrical specs section?
[13:06:23] <OndraSter> nope
[13:06:28] <OndraSter> either I was blind or it isn'T there
[13:06:30] <OndraSter> isn't*
[13:06:32] <codematic> sure not a problem... i can send you the rest of the code so you have the whole picture.
[13:06:52] <OndraSter> it says 1uA leakage
[13:07:00] <abcminiuser> codematic, great, I'll get back to you once I'm done with the release upload
[13:07:11] <abcminiuser> OndraSter, it should be pretty minimal, given it's an input
[13:07:29] <abcminiuser> IIRC the internal pullups are about 100K, so disable them if you hard-drive the input
[13:07:47] <OndraSter> well I have got one button with external pullup - I want to know if I can use 665k pullup for it
[13:08:04] <OndraSter> I am optimizing it for the lowest possible power use because it runs from coin cell
[13:08:31] <OndraSter> I suppose I could measure it if I had here one attiny to test it with :)
[13:09:25] <abcminiuser> OndraSter, disable pullups, turn of the analog comparitor
[13:09:29] <abcminiuser> Use all PRR bits
[13:09:41] <abcminiuser> Deepest sleep mode
[13:09:57] <abcminiuser> And use DIDR if you use the ADC
[13:10:42] <OndraSter> sure
[13:10:48] <OndraSter> DIDR?
[13:45:24] <abcminiuser> OndraSter, Digital Input Disable register for devices with an ADC
[13:45:36] <OndraSter> oh
[13:45:39] <abcminiuser> It disables the digital input buffer completely if set
[13:45:48] <OndraSter> this is the first time I am hearing about that :o
[13:46:35] <codematic> abcminiuser : how can i determine the maximum size the endpoint can have on the atmega32u4 ?
[13:46:52] <codematic> looks like if i try and make the input and output endpoints at 400bytes nothing works.
[13:47:15] <codematic> so im guessing i dont understand how the banking system allocates its buffers.. :(
[13:47:33] <abcminiuser> codematic, it's in the USB section of the datasheet, search for "max 64"
[13:47:44] <codematic> k
[13:47:58] <abcminiuser> Ok, LUFA 120730 released now
[13:48:51] <abcminiuser> codematic, just saw your code
[13:49:19] <abcminiuser> Are you wrapping the read in a loop?
[13:49:28] <abcminiuser> So that it actually processes all the data eventually?
[13:49:45] <codematic> i think so...
[13:50:10] <abcminiuser> You should also conditionally wrap it after the endpoint selection with if (Endpoint_IsOUTReceived())
[13:50:38] <codematic> while(Endpoint_BytesInEndpoint())
[13:51:11] <codematic> doesn;'t that only trigger if a new packets come in ?
[13:51:30] <abcminiuser> You need to make sure there's a packet first
[13:51:33] <codematic> or does it stay triggered as long as there is data in the out fifo ?
[13:51:39] <abcminiuser> On AVR8 it doesn't really matter, but on XMEGA it does
[13:51:46] <codematic> oh.. ok.
[13:51:53] <abcminiuser> You check first that there's a packet, then read until the bank is empty
[13:52:09] <codematic> i was using the Endpoints_bytesinpoint to determine if data was there.
[13:53:09] <codematic> datasheet shows : – Fully independent 832 bytes USB DPRAM for endpoint memory allocation...
[13:53:13] <codematic> for endpoint memory
[13:54:04] <abcminiuser> codematic, yes you can slice that up into banks for each endpoint
[13:54:18] <abcminiuser> But you cannot have bulk endpoints above 64 bytes for Full Speed USB devices
[13:54:30] <codematic> oh
[13:54:33] <codematic> really ?
[13:54:34] <codematic> ok
[13:55:30] <abcminiuser> Yeah it's a USB spec thing
[13:55:44] <codematic> yea i remember that now...
[13:55:55] <codematic> "Configurable Endpoints size up to 256 bytes in double bank mode"
[13:56:35] <codematic> if i set the banks to double bank mode i can get 256 internally, but it will only send 64 bytes at a time though right ?
[13:57:08] <abcminiuser> No
[13:57:18] <abcminiuser> Isochronous type endpoints can be bigger
[13:57:23] <abcminiuser> Bulk is limited to 64
[13:57:34] <abcminiuser> But you can double bank it to make it a bit faster (kinda like double buffering)
[13:57:40] <codematic> ok... yea..
[14:08:21] <codematic> abcminiuser : how do i indicate that my internal buffers are full back to the host ? IE send A NAK ? (for Bulk Writes)
[14:08:44] <abcminiuser> Not doing anything NAKs it
[14:08:56] <abcminiuser> So you do nothing until you can handle it or the host gives up
[14:09:06] <abcminiuser> If you want to abort it from the device side, stall the endpoint
[14:09:25] <codematic> oh if the internal FIFO is empty then the avr will NAK the request then ?
[14:18:13] <abcminiuser> Ja
[14:23:13] <codematic> On the IN Direction, how do i know how much data the USB fifo can handle ?
[14:25:48] <codematic> my Guess is to use Endpoint_IsReadWriteAllowed()...
[14:33:09] <age> with a 1024-prescaled 12 MHz clock, timer in CTC mode and OCR0 = 1, shouldn't I be getting the prescaled clock on OC0 pin?
[14:35:43] <specing> DDR?
[14:36:57] <age> specing, set
[14:37:32] <age> unless my code is broken.
[14:39:42] <age> http://codepad.org/h53xgxhG
[14:40:54] <age> supposed to poll PB1, if it's high -- light a led on PD0 and set OC0 as output
[15:24:25] <chupas> I have an AVR with a 20MHz crystal that seems to be unstable
[15:24:42] <chupas> it may or may not start out ok, but after 30sec it starts to do strange things
[15:25:00] <Kevin`> chupas: is the chip you are using rated for 20mhz at the voltage you are using?
[15:25:07] <chupas> or if i touch the crystal cap it will immediately go bad
[15:25:09] <chupas> yes it is
[15:25:37] <Kevin`> touching the crystal would be expected to have that effect, although you also might have the driving strength set low when it should be high
[15:25:56] <chupas> I mean i have another board right next to it. and it dose not do that
[15:26:02] <Kevin`> do you have an oscilloscope?
[15:26:17] <chupas> i know touching it will mess it up. but I would not expect it to crash the thing like it seems to be
[15:26:33] <chupas> I do. I am going to try to measure clock out, but I think the pin is tied up :-(
[15:26:49] <Casper> chupas: check for CKOPT / full swing oscillator
[15:27:03] <Kevin`> yeah. you could measure on the crystal output of course, but that will almost surely load it down
[15:27:11] <Kevin`> measuring on the avr's clock output is better
[15:27:18] <Casper> also, be sure that you have proper capacitors
[15:27:18] <Casper> and
[15:27:24] <Casper> that you ain't using a breadboard
[15:27:35] <chupas> its a board. I am going to replace the caps
[15:27:51] <Kevin`> chupas: also, you could connect the avr to a signal generator at 20mhz instead of the crystal to eliminate one or the other as a problem
[15:28:30] <chupas> Will do
[15:28:33] <chupas> TY!
[15:28:49] <Casper> chupas: check the fuse first
[15:28:59] <chupas> Im pretty sure i checked it last night and it was set correctly
[15:29:03] <chupas> going to double check now
[15:29:32] <Casper> some avr have a CKOPT too
[15:37:56] <chupas> Eh extxosc_8mhz
[15:37:58] <chupas> seems correct
[15:39:36] <Upu> Hi there wonder if someone can assist, I have a ATmega328 on a PCB with no external oscillator, its fresh out of the packet. Should I be able to read the signature on the chip using AVRDUDE without doing anything else ?
[15:40:05] <Upu> avrdude -pm328p -c stk500v2 -P /dev/ttyACM0 -F -B 6
[15:40:38] <OndraSter> if it is not set to use external xtal - yes
[15:41:06] <Upu> ok
[15:41:35] <Upu> wondering if this is a chip I reclaimed from something
[15:41:56] <Upu> sure I picked a new one, ok thanks I'll stick a crystal on there tomorrow and see if it works
[15:42:29] <OndraSter> you can use another mega to generate clock
[15:44:14] <Upu> I'd have to solder a connection on to the chip anyway so I might as well put a crystal on there
[15:44:43] <Upu> http://i.imgur.com/Xg7Pu.jpg
[15:45:37] <OndraSter> :)
[15:45:46] <OndraSter> I like the VCC/GND labels
[15:45:52] <Upu> well
[15:46:03] <Upu> no protection diode :)
[15:46:19] <OndraSter> :)
[15:46:55] <Upu> thanks anyway I'll put a crystal on tomorrow
[15:49:16] <OndraSter> like I said
[15:49:16] <OndraSter> <OndraSter> you can use another mega to generate clock
[15:49:19] <OndraSter> you can do it today :)
[15:49:33] <Upu> don't have a soldering iron here saldy
[15:49:39] <OndraSter> hook probes!
[15:49:41] <OndraSter> :D
[15:49:46] <Upu> no where to hooky :)
[15:50:08] <Upu> I assume you connect them to the crystal pads ?
[15:50:17] <Upu> I have a few Arduino's here
[15:52:54] <OndraSter> connect "them"
[15:52:57] <OndraSter> them = what?
[15:55:24] <OndraSter> wow, one can run attiny13a down to 62.5Hz using internal oscillator!
[15:55:32] <OndraSter> 128kHz oscillator, ckdiv8 fuse and prescaler 256 :)
[16:05:29] <Kevin`> clkdiv8 sets the initial value of the prescaler
[16:06:12] <OndraSter> yes
[16:06:21] <OndraSter> and then the prescaler down to 62.5Hz
[16:06:25] <OndraSter> and with*
[16:06:40] <Kevin`> what i'm saying is you end up with just /256, not /8/256
[16:07:11] <Kevin`> if you set clkdiv8 the prescaler is set to /8 on startup
[16:07:12] <OndraSter> oh
[16:07:17] <OndraSter> darn
[16:07:26] <Kevin`> you can set it higher or lower in code after
[16:07:29] <specing> OndraSter: you can run attiny13a down to 0Hz!
[16:07:36] <OndraSter> specing, sleep mode!
[16:07:39] <OndraSter> or set it to use external xtal
[16:07:44] <OndraSter> external source*
[16:07:46] <specing> no, poweroff
[16:07:50] <OndraSter> or that
[18:00:57] <OndraSter> oh god
[18:01:03] <OndraSter> remember my today's issue with PORTB/PINB?
[18:01:06] <OndraSter> err
[18:01:12] <OndraSter> with PCINT?
[18:01:14] <OndraSter> and INT0?
[18:01:22] <OndraSter> well, I was so smart to change PORTB instead PINB register lol
[18:02:51] <Tom_itx> :)
[18:06:00] <OndraSter> hah I am so smart
[18:06:04] <OndraSter> ;D
[18:06:18] <Steffann> You are sooo smart OndraSter
[18:06:26] <OndraSter> I know, right!
[18:06:30] <OndraSter> that's what she said!
[18:07:02] <Steffann> I think your mother says that all the time
[18:07:04] <OndraSter> the firmware pretty much works on the first time (except that I wrote PORTB instead PINB in one SBIS and I was setting PORTB register than PINB)
[18:07:29] <OndraSter> we are talking 184B of asm code :P
[18:07:40] <OndraSter> without logic mistake! :P
[18:07:49] <OndraSter> well, maybe timing will be off, I don't trust simulator in that
[18:07:52] <OndraSter> but even sleep works!
[18:08:05] <Steffann> Congratz
[18:08:09] <OndraSter> thanks
[18:09:48] <OndraSter> abc
[18:09:50] <OndraSter> oh he is gone again
[18:09:50] <OndraSter> damnit
[18:35:02] <specing> He may be smart, but Im even smarter!
[18:41:49] <OndraSter> yeaaaahhh... surrre :D
[18:42:49] <specing> You can't do anything about it
[18:42:58] <specing> My EGOmeter just went over 9000
[18:44:02] <Tom_itx> or tilt
[18:44:52] <OndraSter> darn how I wish I had TWO counters in the tiny13a!
[18:45:26] <specing> err
[18:45:37] <OndraSter> I don't need analog comparator
[18:45:54] <specing> Why do you need two for?
[18:46:33] <OndraSter> one that would be doing the actual counting of the "random" number and one that would keep refreshing the number on the front (if I were charlieplexing them)
[18:47:02] <specing> You could use the watchdog as an emergency timer ;P
[18:47:07] <OndraSter> heh
[18:47:08] <specing> if it has one, ofc.
[18:47:13] <OndraSter> that's a good idea actually
[18:47:34] * specing 's EGOmeter > 999999
[18:48:03] <specing> And since you are doing random numbers you need something innacurate
[18:48:12] <specing> -n +c
[18:48:14] <Tom_itx> careful he's gonna blow any sec
[18:48:22] <specing> :)
[18:48:31] <OndraSter> :D
[18:48:53] <OndraSter> I am using already three stuff:
[18:48:59] <specing> you can also use the comparator for this
[18:49:04] <OndraSter> number from SRAM somewhere:
[18:49:07] <OndraSter> (a)
[18:49:16] <OndraSter> (b) value from ADC (battery/3)
[18:49:38] <OndraSter> (c) I keep changing the number as long as he has pressed the button
[18:49:45] <specing> if you set it to compare Vdd to Vdd from a 50cm wire...
[18:49:56] <specing> Its gonna go nuts ;P
[18:50:04] <specing> or with something else
[18:50:12] <specing> I haven't used the AC yet
[18:50:24] <OndraSter> aaa watchdog's MINIMUM is 16ms :(
[18:50:27] <OndraSter> too slow
[18:50:29] <OndraSter> TOO SLOW!
[18:50:39] <karlp> what?!
[18:50:49] <OndraSter> karlp, if I were to use it as second counter :D
[18:51:37] <OndraSter> that's 63 changes per second
[18:51:41] <specing> just get an xmega ffs ;P
[18:51:43] <OndraSter> that could be actually enough for the random number generation
[18:51:47] <OndraSter> specing, this is attiny
[18:51:49] <OndraSter> xmega is too big :P
[18:51:52] <OndraSter> and too expensive
[18:51:59] <specing> heh
[18:52:01] <OndraSter> whole board + parts is sub-3€
[18:52:24] <karlp> if you're making it that small, it doesn't need to be real seconds anyway
[18:52:32] <karlp> just somethign in the same general area as seconds.
[18:53:34] <OndraSter> if it is too slow people will be able to catch the number 6 :P
[18:53:41] <OndraSter> but 62.5 shouldn't be that slow :D
[18:53:45] <OndraSter> 62.5 times per second
[18:53:48] <OndraSter> + random seed
[18:53:49] <OndraSter> "random"
[18:58:44] <specing> I just love this 18.432 Mhz crystal
[18:58:54] <specing> everything divides nicely
[19:00:28] <Tom_itx> almost by design... huh?
[19:00:45] <OndraSter> :D
[19:00:49] <OndraSter> just almost though!
[19:04:41] <specing> No kidding, I soldered it off a ISA serial/parallel card :P
[19:05:47] <OndraSter> :D
[19:05:55] <OndraSter> hmm time to change the board connections to real charlieplexing
[19:06:04] <OndraSter> I will be able to controll them manually!
[19:43:52] <specing> Grrr CTC on T1 doesen't work for the first time, there must be something wrong with the timer module...
[20:30:14] <OndraSter> specing, OR...
[20:30:19] <OndraSter> are you suuuuuure?
[20:30:29] <OndraSter> maybe PEBKAC?
[20:30:32] <OndraSter> it is getting late :)
[20:38:01] <OndraSter> woot something during this week the parts for my xboard should come
[20:38:09] <OndraSter> and I shall be finally able to start developing the bootloader for it!
[20:48:36] <SuperMiguel> whats wrong with avr studio 4.9? why ppl hate it?
[20:48:54] <OndraSter> it is ooooold
[20:48:57] <OndraSter> the UI is :/
[20:48:58] <OndraSter> meh
[20:49:04] <OndraSter> and the gcc is not built in
[20:49:17] <SuperMiguel> it is in studio 5 and 6?
[20:49:27] <Tom_itx> i believe so
[20:50:09] <OndraSter> yes
[20:51:54] <SuperMiguel> Tom_itx: OndraSter u guys use 6?
[20:53:01] <Tom_itx> i dl it but haven't installed it
[21:22:54] <k-man> i want to build a battery charging/power supply cuircuit for my project that will allow me to just plug in to charge and power the project
[21:24:06] <k-man> should I just buy something like this? https://www.sparkfun.com/products/11231
[22:01:15] <R0b0t1> k-man: Don't buy anything from sparkfun if you can avoid it.
[22:59:14] <k-man> R0b0t1, why?