Back
[05:11:53] <abcminiuser> Man the Contiki project is super slow at integrating patches
[05:52:21] <AllinYourhead> If i set the external reset disable fuse of an ATmega328p I won't be able to use ISP for programming any more, correct?
[05:58:18] <mux_> abcminiuser, guess what
[05:58:38] <abcminiuser> Damnit it man, never interrupt during a man watching Serenity
[05:58:45] <jacekowski> AllinYourhead: yes
[05:59:16] <abcminiuser> mux_, mmm?
[05:59:21] <mux_> abcminiuser: thousand times sorry, I will wait until you finish this episode, I understand the gravity of the situation
[05:59:38] <AllinYourhead> no way to reset that fuse except alternative programming method?
[05:59:47] <abcminiuser> Nein, I've just started the movie (damn them for naming both the same)
[05:59:52] <abcminiuser> What's up?
[06:00:00] <mux_> oh hm, yeah that will take a while
[06:00:17] <mux_> I'm still stuck on my xmega mass storage bootloader, and going totally insane
[06:00:26] <hackvana> abcminiuser: Should have masked him
[06:00:36] <jacekowski> AllinYourhead: high voltage programming
[06:00:40] <mux_> abcminiuser: do you maybe have the opportunity to look at my atmel studio project?
[06:00:41] <jacekowski> AllinYourhead: or, high dose xray
[06:01:00] <jacekowski> AllinYourhead: for non invasive methods
[06:01:15] <abcminiuser> mux_, which project?
[06:01:32] <AllinYourhead> okey,thanks for confirming. I need to find another solution then :)
[06:01:40] <mux_> abcminiuser: the one I can send you if you say yes :P
[06:01:47] <abcminiuser> Err sure
[06:02:08] <mux_> abcminiuser: it's a commercial project, so I can pay you for your time if you want
[06:03:11] <abcminiuser> If I had any time to sell, it would be forbidden by my current contract :P
[06:03:42] <mux_> do you have a donate button?
[06:04:02] <mux_> because I've been using your stuff for thousands of euros worth of hardware by now
[06:05:10] <abcminiuser> Sure do, on my site
[06:05:22] <abcminiuser> But send it through and I'll see if I can take a squiz
[06:06:51] <mux_> sent
[06:07:40] <abcminiuser> Sciencing...
[06:08:07] <mux_> eh, I'm not sure how to make a separate room in the webclient
[06:08:15] <mux_> I can run you through some of the weird code
[06:08:40] <abcminiuser> "self-powered (lies!)" <- this should be fun
[06:09:18] <mux_> no
[06:09:21] <mux_> ugh
[06:09:39] <mux_> oh I mistyped
[06:10:34] <abcminiuser> So what happens currently, nothing when plugged in?
[06:11:20] <mux_> It gives me a device descriptor failure, and it seems to get a timeout as it takes >1s to get a response
[06:11:42] <mux_> there's a bit of a catch to this board though that I should explain first
[06:11:58] <abcminiuser> Sure
[06:12:06] <mux_> it's connected through an SMSC USB2512Bi USB hub, and the xmega emulates a configuration EEPROM
[06:12:09] <abcminiuser> (Side note, your product string descriptor length is off-by-2)
[06:12:58] <mux_> oh hm, lemme try fixing that (dont think it will fix it though)
[06:13:16] <abcminiuser> No, just having a quick read-through
[06:13:19] <mux_> the USB2512 has an option of swapping USB D+/D- pins, which it has to do for one port
[06:13:29] <mux_> the port that the microcontroller is on
[06:13:30] <abcminiuser> It's late here and I don't want to wake everyone up digging up an XMEGA board to test tonight
[06:13:56] <mux_> don't worry too much about it, I've just been going crazy looking at this project and need a second pair of eyes
[06:14:34] <mux_> so the board initializes, fires up TWI, loads 256 bytes of configuration info (stored as a sparse array as you can see) into the hub, the hub starts and after that the USB stack on the xmega starts doing stuff
[06:14:34] <abcminiuser> Yeah tomorrow I can quickly test and see if I spot anything
[06:14:49] <mux_> I should note that with CDC firmware, this board works just fine
[06:14:55] <abcminiuser> Aha, that explains a lot
[06:15:06] <mux_> my TWI code and all that stuff is not at fault, I've checked with the scope that it indeed sends stuff correctly
[06:15:17] <mux_> (I did have some trouble with it when the code was in the bootloader, but that is fixed now)
[06:15:52] <mux_> after my hub code, everything is just 'stock lufa'
[06:16:15] <mux_> with the difference that I'm not limited to 6kB, so I left the product/manufacturer/languagestrings in the descriptors
[06:17:19] <mux_> don't worry about bootx.h by the way, that's untested as of now (boot.h port to xmega)
[06:17:50] <abcminiuser> At a guess, the pgm_read_byte_far() may be a tad wonky for XMEGA
[06:18:06] <abcminiuser> You can check that easily tho, remove the PROGMEM and define USE_RAM_DESCRIPTORS
[06:18:16] <mux_> let's see
[06:21:37] <mux_> doesn't really change any behaviour
[06:21:53] <mux_> I've got winpcap and wireshark installed
[06:22:07] <mux_> it seems to produce 'malformed packets'
[06:22:45] <abcminiuser> How malformed?
[06:24:43] <mux_> right now it's not producing malformed packets
[06:24:46] <mux_> I sent you a pcap
[06:26:14] <mux_> hm, surprisingly little going on right now
[06:28:44] <mux_> oh my god
[06:28:51] <mux_> halleluja
[06:29:10] <mux_> so, there is definitely wrong with how I'm putting this into the bootloader
[06:29:19] <mux_> and with pgm_read_byte_far
[06:29:33] <mux_> with ram descriptors and in the application space, it works exactly as intended
[06:29:46] <mux_> I now have a lufa boot disk enumerated
[06:33:51] <mux_> abcminiuser: I hate to thinkt his, but I guess this probably has to do with xmega128a4u having >64k address space and pgmspace/other stuff not properly using RAMPZ for that?
[06:36:40] <abcminiuser> (Back, was getting ready for bed)
[06:36:56] <abcminiuser> Yeah, the pgm_read_byte_far probably isn't geared for XMEGA properly
[06:37:21] <abcminiuser> I'd probably just stick with the RAM descriptors unless you're out of RAM for the bootloader
[06:37:33] <abcminiuser> Not worth the investigation, since the bootloader doesn't need much RAM
[06:40:17] <mux_> it still doesn't work properly in bootloader space, so there's something else messing up as well
[09:51:56] <Duality> anyone heard of a synchronous binary ripple counter, with d Flipflops ?
[10:21:02] <Lambda_Aurigae> Duality, yup.
[10:21:48] <Lambda_Aurigae> although they should be async, not sync.
[10:23:46] <Duality> Lambda_Aurigae: i see but why should a binary riple counter be async ? i was just wondering though if i could build a synchronous ripple counter with d-flipflops though :)
[10:24:54] <Lambda_Aurigae> http://www2.elo.utfsm.cl/~lsb/elo211/aplicaciones/katz/chapter7/chapter07.doc5.html
[10:25:00] <Lambda_Aurigae> read that then ask the question again.
[10:25:08] <Lambda_Aurigae> however, I have to go back to work so laters..
[10:44:47] <jadew> any idea why I'd get Error: No device detected. Error 4109. with an atmel ice programmer and an atsam?
[10:45:31] <jadew> the voltages look right but the device is brand new so there's no movement - no way to tell what state its in
[10:45:37] <jadew> I'm trying to connect over swd
[10:48:13] <Jartza> msg[5] = (char)(((int)'0')+ callType);
[10:48:15] <Jartza> gnnnnh :)
[11:32:30] <Jartza> why do I have to read code like that :(
[11:35:36] <jadew> Jartza, where did you find it?
[11:36:22] <jadew> it's not really incorrect, just... too verbose
[11:36:34] <jadew> it could have been written msg[5] = '0' + callType; :)
[11:37:34] <jadew> any idea if the reset signal should go low when programming via swd?
[11:37:39] <jadew> (as part of the handshake)
[11:39:11] <jadew> because it doesn't seem like the programmer tries to do that
[11:39:30] <jadew> if it's only the SWDCLK and SWDIO pins, then it looks like the chip is unresponsive
[11:40:25] <Jartza> jadew: well, this is some legacy lonworks-code I have to rewrite to new mcu
[11:40:48] <Jartza> so, not based on echelon lonworks chip, but also a legacy lon stack
[11:44:45] <Jartza> jadew: and there's a lot of those.
[11:45:27] <jadew> I suppose we shouldn't jump to conclusions tho, we don't know what kind of compiler they used
[11:48:07] <Jartza> I do know :)
[13:41:04] <Duality> hi
[13:42:21] <Duality> i want to add some assembly to my c code, and i am reading this
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
[13:42:35] <Duality> and found this: asm volatile();
[13:42:42] <Duality> why is the volatile there ?
[13:43:02] <CoolBear> So the compiler doesn't try to optimize your code.
[13:43:12] <specing> optimize == ommit it
[13:43:54] <Duality> i see
[13:43:55] <CoolBear> You usually only get to the point of doing hand-crafted ASM when you are really tight for cycles.
[13:44:07] <Duality> i am really tight for cycles
[13:44:11] <CoolBear> It'd be a shame if the compiler just went "We don't need that do we?"
[16:49:32] <mux_> alright, I need a little bit of help with figuring out something related to >128k address space
[16:50:35] <mux_> as a reward to whomever wants to help me, I will give you a link to a youtube video of the best black metal ever produced
[17:05:29] <Tom_itx> your programmer won't program beyond 128k?
[17:05:58] <mux_> oh you're the best person to answer :)
[17:06:40] <mux_> no, my code runs in application space but not in bootloader space on an xmega128a4u (bootloader = 0x20000+)
[17:06:56] <mux_> I am definitely sure that this has something to do with... me being a dumbass
[17:07:16] <mux_> I suspect instructions that have to use RAMPX/Y/Z/EIND/something
[17:07:33] <Tom_itx> can't help you with asm
[17:07:43] <mux_> aww :(
[17:07:49] <mux_> well, in that case
[17:07:51] <Tom_itx> there are those that can here
[17:08:02] <mux_> can I brighten up your day with some awesome 90s black metal
[17:08:43] <mux_> https://www.youtube.com/watch?v=OEt-Pro7Vxg
[17:08:48] <mux_> you can thank me later
[17:08:57] <mux_> I think I'm going to bed now
[17:09:03] <Tom_itx> you assume i like that sort
[17:09:17] <mux_> oh man, I cannot imagine anybody NOT liking that
[17:09:23] <mux_> it's just so beautiful
[17:09:40] <mux_> it's like kittens
[17:09:46] <mux_> nobody in their right mind would punch a kitten
[17:09:51] <Tom_itx> :)
[17:09:54] <Tom_itx> don't bet on it
[17:10:13] <mux_> I did put an asterisk on that: [in their right mind]
[17:10:16] <mux_> :D
[17:10:45] <mux_> anyway I'm off
[17:43:14] <specing> still shorted.
[17:43:22] <specing> FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU this board.
[17:43:44] <_aandrew> wtf is up with freenode today
[17:47:13] <specing> its shorted to GND
[17:49:27] <specing> What do you do when a piece of a copper track has fallen off the board?
[17:49:38] <specing> superglue it back?
[17:49:59] <specing> is there a glue whose vapour wont cause me cancer when soldering over it?
[17:50:00] <antto> call 911
[17:50:46] <antto> the avr rescue squad
[17:50:59] <CoolBear> specing: Bodge wire.
[17:51:46] <specing> Bodge wire?
[17:52:38] <CoolBear> Say like this:
http://i.imgur.com/4z5WGm1.jpg
[17:54:12] <specing> Oh, then I'll just solder it to a nearby resistor
[17:54:42] <CoolBear> Well, as long as it is supposed to be connected there, don't go soldering to a random resistor ;)
[17:56:18] <Lambda_Aurigae> can always use a 2-part epoxy.
[17:56:26] <specing> yeah, its supposed to be connected there
[17:56:38] <CoolBear> Just making sure, you never know :P
[17:56:39] <Lambda_Aurigae> something high temp like jb-weld...just remember that jb-weld is somewhat conductive as it contains metal flakes.
[17:57:53] <Lambda_Aurigae> as for superglue fumes causing cancer when heated,,,ventilation is your friend...and the fumes from solder flux are probably worse than superglue.
[18:04:35] <CoolBear> Mmm, solder fumes, my favorite.
[18:06:11] <Lambda_Aurigae> solder fumes and a welding suntan.
[18:13:57] <specing> it still doesen't pop up
[18:15:30] <Lambda_Aurigae> sounds like a personal problem to me.
[18:16:10] <specing> heh
[18:17:34] <specing> I've checked it with the voltmeter connection tester, and all lines are ok
[18:17:39] <specing> the MCU never pops up
[22:53:07] <FoxGT> Hypothetically... if an avr input saw 12v... would one say that it is "kaput"?
[22:53:49] <FoxGT> That may or may not have happened. It's acting all kinds of weird now, like the input is permanently grounded.
[22:54:21] <FoxGT> Fortunately; I have more, just curious if there was any way to attempt to fix them. :P
[23:25:15] <Casper> FoxGT: kaput yes, except if it's on the reset pin
[23:25:33] <Casper> also, due to the protection diodes inside, other stuff on the board may have been damaged
[23:29:13] <FoxGT> I figured so
[23:29:36] <FoxGT> Why not if it's on the reset pin, Casper?
[23:29:37] <Valen> I did something similar once
[23:29:43] <Valen> it reversed the tx and rx pinout
[23:29:52] <Valen> reset pin doesn't have the body diode
[23:29:56] <Casper> high voltage programming is basically SPI but a 12V reset instead of 0V
[23:30:00] <Valen> it can hit 13v or so for flash programming
[23:30:07] <Casper> so they made sure it tolerate 12V
[23:30:16] <FoxGT> ahhh
[23:30:26] <Valen> (flash erase needs high voltage)
[23:30:37] <Valen> or am i thinking eeprom
[23:30:47] <Casper> Valen: or possibly pic
[23:31:02] <Casper> avr can work with only 3.3V or even less, even for flash and eeprom
[23:31:12] <FoxGT> okay to link to youtube videos in here?
[23:31:25] <Valen> thats because they have an internal boost converter for the flash erase cycles as i recall
[23:31:48] <Valen> (which got rid of the need for high voltage programming)
[23:32:11] <Valen> though you need the HVP to reset some fuses etc as i recall
[23:32:14] <Valen> even in avr
[23:32:19] <FoxGT> https://www.youtube.com/watch?v=R9uBU7eTfTY
[23:32:40] <FoxGT> That was what it was for, but I wired the brake light to 12v on accident instead of ground. I cut the wrong wire.
[23:33:20] <Valen> yeah I must be thinking eeprom
[23:33:24] <Casper> Valen: yup, need it to disable and enable SPI
[23:33:28] <Casper> spi programming
[23:33:37] <Valen> so high voltage is used to be able to erase the eeprom
[23:33:43] <Casper> they put a protection so you can't disable spi while in spi
[23:34:20] <Valen> and I believe the fuses are set in eeprom not flash?
[23:34:24] <Casper> FoxGT: aaaand now that moto is illegal on the road
[23:34:38] <Casper> Valen: I think in flash
[23:34:39] <FoxGT> This is true. lol
[23:34:52] <Valen> looks cool though
[23:35:02] <FoxGT> I made it so you can shut it off if you turn it on while holding the brake in though.
[23:35:09] <FoxGT> "Wasn't me, officer."
[23:35:19] <Casper> I saw a guy a few years back, actually saw him many times... then no more...
[23:35:26] <Valen> I'd make it so it "spins" rather than having it go down to nothing like that
[23:35:31] <Casper> man that car was a cop magnet...
[23:35:36] <Valen> because at some point in thats cycle its just off
[23:35:49] <FoxGT> You think??
[23:35:56] <FoxGT> What do you mean, Valen?
[23:36:02] <Valen> I wanted to put pov lights in the missus wheels
[23:36:14] <Valen> reading the law I think if they are orange its ok ;->
[23:36:46] <Valen> well watching the video, the light on the right is "off" for a non zero time
[23:37:08] <Valen> I'd just make half the light red and then spin it around to get your animation
[23:37:47] <Casper> apple green paint, extra low profile tires with orange wheels, neon around the license plate, neon under the car, blue headlights, big bass.... now, the driver: possibly 18yo or so, cap in reverse, seat inclined, one hand outside the car, one lying on the top of the steering... plus some other details... like blue light inside at night
[23:37:53] <FoxGT> True. It didn't seem right when I had it jump right back in to being on again.
[23:38:20] <FoxGT> so it's got a 70 ms delay for turning on/off each light, when they're all off, it delays a bit longer.
[23:38:39] <FoxGT> It just looked weird when it was programmed to jump right back into the on cycle again.
[23:39:03] <Casper> FoxGT: so you hooked the avr on the ground side of the light and it's that one that is switched?
[23:39:08] <FoxGT> Maybe I'll try it again & see how it looks. It looked off while it wasn't on the bike.
[23:39:09] <Valen> yeah, thats dangerous to me
[23:39:31] <FoxGT> No.. the brake light input pin.
[23:39:36] <Valen> assume other drivers are going to glance at it and in any instant need to know what is going on
[23:39:56] <Valen> if i glance at it when its on 2 leds i'm going to presume its just a tail light not that the brakes are on
[23:40:07] <FoxGT> I was wiring it to the brake light switch & thought I clipped a different wire, so I basically just fed a pin that was supposed to pull low 12 volts.
[23:40:10] <Casper> FoxGT: you know that it most likelly have still 12V there?
[23:40:26] <Valen> anyway i must go do stuff
[23:41:12] <FoxGT> The way it's setup is the avr is supplied power via 7805 with the decoupling caps & protection diode
[23:41:37] <FoxGT> in order to signal, I had to cut all of the stock wires and make it so that it grounds all input pins.
[23:41:54] <Casper> now... to cut the wires on my new antenna...
[23:42:07] <Casper> hat need to be 23.62"...
[23:42:08] <FoxGT> I tried to take a shortcut when I got to the brake one because I thought that one of the wires went to ground (I hadn't had much sleep)
[23:42:30] <FoxGT> Needless to say, the turn signals still work, but it's like the brake light is permanently grounded.
[23:43:10] <Casper> need to do some math... I beleive I used a 1½ washer... so need to divide that in 2, then take the 23.6 and divide in 2, then substract the first I beleive... then mesure each of the 8 spikes...
[23:43:24] <FoxGT> Lol. an antenna??
[23:43:46] <FoxGT> Actually, I was going to post an instructable, but I'm not sure that my code is very good.
[23:44:02] <Casper> FoxGT: yup
[23:44:07] <FoxGT> It doesn't use interrupts at all. Basically just runs through a lot of if statements.
[23:44:27] <Casper> I wonder if my antenna will work well
[23:44:32] <Casper> it's kinda frightening
[23:45:20] <FoxGT> Why wouldn't it??
[23:45:25] <FoxGT> Pictures?
[23:45:53] <Casper> https://www.dropbox.com/s/mr2087y8ec4viaj/2014-08-18%2020.25.07.jpg
[23:46:40] <Casper> https://www.dropbox.com/s/eu27pq1am0bapnb/2014-08-18%2020.41.11.jpg
[23:46:50] <Casper> https://www.dropbox.com/s/dboq730uzw3u037/2014-08-18%2020.45.06.jpg
[23:47:09] <Casper> https://www.dropbox.com/s/v7i2ljzrcrplt71/2014-08-18%2021.13.23.jpg <=== that's the hat
[23:47:36] <FoxGT> What the...?
[23:47:40] <Casper> https://www.dropbox.com/s/n64zhb7pnqgynac/2014-08-18%2021.13.28.jpg <=== and my messy work area, don't worry, no smoke issue :D
[23:47:57] <FoxGT> What is this for??
[23:48:10] <FoxGT> Your work station looks about like mine.
[23:49:23] <Casper> but your don't have that fume extractor!
[23:49:45] <Casper> https://www.dropbox.com/s/la0yvxirj2xi364/2014-08-19%2000.30.15.jpg <=== assembled, but not aligned
[23:51:08] <Casper> it's for a software radio
[23:51:14] <FoxGT> I have no fume extractor. lol.
[23:51:17] <FoxGT> Is that bad?
[23:51:19] <Casper> should give me, in theory, 100-1000MHz
[23:51:30] <Casper> depend how much toxic fume you make
[23:51:34] <Casper> and how ventilated your room is
[23:51:58] <FoxGT> I have it ventilated where the fumes come back toward my face for 1second of full exposure.
[23:51:59] <Casper> woahhh I fucked up
[23:52:09] <FoxGT> Should keep me healthy
[23:52:26] <Casper> the hat spikes are supposed to be 11.8" not 24... woops :D
[23:52:51] <Casper> my fume extractor is simply a cloth dryer blower
[23:58:03] <Casper> FoxGT: what told you it was an antenna? and how much do you know about them?
[23:59:46] <FoxGT> 23:23] <Casper> now... to cut the wires on my new antenna...
[23:59:53] <FoxGT> :P
