Back
[00:48:58] <vsync_> question, mega1284, porta can be used simultaneously as part adc part i/o?
[00:49:25] <vsync_> that's what the datasheet suggests but then again figures this is not true for all avrs
[01:02:51] <Thrashbarg> if you turn the ADC on and off it should I expect
[01:03:06] <Thrashbarg> but not simultaneously, you'd need to multiplex it
[01:03:58] <Thrashbarg> I *think* the pin for the input gets disconnected from the register...
[01:23:51] <vsync_> this could potentially get hairy then
[01:28:14] <Thrashbarg> yup
[04:53:33] <LeoNerd> How annoying. All last night I couldn't get any code to talk to my WS2812 smart LED, all I could get was a dim blink of red. Overnight I wondered if maybe it needed a decoupler cap.
[04:54:10] <x29a> now it works?
[04:54:21] <LeoNerd> This morninf I put one in, to find I missed the hole on the +ve supply and it was in the next row of the breadboard. Move that and now it's perfect
[04:54:40] <x29a> d'oh
[04:54:43] <LeoNerd> Doesn't even need the cap. It just doss need -both- power supply pins ;)
[04:55:00] <x29a> naturally
[04:55:05] <LeoNerd> Visual parallax error in pushing the wire in I think
[04:55:36] <LeoNerd> It's a tall breakout board and I look at an angle where it sits on the desk
[04:55:53] <LeoNerd> Ahwell, solved now anyway
[05:00:09] <LeoNerd> Well now that works. next step is to make my $N-was continuity/board tester with it
[05:00:19] <LeoNerd> It needs a better name
[06:51:44] <robin_sz> so .. pointers to structs are confusing me again
http://pastebin.com/qECDbnbi
[07:50:25] <neionz> robin_sz: is that c or c++?
[07:55:04] <malinus> who in their right mind would make that code for cc++?
[08:01:10] <aep> so i have tom's tiny avr2 isp (probably applies to all lufa isps) connected as PDI interface via a 10 pin mini-jtag to an ATxmega256A3U.
[08:02:11] <aep> and the atmel studio thing says "can't connect to target blabla, invalid usb descriptor 130" or something. I'm not even sure if lufa thingies work with atmel studio at all
[08:03:15] <robin_sz> neionz, C
[08:13:27] <malinus> aep: works just fine with ISP fiy.
[08:13:50] <aep> right so maybe its the fact that i run a virtual windows :/
[08:14:15] <aep> going to infect a real windows with their stuff now
[08:33:58] <aep> nah same. 'read from usb endpoint 130 failed: invalid pipe number' :/
[08:34:50] <neionz> robin_sz: ".menuDepht". What does the dot vefore it do? What type is it?
[08:35:08] <neionz> robin_sz: is it real C or that audrino kind of weirdness?
[08:52:53] <aep> hm doesnt work with avrdude either
[08:52:57] <aep> avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2103)
[08:53:00] <aep> Bus 002 Device 005: ID 03eb:2104 Atmel Corp. AVR ISP mkII
[08:53:04] <aep> one of oO
[09:02:17] <robin_sz> neionz, thats standard C99 dude
[09:02:48] <robin_sz> .menuDepth is access to the structure member
[09:21:34] <neionz> robin_sz: yaeh, but why do you .menuDepth = 1; in the struct definition?
[09:22:48] <aep> does anyone happen to know how to map jtag to PDI in the atmel world? this thing shows pinout definitions for jtag, but the mcu is an ATXMEGA256A3U :
http://www.atmel.com/images/atmel-42268-wireless-zigbit-atzb-x0-256-4-0-cn_datasheet.pdf
[09:25:33] <robin_sz> neionz, umm, its not in the definition, its in the decalaration
[09:26:21] <robin_sz> and thats how you assing values in things decalared static const
[09:26:31] <robin_sz> how else could you possibly do it?
[09:27:11] <robin_sz> you cant do:
[09:27:46] <robin_sz> static const foo_t foo;
[09:27:56] <robin_sz> foo.bar = 1;
[09:27:59] <robin_sz> now can you?
[09:28:11] <robin_sz> you have to do :
[09:28:42] <robin_sz> static const foo_t foo = { .bar =1, .baz=2};
[09:28:56] <robin_sz> or, if you are happy to assign in order:
[09:29:12] <robin_sz> static const foo_t foo = {1,2};
[09:29:22] <robin_sz> but I prefer the .bar=1 style
[09:29:25] <robin_sz> easier to read
[09:32:59] <aep> ok so i found the traces for PD1/XCK0 and PDI_DATA and wired them directly to clk/data of my other avr isp's pdi thing. still avr studio says cannot connect to tool :/
[09:33:13] <aep> is there anything else i need to care about?
[09:36:06] <robin_sz> did you remember to enable jtag in the fuses?
[09:36:38] <aep> i'm not even sure what that menas
[09:36:42] <aep> *means
[09:36:57] <robin_sz> the pins are multi-purpose
[09:37:02] <aep> how would i be able to set fuses if my programmer doesnt work?
[09:37:45] <robin_sz> maybe the chip already has JTAG enabled
[09:37:53] <twnqx> ,,, jtag pins are 30-31
[09:38:01] <twnqx> PDI is not related to jtag whatsoever
[09:38:06] <twnqx> 30-33*
[09:38:15] <twnqx> tck,tms,tdo,tdi is jtag
[09:38:22] * robin_sz nods
[09:38:40] <robin_sz> I think they ship as new with jtag enabled
[09:38:59] <aep> uh the ATxMega256A3U has jtag?
[09:39:18] <twnqx> the pdf you linked has the ports listed
[09:39:22] <twnqx> as jtag
[09:39:23] <twnqx> on page 10
[09:39:30] <aep> yes, which is super weird
[09:39:35] <twnqx> i have no clue what else you are talking about :/
[09:40:20] <aep> this is all very confusing
[09:40:33] <aep> its a module with an ATxMega256A3U, the module spec lists jtag
[09:40:36] <aep> but the mcu doesnt have jtag
[09:40:49] <aep> and the designated PDI pins do not work
[09:41:03] <twnqx> http://www.atmel.com/Images/Atmel-8386-8-and-16-bit-AVR-Microcontroller-ATxmega64A3U-128A3U-192A3U-256A3U_datasheet.pdf page 60
[09:41:08] <twnqx> yes it has jtag, for sure
[09:41:28] <aep> hm ok, atmel studio won't let me select the chip with jtag :/
[09:42:07] <Tom_itx> then it doesn't have jtag
[09:42:41] <aep> not sure how to get pdi working then.
[09:42:57] <aep> Tom_itx: btw, how do i get your isp working with atmel studio?
[09:43:15] <twnqx> on page 61
[09:43:23] <twnqx> pins pb4 to pb7
[09:43:29] <twnqx> jtag is an alternate function
[09:43:34] <Tom_itx> you just plug it in unless you have modified something
[09:43:48] <twnqx> which may or may not have to explicitely enabled using fuse bits prior to use
[09:43:56] <twnqx> i won't read the datasheet for you to that extent
[09:44:09] <aep> Tom_itx: i might hvae broken it, dunno, is there an original firmware binary somewhere?
[09:44:34] <aep> twnqx: won't matter, since atmel studio won't allow me to use it. PDI is all it allows, so i guess i need to get that working
[09:44:41] <twnqx> lol atmel studio
[09:44:49] <twnqx> ah well, use whatever suits you :)
[09:45:44] <aep> i only need it once to load the fricking zigbee firmware :/
[09:46:09] <aep> it's not like they just send you a hex file :P
[09:47:13] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[09:47:17] <Tom_itx> * 131027 Windows Studio version(.hex)
[09:47:22] <Tom_itx> is the one you want
[09:47:38] <aep> thanks
[09:48:18] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_User_manual_index.php
[09:48:25] <Tom_itx> directions are there
[09:49:11] <aep> actually i'll try with avrdude first
[09:49:52] <Tom_itx> avrisp2 is the programmer you select for that
[09:50:35] <aep> NOTE: *** IN PDI MODE, ONLY USE TARGET POWER ***
[09:50:39] <aep> this sounds relevant
[09:50:48] <aep> i powered the target from the isp :/
[09:51:20] <aep> maybe that's the reason it won't work
[09:52:01] <Tom_itx> is it an xmega?
[09:52:30] <aep> yeah
[09:52:33] <Tom_itx> xmegas are 3.3v only sir
[09:52:55] <aep> odly enough it didnt power on at 3.3
[09:53:00] <Tom_itx> i have done it too and gotten away with it for a bit but it may have ruined it
[09:53:10] <aep> oh
[09:53:54] <Tom_itx> the switch removes the usb power from the target chip and only powers the programmer, leaving you to power the xmega from it's own source
[09:54:15] <Tom_itx> the 2nd chip on it is a voltage translator
[10:05:56] <aep> hm ok so i powered it externally. same issue :/
[10:06:02] <aep> with avrdude this time
[10:06:06] <aep> avrdude: stk500v2_recv_mk2: error in USB receive
[10:07:00] <aep> (this is with a different programmer, i couldnt get toms one react to dfu_programmer)
[10:07:31] <aep> if i turn around data/clock i get:
[10:07:34] <aep> avrdude: usb_open(): cannot read serial number "Connection timed out"
[10:11:21] <Tom_itx> are you using avrdude on windows?
[10:11:37] <Tom_itx> if you are you need that 2nd firmware from my site loaded along with libusb
[10:11:38] <aep> nah linux
[10:11:57] <aep> its a different programmer. i cant get program yours
[10:12:22] <Tom_itx> sounds like you may have screwed something up
[10:12:31] <aep> probably :D
[10:12:57] <aep> dfu-programmer just says "Error while flashing." most amazing error message ever
[10:13:34] <aep> i'll try the windows thing later
[10:34:51] <Tom_itx> if you can't flash the programmer avrdude isn't gonna help much
[11:09:03] <aep> aw
[11:09:09] <aep> i had to erase before flash, that was all
[11:09:29] <Tom_itx> on the programmer or the part?
[11:09:33] <aep> the programmer
[11:09:39] <aep> didnt get the target to do anything yet
[11:09:40] <Tom_itx> ok good
[11:09:55] <Tom_itx> now flip the programmer switch so it's toward the target
[11:10:07] <aep> yeah re-wiring with external power now
[11:10:36] <Tom_itx> if that doesn't work then you probably know what happened
[11:13:33] <aep> i got a new target
[11:13:41] <aep> different things are happening indeed
[11:13:44] <aep> avrdude: stk500_recv(): programmer is not responding
[11:15:02] <Tom_itx> using avrdude?
[11:15:06] <aep> yeah
[11:15:20] <Tom_itx> if you have studio installed, use it
[11:15:24] <aep> sure
[11:15:27] <Tom_itx> it will be much simpler
[11:15:35] <Tom_itx> install that first firmware i linked you
[11:15:43] <Tom_itx> it will work with studio
[11:15:46] <aep> i was just switchin in hopes someone here knows what the errors mean
[11:15:50] <aep> yup
[11:15:52] <Tom_itx> but not with avrdude on WINDOWS
[11:16:39] <Tom_itx> the error probably means you have the wrong firmware for avrdude on windows
[11:16:53] <Tom_itx> it's a USB driver issue
[11:17:01] <aep> nah i'm on linux with avrdude
[11:17:03] <Tom_itx> don't mix em up
[11:17:06] <aep> using the avrdude firmware
[11:17:20] <Tom_itx> either one should work on linux
[11:17:22] <aep> i'll try the atmel studio firmware with atmel studio on windows now :D
[11:17:23] <Tom_itx> even the windows one
[11:17:32] <Tom_itx> i'd put it back on and leave it
[11:17:45] <aep> which one?
[11:17:48] <Tom_itx> the studio firmware will work on linux
[11:17:50] <aep> ah
[11:17:53] <aep> ok cool
[11:18:00] <Tom_itx> just not with avrdude on windows
[11:18:08] <Tom_itx> it's a USB driver issue
[11:18:09] <Tom_itx> it's a USB driver issue
[11:18:10] <Tom_itx> it's a USB driver issue
[11:19:21] <aep> atmel studio just shows 'diconnected' as soon as i hit apply, then a popup 'unable to connect to tool'
[11:19:51] <aep> which according to google could also mean that it's unable to connect to the target
[11:20:15] <Tom_itx> unplug the target and try it
[11:20:27] <aep> same error
[11:22:11] <aep> avrdude also says: avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
[11:25:01] <Tom_itx> i don't think you have the right firmware installed _or_ it's not registering under the JUNGO driver
[11:25:11] <Tom_itx> look in hardware and see if it's there
[11:25:45] <aep> 131027 Windows Studio version(.hex)
[11:26:10] <Tom_itx> if you've been messing with it, you may have the usb driver screwed up
[11:26:14] <Tom_itx> it's easy to do in windows
[11:26:27] <Tom_itx> i found the only fix for it for me was to reinstall studio
[11:26:27] <aep> there's a "Jungo Connectivity" -> "WinDriver"
[11:26:36] <Tom_itx> and let it reinstall it
[11:26:57] <aep> hrm
[11:27:08] <Tom_itx> that's why it's just better to use studio in windows instead of avrdude
[11:27:17] <aep> i never used avrdude on windows
[11:27:38] <Tom_itx> it's some sort of a USB driver issue
[11:27:44] <aep> mh ok
[11:27:44] <Tom_itx> i'm almost certain of it
[11:27:52] <Tom_itx> _almost_ !
[11:27:55] <aep> odd that it happens on linux as well
[11:28:03] <aep> i was thinking i just mis-wired the target
[11:28:11] <Tom_itx> hmm
[11:28:23] <Tom_itx> you could have borked the programmer some how...
[11:28:28] <Tom_itx> i'm not quite sure
[11:28:40] <Tom_itx> it lets you load the firmware though
[11:28:59] <aep> is there some debug thing i can do with avrdude?
[11:29:12] <Tom_itx> -vvvv
[11:30:14] <aep> hm yeah not more output either. i'm just wondering how to distinguish between target issues and programmer
[11:30:26] <LeoNerd> So I think I finally found something I can use a tiny13 for; something that needs few IO pins, no serial/USI/...
[11:30:53] <LeoNerd> (mostly because I happen to have one spare thinking "What am I going to use this for?")
[14:28:55] <LeoNerd> I'm trying to keep a selection of useful .c files that apply to a variety of chips, so I can just symlink/compile them in and all is ince
[14:28:56] <LeoNerd> nice
[14:29:17] <LeoNerd> Is there a #define symbol or somesuch that I can detect the chip type with, to account for differences from place to place?
[14:29:58] <vsync_> Has anyone done any reflector stuff with LEDs?
[14:30:20] <LeoNerd> reflector?
[14:32:10] <vsync_> spreading the light
[14:32:48] <LeoNerd> Oh.. not so much reflector, but I did some things with a diffuser over the top
[14:33:06] <vsync_> pardon my english
[14:33:09] <vsync_> diffuser. yeah.
[14:33:17] <LeoNerd> Of all things, I eventually settled on a toddler sippee cup that was made of just the right kind of transluscent white plastic..
[14:33:56] <LeoNerd> A reflector is more for omnidirectional light sources, like incandescent bulbs, to point them out the right way. LEDs are usually quite a narrow beam anyway
[14:34:06] <vsync_> yeah, that's exactly what i mean
[14:34:26] <vsync_> i messed up diffuser and reflector, even though they are self-explanatory
[14:34:30] <vsync_> heh.
[14:34:38] <vsync_> so, anyway
[14:34:47] <vsync_> i take it, this was for a screen?
[14:34:57] <LeoNerd> No, a theatrical prop :)
[14:35:02] <LeoNerd> Hold up I may have a photo
[14:35:09] <vsync_> that'd be appreciated
[14:37:19] <LeoNerd> Ah, seems not
[14:38:27] <vsync_> you know a thing or two of optics anyhow?
[14:38:36] <LeoNerd> Not really my area, no
[14:38:51] <vsync_> :|
[14:40:52] <vsync_> anyway to throw it out there, trying to replicate something like the side-lit kindle
[14:41:16] <malinus> LeoNerd: yes. as you know, you normally set the mmu flag with avr-gcc
[14:41:21] <vsync_> it has a clear diffuser on top and leds mounted to the side
[14:41:22] <malinus> LeoNerd: you can just use that
[14:42:34] * LeoNerd ponders
[14:42:56] <malinus> ?
[14:43:35] <LeoNerd> -mmcu isn't visible at the C layer, is it?
[14:44:23] <malinus> LeoNerd: yes, just look in the avr-gcc source files
[14:44:27] <LeoNerd> Hmmm
[14:44:33] <malinus> LeoNerd: how else would avr/io.h etc. work?
[14:44:57] <LeoNerd> Ooh... heh.. Yes :)
[14:45:00] <LeoNerd> Clearly. OK I can just do that
[14:45:27] <malinus> just look in the source
[14:45:36] <LeoNerd> Yah
[15:09:28] <LeoNerd> How come most of the AVR chips are shipped with the CKDIV8 fuse set..?
[15:21:09] <aandrew> probably to allow you to recover from too fast a clock? not really sure
[17:54:52] <LeoNerd> Hrm. ADC reads are giving me just zeroes.. What could I have forgotten? I have: set the ref (VCC), set the ADEN bit, set the prescaler, selected the channel with ADMUX, set the ADSC bit, wait for it to become clear, then read the ADCW register
[17:54:56] <LeoNerd> Zero every time
[18:06:35] <vsync_> you sure the connections are okay?
[18:07:50] <LeoNerd> I believe so yeah...
[18:13:47] <LeoNerd> Huh.. very occasionally sometimes it reads 1
[18:26:52] <LeoNerd> HAh! found it. The MUX bits are in ADMUXA, not ADMUXB.
[20:53:32] <postmodern> I'm assembling an AVR ISP programmer, and the instructions give the options of adding 1.5K resistors to the SCK/MOSI pins, but if the chip requires load on those pins they recommend just using jumpers
[20:53:42] <postmodern> do most ATmega chips require load on SCK/MOSI?