#avr | Logs for 2015-01-03

Back
[00:21:29] <inflex> urrrrugh - why did Eagle go and try change their icons?
[00:21:36] <inflex> Really, they were bad enough originally... but now they're WORSE
[00:34:05] <Casper> because they went from good to average?
[00:36:27] <inflex> Casper: I'd say they've gone from poor to terrible. At least previously they were contrasted and detailed, now they're blurry and indistinct
[00:36:53] <Casper> I once considered strongly to buy it
[00:37:07] <Casper> now... the price went up terribly
[00:37:08] <inflex> I have already got a full licence for it
[00:37:19] <inflex> huh? How much for what you were wanting?
[00:37:23] <Casper> for a software that I do not find to be worth the price...
[00:37:31] <Casper> have you checked the price recently?
[00:37:42] <inflex> $575 for standard schem+layout
[00:38:02] <inflex> or I think $49 for the restricted
[00:38:46] <inflex> Eagle light $69
[00:39:18] <Casper> 160x100mm is too small for what I need...
[00:39:21] <Casper> so unsuited
[00:39:35] <inflex> fair enough
[00:39:36] <Casper> so would need eagle pro
[00:39:43] <inflex> what size boards do you need?
[00:39:44] <Casper> 1145$
[00:40:00] <Casper> atleast 6x6"
[00:40:05] <inflex> ah ok
[00:40:24] <Casper> so like 150x150mm, but some board need to be like 200-300x50mm
[00:40:25] <inflex> ja, for me it's always been a case of sub 1x1" msot of the time, and now maxing out at 2x2" or MAYBE 2x4"
[00:41:30] <inflex> for my requirements, Eagle is good, $69 was cheap ( well, $49 when I got it ) and I was happy, for your needs, yep, doesn't really fit.
[00:42:05] <hypermagic> 1149851
[00:42:44] <Casper> it used to be like 400$ for what fit my needs years ago
[01:28:24] <hackvana> Casper: Many of my customers use KiCad (and have switched to KiCad from Eagle). You can ask for help in #hackvana or #kicad
[01:28:52] <hackvana> Can your CAD package do this? https://www.youtube.com/watch?v=CCG4daPvuVI
[01:28:52] <Casper> hackvana: when I'll need to make another board, I'll try kicad
[01:29:11] <hackvana> http://hairy.geek.nz/2013/10/switching-to-kicad/
[01:32:01] <Casper> hackvana: look nice
[01:34:46] <Casper> hackvana: is there an eagle to kicad converter?
[01:34:59] <hackvana> Sort of.
[01:35:25] <hackvana> I believe KiCad can read Eagle layouts (although as you expect, lots of info is lost), and KiCad can read Eagle footprints.
[01:36:14] <hackvana> Just a warning: All EDA packages suck. The thinking behind KiCad is quite different to Eagle, and when you first start using KiCad, you can expect it to piss you off, a lot.
[01:36:59] <Casper> What about transistors pads, can you easilly move them?
[01:37:23] <Casper> in eagle, that is a royal pita... need to redesign a new package, delete the part and add the new one...
[01:38:07] <inflex> Casper: actually, all you have to do is move the pad in the design/part, then reload the lib
[01:38:11] <hackvana> I think most EDA packages will have the notion of a footprint, which you define. The individual pads in a footprint are not designed to be moved independently of the other pads in that footprint.
[01:39:14] <hackvana> Yeah. Similarly in KiCad: Open the footprint editor, alter the footprint, and there's a button to update a/all footprints on the board.
[01:39:34] <Casper> inflex: then that change it permanantly on all future schem..
[01:39:39] <hackvana> If you need to vary your footprint, make several with the variatioon you want.
[01:40:03] <inflex> Casper: yes, it's a permanent change.
[01:40:07] <hackvana> In KiCad, schematic symbols and footprints are completely separate.
[01:40:10] <Casper> yeah, but it's annoying when you see some board limitation...
[01:40:15] * inflex just keeps multiple variants if required, under the same part name
[01:40:36] <inflex> easy enough to just clone the part to a new variant
[01:40:43] <inflex> (under the same part name )
[01:40:50] <hackvana> And there's a step where you associate symbols with footprints, eg, "this 555 symbol is associated with DIP-8, this ATtiny is associated with SOIC-8"
[01:41:11] <inflex> anyhow, back to work fro me
[01:42:30] <inflex> I've got plenty of gripes about Eagle, but for the price ($49 at the time) I can't complain
[01:42:57] <Casper> yeah
[01:43:13] <inflex> I would like if it learned to move bevelled/45/corner traces in/out without having to individually move the segments
[01:43:45] <Casper> at 300$ back then, it was okish... but then I realised that it give you access only to free minor updates, that the bugs were still severe, that wouln't be fully fixed in that one...
[01:44:01] <Casper> then they made a new major version soon after, and bumped the price
[01:44:32] * inflex bought his back when it was v5.0 or so... happy to see the licence still is valid
[01:45:09] <inflex> I think when you're starting to get extra serious you need to get in to those $$$$ suites
[01:45:28] <inflex> Still, all 100000x better than the old days of drafting PCBs by hand... ugh that was horrid
[01:46:00] <Casper> hehe yeah for sure
[01:46:11] <Casper> but currently my main issue is actually making the boards...
[01:46:28] <Casper> projects get put off because I can't make board at home anymore
[01:46:39] <Casper> and the 2-5 weeks for making the board is too long :D
[02:01:15] <hackvana> I can have you boards in as little as 5 days.
[02:02:34] <Casper> hackvana: to canada?
[02:02:47] <Casper> at a good price?
[02:29:16] <hackvana> Casper: Yes and yes.
[02:29:36] <Casper> I'll try to remember that
[02:29:54] <Casper> I need to make a refrigerator controller
[02:30:03] <hackvana> Come hang out in #hackvana :-)
[02:30:19] <Casper> maybe with a way to figure out when it's time to unfreeze it
[07:42:09] <antto> if an output pin on an atmega (at 5V vcc) measures constant 2.6V when there should be 0V - what could this be?
[07:43:21] <antto> i suspect something with the pcb.. pins shorted or something (since the atmega is SMD)
[07:43:29] <antto> but could it be something else?
[07:43:38] <RikusW> is ddr set as output ?
[07:43:53] <antto> the pin?
[07:44:03] <RikusW> yes the ddr bit for the pin
[07:44:21] <antto> it's set as output surely, because that same firmware works on a pile of other such setups
[07:45:29] <RikusW> pwm on the pin might cause it
[07:45:56] <antto> uhm
[07:46:09] <antto> the firmware doesn't do PWM on that pin
[07:46:16] <antto> it just turns it on/off from time to time
[07:49:29] <Lambda_Aurigae> you have something wrong with the chip or the circuit
[07:50:01] <antto> yeah, that's what i suspect too
[07:50:09] <antto> thanks
[07:55:38] * RikusW too
[09:53:01] <tpw_rules> anybody experienced with v-usb?
[09:53:18] <tpw_rules> and willing to help someone who asks lots of stupid questions
[10:27:51] <davor> how much of a benefit is there between using an atmega328p with an 8 MHz crystal versus its own internal 8 MHz oscillator?
[10:29:00] <LeoNerd> Accuracy
[10:29:15] <LeoNerd> If you care about accuracy of timing, it's better. But then it uses two more pins you can't now use for GPIO
[10:30:14] <davor> where would the internal oscillator be unsuitable as opposed to a crystal?
[10:30:18] <davor> what kind of applications?
[10:30:37] <LeoNerd> If you don't care about timing as much
[10:32:15] <davor> I mean, where do I care about timing? when does it come in as a concern? I know it's a fairly bad question as it cannot really be answered definitively, but surely there's something concrete where the built-in oscillator just doesn't cut it
[10:32:21] <davor> what about SPI for instance?
[10:32:43] <LeoNerd> If you care that a 1000msec delay is exactly 1000msec
[10:32:46] <LeoNerd> If you are displaying a clock
[10:32:52] <LeoNerd> If you are doing things where the aboslute value of time is important
[10:32:59] <LeoNerd> SPI doesn't care about timing...
[10:33:07] <davor> ah, right
[10:33:21] <davor> how much of an offset from 1000 ms would it be?
[10:33:25] <LeoNerd> The internal 8MHz oscillator could be +/- 2% or so
[10:33:34] <LeoNerd> A crystal is a few parts per million.. i.e. 0.0001%
[10:33:39] <davor> ah, that's a massive difference
[10:33:41] <davor> thanks LeoNerd
[10:33:58] <davor> oh, and I take it the crystal is far less temperature-dependent?
[10:34:15] <LeoNerd> Far less, yah
[10:34:42] <davor> awesome. I'll put one in, thanks.
[10:40:43] <Lambda_Aurigae> internal oscillator is not so good for things like usart comms...it can drift with chip temperature and input voltage.
[10:41:14] <Lambda_Aurigae> 2% drift can mean the difference of communicating or not.
[10:41:40] <Lambda_Aurigae> I've done usart comms on the internal rc oscillator but found I had to recalibrate if I was running it too long.
[10:49:30] <Lambda_Aurigae> that being said, I understand the newer series chips have much more stable RC oscillators.
[11:02:04] <DKordic> davor: I guess the internal oscilaator is not accurate enough for USB. Check it's documentation.
[11:02:31] <LeoNerd> If you have a fast enough base CPU rate and a slow enough UART, you can write yourself a self-synchronising soft UART for receiving at least
[11:02:45] <LeoNerd> Internal RC osc. can be good eonugh for receive-only UART
[11:04:33] <Lambda_Aurigae> DKordic, internal rc oscillator on some chips with the clock pll can do v-usb..but only on those chips with pll.
[11:05:05] <Lambda_Aurigae> all depends on your application.
[11:07:18] <LeoNerd> ooooh clock PLL?
[11:07:22] <DKordic> Lambda_Aurigae: Like XS1-G4 :) .
[11:07:57] <Lambda_Aurigae> DKordic, never heard of it.
[11:09:19] <DKordic> The new Transputer. Almost every peripheral is done in software. xcore.com
[11:10:06] <Lambda_Aurigae> transputer again, eh?
[11:12:08] <LeoNerd> Isn't that basically an FPGA?
[11:12:19] <Lambda_Aurigae> kinda.
[11:12:28] <Lambda_Aurigae> it's a processor fpga hybrid thingie, kindasorta.
[11:12:42] <DKordic> They say it is an alternative to low end FPGAs.
[11:12:50] <Lambda_Aurigae> or rather, the original transputers were.
[11:12:55] <Lambda_Aurigae> haven't looked at this new one yet.
[11:29:01] <Gaboose> I flashed this attiny85 + nrf24l01 example program and it stop looping after a few iterations
[11:29:26] <Gaboose> only to start again when I put my fingers at about 3cm from the chip
[11:30:10] <Gaboose> it halts on this line: radio.write( &payload ...
[11:30:11] <Gaboose> https://github.com/TMRh20/RF24/blob/master/examples/rf24_ATTiny/rf24ping85/rf24ping85.ino#L80
[11:30:26] <Gaboose> wat da hell?
[11:30:52] <Lambda_Aurigae> how about a nice schematic?
[11:31:19] <Lambda_Aurigae> where is the crystal connected?
[11:31:32] <Lambda_Aurigae> or, how is the clock source set?
[11:31:59] <Gaboose> i tried 8mhz and 1mhz internal clocks
[11:33:14] <Gaboose> it behaves like that even if I connect only Vcc, GND and PB3 (for Serial.println statements)
[11:39:44] <Gaboose> i can try and draw a schematic, but it may take a while and the connections are pretty simple
[11:41:29] <Lambda_Aurigae> tiny85..can't be too difficult.
[11:42:07] <Lambda_Aurigae> do you have another chip?
[11:42:13] <Lambda_Aurigae> how are the fuses set?
[11:45:32] <Gaboose> (low, high, ext) E2 D7 FF for 8mhz, 62 D7 FF for 1mhz
[11:45:42] <Gaboose> latter one currently
[11:47:08] <Gaboose> BOD disabled
[11:49:20] <Gaboose> why would the code halt on the write statement specifically?
[11:49:36] <Lambda_Aurigae> does it block?
[11:49:48] <Lambda_Aurigae> like, does the write statement wait for a return of some kind?
[11:50:25] <Jartza> seems so
[11:50:40] <Lambda_Aurigae> without seeing the code, no way to know what's going on.
[11:51:12] <Jartza> I'm guessing it's this: https://github.com/TMRh20/RF24/blob/master/RF24.cpp
[11:51:33] <Jartza> write starts at line 822
[11:51:46] <Jartza> while( ! ( get_status() & ( _BV(TX_DS) | _BV(MAX_RT) ))) {
[11:51:47] <Jartza> ...
[11:52:54] <Jartza> Gaboose: are you sure the spi communication works correctly?
[11:52:58] <Jartza> and the device is wired correctly
[11:53:33] <Joggl> logic analyzer ftw.
[11:53:38] <Jartza> yes
[11:53:50] <Jartza> and are you sure you aren't overvoltaging it?
[11:54:12] <Joggl> oszi ftw ;)
[11:55:17] <Jartza> oszi is some kind of german thing ;)
[11:55:28] <Jartza> the rest of the world talks about "scope" or "oscope" ;)
[11:55:52] <Gaboose> im using this for a 3.3V Vcc http://codeandlife.com/wp-content/uploads/2012/01/usb_tutorial-1b.jpg
[11:56:16] <Gaboose> spi communications is as correct as the library is..
[11:56:56] <Gaboose> if i had one of those logic analyzers could I just tap the MISO MOSI wires and see what the chips are talking?
[11:57:24] <Jartza> yes
[11:57:29] <Jartza> sck, mosi, miso and stuff
[11:58:00] <Jartza> any debugging of spi/i2c/etc buses is hard without logic analyzer or oscilloscope
[11:58:02] <Lambda_Aurigae> and what are you powering it with?
[11:58:10] <Jartza> yes, what's the input voltage
[11:58:32] <Joggl> Jartza, o0 i am caught...
[11:58:37] <Lambda_Aurigae> must be at LEAST 4.6V with that regulator. some USB ports only give 4.25V even.
[11:58:58] <Jartza> Joggl: :D
[11:59:09] <Jartza> isn't that adjustable regulator?
[11:59:26] <Jartza> it needs some kind of feedback to adj pin?
[11:59:35] <Lambda_Aurigae> can be either adjustable or fixed at 1.8, 2.5, 3.3, 5, or 12V
[11:59:45] <Jartza> oh, ok
[11:59:48] <Lambda_Aurigae> depends on the particular version of the chip.
[12:00:10] <Gaboose> it's a phone chrager from a wall socket. I read 5.2V on it
[12:00:11] <Lambda_Aurigae> it is LDO but has a 1.3V LDO voltage at 1.5A
[12:02:10] <Lambda_Aurigae> running this thing on a solderless breadboard I take it?
[12:02:32] <Gaboose> yes
[12:02:58] <Lambda_Aurigae> any and all not used i/o pins set to input need to be connected to GND.
[12:03:25] <Joggl> what controller?
[12:03:49] <Lambda_Aurigae> lots of stray capacitance on a solderless breadboard.
[12:04:04] <Lambda_Aurigae> when you say it restarts if you touch the chip, tells me we have a grounding/noise issue.
[12:04:17] <Gaboose> i didn't say it restarted
[12:04:26] <Gaboose> it blocks and then continues
[12:04:31] <Lambda_Aurigae> ok...starts.
[12:04:33] <Lambda_Aurigae> whatever...
[12:04:40] <Lambda_Aurigae> still sounds like grounding/noise issue.
[12:04:54] <Gaboose> right, well, i'm using all pins though
[12:05:17] <Joggl> blocking and continues? does not sound like noise for me
[12:05:19] <Gaboose> 5 for the wireless module, one for serial debug output
[12:07:13] <Lambda_Aurigae> well, I'm out of ideas.
[12:08:32] <Gaboose> maybe some general noise protection tips?
[12:12:24] <Jartza> Gaboose: do you have pull-up resistor on reset-pin?
[12:12:38] <Gaboose> i'm using the reset pin as an output
[12:12:50] <Gaboose> and no, i dont
[12:20:19] <Gaboose> do I need one?
[12:21:23] <Tom_itx> yes you need one
[12:23:34] <Jartza> Gaboose: do you have high voltage programmer?
[12:23:46] <Jartza> and have you burned the fuse "disable reset"?
[12:23:58] <Jartza> if not, then you pretty much shouldn't be using reset pin
[12:24:02] <Tom_itx> if he's using reset as an IO he has
[12:24:23] <Jartza> if you burn the fuse "disable reset", then you can't program the chip with "normal spi"
[12:24:30] <Jartza> you need high voltage serial programmer
[12:24:41] <Jartza> or at least high voltage fuse resetter
[12:25:11] <Jartza> Tom_itx: I'm more or less sure that he thinks he's using it as an IO, but that's causing the cpu to reset all the time :)
[12:25:24] <Tom_itx> yeah
[12:25:54] <Tom_itx> there's one of the U chips that brings the reset out to PORTC? i believe
[12:25:57] <LeoNerd> Ooh.. if you write to the reset pin while it's still a reset pin, does it actually reset the CPU then?
[12:26:03] <Tom_itx> every time you would toggle the pin it would reset
[12:26:15] <Tom_itx> it darn sure does
[12:26:19] <Gaboose> woah
[12:26:19] <LeoNerd> Ah.. useful :)
[12:26:49] <Jartza> yes :)
[12:26:50] <Tom_itx> so unless you have a way to undo the reset pin, don't change it to GPIO
[12:26:56] <LeoNerd> It sometimes concerned me that AVR doesn't have an actual 'RESET' instruction, but I suppose that SBIC PORTB, PB2 effectively is that then :)
[12:27:05] <Jartza> I use that pin to reset Tagsu :)
[12:27:15] <Jartza> it's normally pulled up with 10k
[12:27:23] <Jartza> I just set the pin down and the MCU resets
[12:27:26] <LeoNerd> Nice
[12:27:28] <Jartza> useful
[12:27:54] <Jartza> and you can read the boot reason also from register
[12:28:07] <Jartza> to tell apart watchdog reset from power up and reset
[12:28:08] <LeoNerd> Ooh? Which register?
[12:28:20] <LeoNerd> I don't recall one of those on a 'tiny
[12:29:27] <Jartza> LeoNerd: MCUSR
[12:30:06] <Jartza> there's 4 bits telling the boot reason
[12:30:20] <Jartza> either brown-out, watchdog, external reset or power on
[12:30:27] <Jartza> external reset being the reset pin :)
[12:30:29] <LeoNerd> Hmmmm
[12:30:35] <LeoNerd> "external" reset <.<
[12:30:42] <Jartza> datasheet page 44
[12:31:12] <Gaboose> hm, strange.. im using the reset pin as output, but the chip doesn't actually reset
[12:31:15] <Gaboose> i can tell from the print statements
[12:37:28] <Jartza> Gaboose: you can't use reset-pin as normal IO unless you set the RSTDISBL fuse
[12:37:41] <Jartza> and when you do that, you can't no longer program it with ISP programmer
[12:37:43] <Jartza> so beware
[12:38:13] <Jartza> Gaboose: what programmer you use?
[12:39:02] <LeoNerd> You can still use SPM and therefore the Arduino bootloader, so long as you powercycle it to reset
[12:39:10] <Gaboose> Jartza: linuxspi
[12:41:47] <Jartza> Gaboose: what device? :)
[12:42:06] <Gaboose> rpi's spi port
[12:42:07] <Gaboose> :)
[12:42:13] <Gaboose> raspberry pi's
[12:43:10] <Gaboose> it has reset control through GPIO too
[12:50:29] <Jartza> so you don't have high voltage serial programmer
[12:50:54] <Jartza> meaning, you shouldn't set the RSTDISBL fuse, because then you can't program the chip anymore
[12:51:03] <LeoNerd> Only the smaller ATtiny chips use HVSP anyway... most chips (including the megas) use HVPP
[12:51:04] <Jartza> which means, you shouldn't use reset pin as io
[12:54:07] <Gaboose> yea, got it, i'll disable the printlns i guess
[12:54:41] <Gaboose> though im rather certain that my chip didnt restart
[12:54:54] <Gaboose> maybe the reset output are badly configured as well
[12:55:53] <LeoNerd> You keep saying "reset output"
[12:55:57] <LeoNerd> The RESET pin is an input
[12:58:46] <Fleck> ;p
[12:59:21] <Jartza> yes. it's for resetting the chip.
[13:15:13] <Lambda_Aurigae> LeoNerd, if reset is disabled then the pin can be input or output...if you don't disable it and use it as output it is the same as resetting the chip..or so I'm seeing.
[13:16:40] <LeoNerd> That sounds plausible
[13:16:43] <LeoNerd> Afternoon RikusW
[13:17:01] <LeoNerd> We're just discussing outputting to the RESET pin when it isn't disabled, and whether that does a hardware reset
[13:17:24] <RikusW> Good evening LeoNerd
[13:17:44] <RikusW> (almost 21:00 here)
[13:17:48] <LeoNerd> Heh.. when did it become so late?
[13:17:54] <LeoNerd> Ohyeah, I had breakfast at 4pm
[13:18:32] <RikusW> thats what I say 02:00 this morning :-P
[13:18:37] <RikusW> *said
[13:19:00] <Lambda_Aurigae> LeoNerd, I've done similar with regular gpio pins...set them as output, write to them, then read their state as if they were inputs....
[13:19:31] <RikusW> It might actually reset the chip
[13:19:36] <LeoNerd> Hrm
[13:19:39] <Lambda_Aurigae> LeoNerd, we made homemade belgian waffles at 4:30 this morning.
[13:19:50] <Lambda_Aurigae> RikusW, I suspect it will if you do such with the reset pin on an attiny.
[13:19:55] <LeoNerd> Oh, but it's usually safe to just blat PORTB = 0 because the relevant pin defaults to an input?
[13:20:07] <LeoNerd> I could easily test it here actually
[13:20:28] <Lambda_Aurigae> I'm making bacon and tomato sandwiches with homemade bread and homemade bacon here...unfortunately I don't have a hothouse so no home grown tomatoes in the middle of winter.
[13:20:33] <LeoNerd> I usually keep a 'tiny84 and an 85 in HV mode, with a little sticker on them to remind me which one :)
[13:20:50] <LeoNerd> Lambda_Aurigae: Dogfooding like a King :)
[13:20:51] <RikusW> I do know messing with C1 on mega32u2 is bad news, its on one of the XT pins, and does actually stop the clock...
[13:21:08] <LeoNerd> Oops
[13:21:09] <Lambda_Aurigae> oops.
[13:21:09] <Lambda_Aurigae> hehe
[13:21:12] <LeoNerd> SNAP!
[13:21:46] <RikusW> * C0 / XT2
[13:22:17] <RikusW> it took me quite a while to figure out what was happening
[13:22:28] <RikusW> basically dW will break too
[13:22:33] <Lambda_Aurigae> I bet.
[13:22:34] <LeoNerd> I had a similar thing on USI on the tiny84
[13:22:48] <Lambda_Aurigae> I love playing god with clocks on microcontrollers.
[13:22:55] <LeoNerd> The data sheet tells you to ensure that the SS line is set as an OUTPUT when you use the USI, or else you'll confuse the SPI slave hardware into doing Weird Things
[13:22:56] <LeoNerd> That's fine
[13:23:02] <Lambda_Aurigae> AVR will pretty much run from DC to 120% max clock.
[13:23:04] <RikusW> if it was not for the boot switch the chip would have been bricked
[13:23:14] <RikusW> (or I'd have to do HVPP)
[13:23:15] <LeoNerd> What it doesn't say is that you have to make it an output in the DDR _before_ you even enable the USI
[13:23:35] <LeoNerd> What I was doing was enabling the USI on startup, but only fiddling DDR just before I wanted to talk SPI. That doesn't work
[13:23:44] <Lambda_Aurigae> have run them using a debounced pushbutton as the clock source..alternating with a 555 timer and variable resistor to control the clock speed through that.
[13:24:13] <LeoNerd> RikusW: This is why the first bit of toolchain I made myself was the HVSP :)
[13:24:42] <RikusW> good idea
[13:24:51] <LeoNerd> Still not sold any yet, mind..;.
[13:25:38] <RikusW> my U2S use the SS pin to reset the target avr, when auto disabling dW I set it as input.....
[13:26:06] <RikusW> took me a while to figure out why SPI/ISP is no longer working.
[13:26:24] <RikusW> (after adding dW disable code)
[13:28:04] <Lambda_Aurigae> http://hackaday.com/2015/01/03/peculiar-radial-mill-from-car-parts/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[13:41:54] <Jartza> wow
[13:41:59] <Jartza> I tested this reset thing
[13:42:08] <Jartza> other attiny resets
[13:42:17] <Jartza> the other just keeps the reset high all the time, even when setup as output
[13:42:35] <Jartza> either way, Gaboose will have problem
[13:42:42] <Jartza> and I suggest to use some other pin than reset
[13:43:01] <Jartza> I still need to check the fuses
[13:45:16] <RikusW> seems you discovered a hw bug ;)
[13:45:59] <Jartza> this is really strange
[13:46:11] <Jartza> why do they act differently
[13:46:32] <RikusW> bug in Atmel's hdl files ?
[13:47:04] <Jartza> dunno
[13:47:11] <Jartza> these are different batches though
[13:47:22] <RikusW> it seems that AVR is created with hdl much like fpga configs
[13:47:24] <Jartza> btu which behaviour is the correct? :)
[13:47:46] <RikusW> same tiny ?
[13:48:34] <RikusW> output pins might not be exactly identical
[13:48:48] <Jartza> same tiny yes
[13:48:57] <RikusW> thats weird
[13:48:58] <Jartza> both are dip attiny85s
[13:49:11] <Jartza> hmm
[13:49:20] <Jartza> third chip also keeps the reset high all the time
[13:49:27] <RikusW> static charge on the pin ?
[13:49:57] <LeoNerd> Check the fuses
[13:50:01] <Jartza> nope
[13:50:07] <RikusW> or add a pullup ?
[13:50:08] <Jartza> I have to check the fuses yes
[13:50:13] <Lambda_Aurigae> it's not a bug..it's a feature!
[13:50:16] <Jartza> I tried with and without pullup
[13:50:52] <Jartza> hmm, this one chip had really strange fuses too
[13:51:02] <Jartza> maybe it's the broken one I was going to throw away
[13:51:09] <Jartza> should've marked it somehow :)
[13:51:23] <Jartza> all the others work the same way
[13:51:37] <Jartza> when RSTDSBL fuse is not set, you can't really use reset pin as output it seems
[13:51:48] <Jartza> driving it low or high doesn't make any difference, it stays high
[13:51:58] <Jartza> with pullup-resistor it stays "higher" :D
[13:52:38] <Jartza> but if Gaboose is trying to use it as an output-pin, maybe that's the problem, the pin stays high all the time
[13:53:43] * RikusW goes to smoke a pullup resistor :-D
[13:55:03] <Jartza> now I need to check my own firmware
[13:55:12] <Jartza> how did I reset the chip again :D
[13:56:04] <RikusW> I've had atmega8 chips behave differently with the same fw once
[13:56:22] <RikusW> turns out I forgot to initialize a variable...
[13:56:24] <Jartza> oh
[13:56:32] <Lambda_Aurigae> that happens a lot.
[13:56:40] <Jartza> I remembered wrong. I use watchdog to reset.
[13:56:40] <RikusW> and some ram tended to be 0 by default on some chips
[13:56:54] <WormFood> what is the largest possible valid value, for UBRRH? Is that a maximum of 4 bits? (I don't want to pull out some random datasheet to check)
[13:57:09] <Lambda_Aurigae> look at the datasheet for your specific chip WormFood
[13:57:20] <WormFood> I don't have a specific chip
[13:57:25] <WormFood> that is why I asked
[13:57:28] <RikusW> WormFood: it will probably differ with AVR
[13:57:34] <Lambda_Aurigae> might be different on different chips.
[13:57:45] <WormFood> of course it will differ, which is why I asked for the maximum possible valid value
[13:57:58] <WormFood> out of all the AVRs
[13:58:10] <Lambda_Aurigae> one would have to compare all datasheets and see which has the most bits.
[13:58:10] <LeoNerd> Probably just minor silicon differences in different revisions...
[13:58:14] <LeoNerd> boundary cases, etc
[13:58:17] <WormFood> I'm just tweaking my bit rate calculator
[13:58:48] <Lambda_Aurigae> on the atmega1284p it is 4 bits.
[13:59:05] <WormFood> that is what I was suspecting, that it is 4 bits
[13:59:10] <Lambda_Aurigae> but the datasheet says it could be more in future devices so the extra 4 bits are reserved.
[13:59:12] <WormFood> but I didn't know if something else, might be bigger
[13:59:26] <LeoNerd> Presumably it has to allow for faster clock rates in the future, to still talk slow baud rates
[14:00:17] <WormFood> right
[14:00:57] <WormFood> well, right now, my bit rate calculator shows anything over 12 bits, as being "out of range", unless you check the box to limit it to 8 bits. I just wanted to see if I should update my program.
[14:01:13] <RikusW> seems like its safe to assume 4
[14:01:13] <LeoNerd> Use the device info files to check :)
[14:01:20] <LeoNerd> N1njVacation: Speaking of.. ohwait you're on "vacatoin"
[14:01:21] <LeoNerd> boo
[14:01:24] <RikusW> I just grepped my parts file db
[14:01:30] <WormFood> good idea LeoNerd
[14:01:46] <WormFood> I have those files somewhere, but I haven't updated them in over a year
[14:02:04] <LeoNerd> I'm still waiting for reply from Atmel on whether they'll offer them as a separate download
[14:02:17] <LeoNerd> https://metacpan.org/pod/Device::AVR::Info <== I wrote this to use them
[14:05:06] <WormFood> it appears, that maybe the RFR2 devices, may have a 16 bit UBRR
[14:10:23] <WormFood> no, those are only 12 bits, but the device info file (that I have) suggests UBRRH is 8 bits.
[14:13:39] <Jartza> Gaboose: I think you can tie the CE high on nrf24l01 if you want to save a pin
[14:14:35] <Jartza> Gaboose: and you can use red led to drop 5V to 3.3V-ish :)
[14:15:23] <Jartza> nrf24 is satisfied with 1.9-3.6v so red led should be enough
[14:15:33] <Jartza> they have forward voltage drop of 1.8-2.2 volts usually
[14:15:58] <LeoNerd> CE high will increase power usage, and -might- or mightnot work. I can't remember if it's level or edge-triggered
[14:43:15] <RikusW> resistor might be better than a led
[17:10:39] <hypermagic> hello my friends
[17:13:08] <Joggl> o0
[18:52:52] <NicoHood> anyone knows how to initialize a union to zero by default? https://gist.github.com/NicoHood/3cbe1e3c2be256a54eaa
[19:01:42] <hypermagic> NicoHood, you don't
[19:01:59] <hypermagic> union is not a variable, it is a type
[19:02:12] <hypermagic> you initialize your variable
[19:04:14] <NicoHood> hypermagic: cant i create a constructor like i wrote? it just throws errors when i try to compile
[19:05:01] <hypermagic> you may use an initializer and define 0 to each one of your structure's elements, or write a zeroing function.
[19:05:13] <LeoNerd> Or just = { 0 }
[19:05:32] <hypermagic> will that zero all elements?
[19:05:34] <NicoHood> LeoNerd: that works. just asking if i can always set everything to zero
[19:05:52] <NicoHood> withput that
[19:06:00] <NicoHood> for dumb users, you know ;)
[19:06:15] <hypermagic> i'd make a zero function :P
[19:06:25] <LeoNerd> Then no. In C, types can't provide default initialisation for variables of that type.
[19:06:35] <NicoHood> hypermagic: how?
[19:07:23] <hypermagic> a simple one
[19:07:39] <NicoHood> outside the struct?
[19:07:48] <hypermagic> it may also be possible to just zero like 16 bytes at the address of your structure for example
[19:08:38] <hypermagic> but these kind of optimizations are dangerous to reliability
[19:08:46] <LeoNerd> It's fine enough on AVR but don't forget that "all fields are numerically zero" doesn't necessarily mean "all the underlying bytes of storage are zero"
[19:08:54] <LeoNerd> on other platforms
[19:09:52] <NicoHood> why cant i use this? http://stackoverflow.com/questions/1069621/are-members-of-a-c-struct-initialized-to-0-by-default
[19:10:05] <NicoHood> 1st answer
[19:10:08] <hypermagic> bla
[19:10:29] <LeoNerd> That works
[19:10:59] <LeoNerd> = {} but I usually prefer the notation = { 0 } as it's a little more explicit that "I mean to conceptually zero this out here"
[19:11:00] <hypermagic> you cant ?
[19:11:03] <LeoNerd> Rather than it being empty
[19:11:09] <hypermagic> use 0.0 for double anyway
[19:11:19] <LeoNerd> Doesn't matter. compiler will handle it
[19:11:38] <LeoNerd> struct foo var = { 0 }; <== compiler knows the types of every field and will initialise each field to the /conceptual/ "zero" value of each field
[19:11:41] <NicoHood> and why does this work and mine not?
[19:11:41] <NicoHood> struct Snapshot {
[19:11:41] <NicoHood> int x;
[19:11:41] <NicoHood> double y;
[19:11:41] <NicoHood> Snapshot():x(0),y(0) { }
[19:11:42] <NicoHood> // other ctors / functions...
[19:11:42] <NicoHood> };
[19:11:58] <LeoNerd> Oh this is a C++ question
[19:12:02] <LeoNerd> *shrug* no idea then. all bets off
[19:12:10] <hypermagic> it is because you use c++
[19:12:15] <NicoHood> LeoNerd: i want to use c only.
[19:12:20] <hypermagic> use C :P
[19:12:21] <LeoNerd> Then use C only and avoid C++isms
[19:12:27] <NicoHood> hm okay i get it :(
[19:26:37] <hetii> Hi :)
[19:27:43] <hetii> Q: I port some STK500v2 programmer to LPC1769, test it with atmega8 and ttiny13 in both can read//write data but have some atmega328 where got timout when try write data
[19:27:58] <hetii> signature is readed fine
[19:29:24] <hetii> I wonder what`s can be different
[19:50:39] <Casper> hetii: try to slow it down
[19:50:50] <Casper> it might be a clock issue
[19:51:56] <hetii> the point is that I test all possible scenario with it.
[19:52:19] <hetii> Test with attiny13 that works slower then this atmega328p
[19:52:25] <hetii> and works with it
[19:52:44] <hackvana> hetii: Do you have a bypass cap next to the chip between Vcc and GND?
[19:53:08] <hackvana> What else is connected to the programming lines, anything except the programmer?
[19:53:48] <hetii> hmm, its in some arduino mini board so have cpas on it. Nothing else, just programmer and this mcu
[19:54:20] <LeoNerd> Also ICSP still runs using the onboard CPU clock
[19:54:24] <LeoNerd> It might depend on clock fuses
[19:55:08] <hetii> the strange issue is in that I test this mcu some time ago with some other port of stk500 and works, difference now is in that I use other computer as a host.
[19:55:34] <hetii> yep I need check this fuses, step by step
[20:03:25] <Casper> hetii: also, check the default clock, I know some chip have an insanelly slow clock by default
[20:03:29] <Casper> like 128kHz
[20:03:47] <LeoNerd> That's why some of the ICSP boards give you a "slow clock" option
[20:04:33] <hetii> yep I know that.
[20:04:52] <hetii> I suppose some bits are wrong set and thats the reason why it acts odd.
[20:05:12] <DO9XE_> is here someone, who can help me with a LUFA PRoblem? I have a xMega and it allways reports the length 0 for all packages to the host, but the code schould normally calculate the right length :P I dont know what could be wrong :/