Back
[07:22:54] <megal0maniac_afk> The endians strike again
[08:34:31] <sabesto> anyone used the xmega ADC in differencial mode?
[08:36:25] <sabesto> cant seem to be able to set it up like the datasheet suggests
[08:37:03] <sabesto> xmega256a3bu, using ADCA and input 4 and 5
[09:34:15] <megal0maniac> Can you set a pin change interrupt to only react to a falling edge?
[09:34:26] <megal0maniac> Oh nevermind
[09:34:32] <megal0maniac> ISC
[09:36:28] <megal0maniac> And it looks as though I have to use INTx and not PCINTx if I want to only look for falling edge
[09:44:26] <Tom_itx> yep
[09:44:38] <Tom_itx> PCINTx is both edges
[09:45:02] <Tom_itx> you can deal with it in the interrupt
[10:12:33] <DrLuke> how do I remove the STK500 in atmel studio 6.1?
[10:12:40] <DrLuke> I have 4 entries now, all don't work
[10:12:52] <DrLuke> because they try to access the wrong com port even though I selected a different one
[10:13:08] <DrLuke> http://i.imgur.com/XZpOQOi.png
[10:14:00] <DrLuke> nevermind I found it under view->available atmel tools
[10:15:47] <Tom_itx> a sure way would be to format the hdd and reinstall studio
[10:16:19] <theBear> or format it, install a real os, and never think of studio again
[10:16:21] <theBear> :)
[10:16:36] <Tom_itx> that came to mind
[10:29:27] <DrLuke> argh
[10:29:37] <DrLuke> my avr keeps just resetting after a few ms
[10:29:42] <DrLuke> and I have no idea why
[10:29:48] <DrLuke> the reset pin is staying high
[10:30:27] <DrLuke> is there any way to determine the reset cause?
[10:32:35] <twnqx> yes
[10:32:46] <twnqx> well, at least for some
[10:33:29] <DrLuke> I have an atmega1284p
[10:34:04] <twnqx> check for MCUSR in the data sheet
[10:36:20] <DrLuke> ah, thanks!
[10:37:00] <Tom_itx> WDT
[10:37:57] <twnqx> (if it's empty you probably just crashed the chip)
[10:38:36] <megal0maniac> DDRB = 0xFF; PORTB = MCUR;
[10:38:43] <megal0maniac> Add LEDs and hey presto!
[10:38:58] <megal0maniac> *MCUSR
[10:39:01] <twnqx> static const __ATTR_PROGMEM__ char resetsources[5][16] = {
[10:39:01] <twnqx> "Power-on ", "External Reset ", "Brown-Out ", "Watchdog ", "JTAG "
[10:39:01] <twnqx> };
[10:39:10] <twnqx> for (i=PORF; i<=JTRF; i++)
[10:39:10] <twnqx> if (MCUSR & (1<<i))
[10:39:10] <twnqx> uart0_writepstring (resetsources[i]);
[10:39:11] <twnqx> :P
[10:39:26] <megal0maniac> Oh pfft
[10:39:58] <megal0maniac> The hell does that first line do?
[10:40:14] <Tom_itx> puts the var in program mem
[10:40:22] <Tom_itx> and makes it static
[10:40:24] <twnqx> the array of strings*
[10:40:57] <megal0maniac> [5][16]?
[10:41:08] <twnqx> twodimensional arrays
[10:41:12] <megal0maniac> Oh!
[10:41:19] <Tom_itx> char array of 5, 16 in length eacy
[10:41:21] <Tom_itx> each
[10:41:23] <megal0maniac> With 16byte blocks for strings
[10:41:26] <twnqx> yes
[10:41:34] <megal0maniac> Clever :0
[10:41:36] <megal0maniac> )
[10:42:51] <megal0maniac> Tom_itx: Have you heard of Miller beer? Because it says Milwaukee, WI, USA on the bottle. But I'm sceptical
[10:43:03] <Tom_itx> it's common in the us
[10:43:10] <twnqx> MILler, MILwaukee. makes sense.
[10:43:30] <megal0maniac> Cool. Cheers :)
[10:43:53] <Tom_itx> just your average drunk's beer
[10:44:39] <megal0maniac> Well here it's imported :P
[10:45:06] <Tom_itx> Budweiser, Miller and Coors are probably the most common here
[10:47:01] <DrLuke> ok, so MCUSR tells me that I have a watchdog-reset. This confuses me, as I don't even have the watchdog timer enabled!
[10:47:13] <twnqx> lol
[10:47:14] <megal0maniac> Yes you do!
[10:47:22] <twnqx> isn't WDT a fuse thing?
[10:47:35] <twnqx> or at least possibly a fuse thing?
[10:47:39] <Tom_itx> yeah
[10:47:46] <Tom_itx> it's generally disabled
[10:49:00] <DrLuke> well I have it disabled in the fuses
[10:49:33] <Tom_itx> is it vector 0
[10:49:42] <twnqx> maybe, maybe not :P
[10:50:33] <DrLuke> oh god
[10:50:50] <DrLuke> disabling the fuse worked, but I had to reprogram it one more time for it to kick it in
[10:50:56] <DrLuke> weird
[10:51:02] <DrLuke> atleast it stopped with the resetting now
[10:51:14] <RikusW> reprogram + power cycle should work too
[10:51:41] <megal0maniac> Lo RikusW :)
[10:51:50] <RikusW> Hi megal0maniac
[10:59:45] <DrLuke> oh man this is so strange, now I get the brown out flag AND the external reset flag
[10:59:54] <DrLuke> after around 100ms of code execution
[11:08:48] <RikusW> is there a pullup on reset ?
[11:08:59] <RikusW> and whats the brownout voltage set to ?
[11:09:11] <RikusW> how about having enough caps around ?
[11:09:15] <RikusW> *connected
[11:09:25] <DrLuke> yes
[11:09:32] <DrLuke> brownout is disabled in fuses
[11:09:56] <rue_house> zlog
[11:10:25] <rue_house> what do you have on the io lines?
[11:10:42] <rue_house> what is your power source?
[11:11:25] <rue_house> what is te avr and what are you fuses set to?
[11:12:32] <DrLuke> rue_house: Power source is an FTDI cable (5V), there's stuff on i2c, spi, different IO of ICs
[11:13:13] <rue_house> hah
[11:13:22] <rue_house> then you power is probably ducking out
[11:13:27] <DrLuke> Hm
[11:13:47] <rue_house> 5V isn't garunteed on usb
[11:13:57] <rue_house> you get anywhere from 5.7 to about 3 iirc
[11:14:04] <rue_house> its just USUALLY 5
[11:14:31] <rue_house> try a REALLY large capacitor across the power rails and see, for the most part, if that clears it up
[11:14:36] <DrLuke> I use an USB hub, with a 4A psu
[11:14:36] <rue_house> or get a real 5V supply
[11:14:41] <DrLuke> I think it's pretty stable :)
[11:14:51] <rue_house> its running thru the hub?
[11:14:54] <DrLuke> yes
[11:15:03] <DrLuke> it also did that directly on the PCU
[11:15:05] <rue_house> is it a cheap chinese hub or a noth american smart one?
[11:15:22] <DrLuke> well, the hub was made in germany
[11:15:35] <rue_house> then it pobably has power control on it
[11:15:35] <DrLuke> and the power supply is a DC-DC supply that looks like it cost more than 1$ to produce
[11:15:54] <DrLuke> let me check the power rail with my scope
[11:16:00] <rue_house> any more than 250mA (?) without the usb asking for more and it would duck out
[11:16:26] <rue_house> if it was a cheap chinese one, the power just goes straight thu, no overload protection
[11:17:20] <DrLuke> the power rail is at a stable 4.8V with all LEDs on the board turned on
[11:17:25] <vsync_> and, if it was a "smart american one", i wouldn't be surprised if you got electricuted with mains out of it
[11:17:28] <DrLuke> and 4.9V with the LEDs off
[11:17:52] <vsync_> like the chargers this one particular fruit company produces
[11:18:06] <DrLuke> that only happened with chinese fake ones though
[11:18:10] <rue_house> vsync_, I got a chinese led driver, scarry, scarry stuff, no isolation
[11:18:13] <DrLuke> apple chargers always were safe
[11:18:24] <vsync_> DrLuke: read your news better
[11:18:31] <DrLuke> source?
[11:18:47] <vsync_> can you understand finnish?
[11:18:47] <rue_house> what capacitors do you have across the power rails
[11:18:57] <DrLuke> all the news I heard about that were apple chargers that looked like the real thing, but were fakes
[11:19:15] <DrLuke> rue_house: big electrolytes (330 uF), and several small ceramics
[11:19:33] <DrLuke> one for every VCC input
[11:19:38] <DrLuke> places close to it
[11:19:39] <rue_house> hmm
[11:19:41] <DrLuke> placed*
[11:19:48] <rue_house> it'd have to duck pretty hard to lose that
[11:20:04] <DrLuke> well the AVR itself doesn't drive any LEDs
[11:20:10] <vsync_> DrLuke: if you speak finnish. then here
http://www.iltasanomat.fi/kotimaa/art-1288582526949.html. otherwise, be quiet
[11:20:11] <rue_house> breadboard? any chance of a bad power connection?
[11:20:24] <rue_house> what the peak current per led?
[11:20:32] <DrLuke> Vsync_: No need to be rude.
[11:20:42] <DrLuke> rue_House: No, this is a PCB
[11:20:53] <DrLuke> and it's the tiny QFN package
[11:21:03] <rue_house> your sure the solder is ok?
[11:21:07] <vsync_> smoked it
[11:21:08] <DrLuke> yep
[11:21:13] <rue_house> the power pin dosn't just look soldered
[11:21:15] <rue_house> hmm
[11:21:38] <DrLuke> I can check again, but there was nothing I could see with either the bare eye or with my eyepiece
[11:21:44] <DrLuke> I sadly don't have a fancy microscope
[11:22:08] <DrLuke> I should also mention this was populated in a pick an place house
[11:22:15] <rue_house> if it was one of my projects, it would probably be an output driver grounding out my avr supply
[11:22:29] <rue_house> does the code do anything at the 100ms mark?
[11:22:48] <DrLuke> it just loops
[11:23:00] <DrLuke> I print "test"
[11:23:10] <DrLuke> uart_puts("test");
[11:23:11] <DrLuke> whoops
[11:23:34] <DrLuke> http://i39.tinypic.com/2miwau.png
[11:23:50] <DrLuke> and it outputs the gps stuff, too
[11:24:28] <DrLuke> wtf, now it worked for longer, almost 2 seconds
[11:24:45] <rue_house> do you have a power led to watch?
[11:24:54] <rue_house> can you recreate it with while(1)
[11:24:59] <Tom_itx> sounds like a bad connection
[11:25:13] <rue_house> how do we know your string handling isn't overlfowing
[11:25:27] <DrLuke> I'm using peter fleury's uart lib
[11:25:38] <DrLuke> never failed me before, but this might be that one time
[11:25:39] <Tom_itx> or the baudrate has too many errors
[11:25:53] <DrLuke> I'm on 8MHz, and 9600 baud
[11:26:26] <Tom_itx> http://www.wormfood.net/avrbaudcalc.php
[11:26:36] <Tom_itx> .2%
[11:26:53] <rue_house> do a stupid-simple code test
[11:26:55] <megal0maniac> acceptable!
[11:27:02] <rue_house> so your testing ONLY the hardware
[11:27:07] <DrLuke> yep
[11:30:07] <DrLuke> I think I pinpointed it to the SPI hardware
[11:30:53] <DrLuke> when I call this function:
http://pastebin.com/dvPvKQff it stops
[11:37:11] <sjokkis> any of you used freertos on avr before? i'm trying to make the atmega323 port run on an at90usb but it does a reset at, seemingly, a fixed interval
[11:37:30] <sjokkis> i fixed the lack of a tick that i had yesterday, if any of you were around then
[11:39:35] <sjokkis> as far as i can tell, based on the built-in overflow detection, it's not stack overflow
[11:53:25] <megal0maniac> Does anyone know anything about using avarice in Linux with a usb device? (libusb, not /dev/ttyUSBx)
[11:55:12] <megal0maniac> I keep getting "did not find any USB device "usb" "
[12:03:52] <Fornaxian> not sure that avarice can do that.
[12:04:02] <Fornaxian> unless you have a serial bootloader on there supported by avarice
[12:04:50] <megal0maniac> I mean a USB based debugger. I.e. JTAGICE3 as opposed to JTAGICE MKI. Support is only in trunk, so documentation is vague and sparse
[12:05:04] <Fornaxian> oh wait....debugger.
[12:05:17] <Fornaxian> duh...
[12:05:21] <megal0maniac> :)
[12:05:24] <sjokkis> huh, and now, inexplicably, it works
[12:05:28] <sjokkis> embedded is weird
[12:05:36] <Fornaxian> I was thinking of something else entirely...like avrdude but older.
[12:05:57] <Fornaxian> what is your jtagice3 device in /dev ??
[12:06:54] <megal0maniac> hid-generic 0003:03EB:2140.0002: hiddev0,hidraw1: USB HID v1.11 Device [Atmel Corp. JTAGICE3 CMSIS-DAP] on usb-0000:00:1d.0-1.2/input0
[12:08:11] <Fornaxian> but what device does it setup as in /dev ?
[12:08:23] <Fornaxian> that looks like the output from lsusb
[12:08:46] <megal0maniac> That's from dmesg. I'd expect it to tell me there, if at all
[12:08:57] <megal0maniac> lsusb
[12:09:07] <megal0maniac> Sorry, wrong terminal window :)
[12:11:29] <megal0maniac> Yeah, I have no idea
[12:14:47] <megal0maniac> avrdude gives the same error :/
[12:15:07] <megal0maniac> usbdev_open(): did not find any USB device "usb"
[12:18:29] <megal0maniac> Everything libusb was installed when i compiled :/
[12:19:03] <megal0maniac> And sudo doesn't help which eliminates udev issues
[12:19:43] <Tom_itx> wrong libusb ver?
[12:19:54] <Tom_itx> i got that on windows once
[12:19:55] <megal0maniac> All of them!
[12:20:21] <Tom_itx> wrong compiler ver?
[12:20:33] <Tom_itx> want a hint?
[12:20:38] <Tom_itx> get avrdude from arduino
[12:20:43] <Tom_itx> it works
[12:21:30] <Tom_itx> as far as anything else, you're on your owm
[12:21:44] <megal0maniac> It's also the very latest firmware, which iirc, doesn't use Jungo. So I might be treading uncharted waters
[12:21:52] <megal0maniac> abcminiuser: You would know
[12:22:07] <abcminiuser> Hva?
[12:22:09] <megal0maniac> Should I just go back to Windows where everything works? :P
[12:22:12] <Tom_itx> avrdude doesn't use JUNGO sir
[12:22:21] <Tom_itx> and if you have it installed it will interfere
[12:22:32] <abcminiuser> Aww man scrollback
[12:22:34] <megal0maniac> Well I'm running Linux so I can't
[12:22:43] <Tom_itx> libusb.dll
[12:22:55] <Tom_itx> or whaever equivalent linux has
[12:23:15] <megal0maniac> abcminiuser: Wasn't there a recent major firmware change for the jtagice3?
[12:23:29] <abcminiuser> Indeed
[12:23:40] <abcminiuser> 3.x branch has a HID wrapper
[12:23:41] <megal0maniac> I'm experimenting with getting it work in Linux, and I'm starting to suspect that this might be the problem
[12:24:07] <abcminiuser> Yeah, you're using the CMSIS-DAP version
[12:24:11] <vsync_> any way of getting usbasp to work with atmel studio 6.1? or must i keep on using another flashing program :x
[12:24:14] <abcminiuser> Which is the new/different one with HID
[12:24:25] <abcminiuser> Need to downgrade it back to 2.x for the Jungo version
[12:26:10] <megal0maniac> And avrdude / avarice on Linux are probably expecting whatever protocol 2.x uses
[12:26:46] <megal0maniac> I'll mail Joerg Wunsch maybe. He'll know.
[12:26:52] <megal0maniac> Brb, food :)
[12:28:36] <abcminiuser> The use V2
[12:49:26] <megal0maniac> abcminiuser: And as far as I know, firmware downgrades aren't possible
[12:49:39] <abcminiuser> We have a tool to do it
[12:49:43] <abcminiuser> Search the Atmel Gallery
[12:49:54] <megal0maniac> Oh?
[12:50:05] <megal0maniac> Didn't think Atmel wanted people to downgrade
[12:52:11] <megal0maniac> Cool, found it
[13:03:36] <megal0maniac> Wow it's slow... Nearly 3 minutes to read 256kb over JTAG
[13:07:20] <megal0maniac> And 2 seconds over PDI. Acceptable :P
[13:16:28] <Tom_itx> odd
[13:16:36] <Tom_itx> jtag is usually faster
[13:16:52] <Tom_itx> their jtag must not be very efficient
[13:33:49] <megal0maniac> Must be. PDI is nice and fast
[15:16:15] <Roklobsta> just wondering - who can supply epaper/eink modules in low qty?
[15:22:07] <specing> wat
[15:23:27] <jadew`> sup?
[15:23:46] <jadew`> Casper, any new pics/screens?
[15:38:25] <NTQ> Hi guys. I have a problem with my AVRISP mkII and the USB3.0 Port on Linux Debian. If I plug in the programmer on a USB2.0 port it works fine. If I try a USB3.0 port I got this error:
http://pastebin.com/RAqhGhbC
[15:38:56] <NTQ> With sudo avrdude ... I have also no problems.
[16:04:15] <megal0maniac> Patient: "Doctor, it hurts when I do this"
[16:04:22] <megal0maniac> Doctor: "Stop doing that"
[16:04:30] <megal0maniac> NTQ: ^
[16:05:07] <sjokkis> i'm writing to a display, and the first half of the line i'm writing is garbage, followed by the characters i want to display. anyone experienced this before and recognize what it might be?
[16:06:09] <megal0maniac> NTQ: It isn't an AVRISP issue, because USB3 ports are supposed to fall back into a fully compatible USB2 mode if the device isn't "superspeed" capable. So it's either a hardware (your computer) or driver issue.
[16:07:00] <megal0maniac> sjokkis: What kind of display and how are you communicating with it?
[16:08:30] <sjokkis> megal0maniac: it's an OLED display, and it's connected to the external memory interface
[16:08:34] <NTQ> megal0maniac: I think also it's a driver issue from linux. But I had this problem first a few weeks ago. Before it works also on USB3.0
[16:08:57] <sjokkis> megal0maniac: i have a test hex file i've been provided with, so i know the display works
[16:08:59] <NTQ> Maybe some package updates forces this issue
[16:14:26] <megal0maniac> sjokkis: Serial? SPI? I2C? Parallel?
[16:16:11] <sjokkis> megal0maniac: parallel
[16:23:41] <rue_shop3> where dat fuse calculator
[16:24:49] <sjokkis> rue_shop3: the baud rate one? just google baud rate calculator
[16:25:08] <rue_shop3> no for fuse bits
[16:25:19] <sjokkis> oh i misread
[16:26:17] <rue_shop3> was it furrywolf who did that one?
[16:26:23] <rue_shop3> cant fine it
[16:26:23] <Tom_itx> http://www.engbedded.com/fusecalc/
[16:26:33] <rue_shop3> no where is the one the guy here made?
[16:36:26] <rue_shop3> is ther ea diff between a m32 and a m32A?
[16:37:34] <Tom_itx> A
[16:38:09] <rue_shop3> aside form the letter on the top
[16:40:14] <rue_shop3> hmmm why isn't this led flashing
[16:40:24] <rue_shop3> what different betwen m32 and m32a
[16:41:07] <Tom_itx> either power or frequency rating
[16:41:22] <rue_shop3> http://www.atmel.com/Images/doc8162.pdf
[16:41:30] <rue_shop3> The ATmega32A is a functionally identical, drop-in replacement for the ATmega32.
[16:42:16] <rue_shop3> just power consumption
[16:42:24] <rue_shop3> ok, why is my led no flashing
[16:44:26] <sjokkis> you're turning it on and off repeatedly
[16:46:03] <rue_shop3> ah, my dev board was upsde down ahahaha
[16:46:09] <rue_shop3> serves me for not marking port 1
[16:47:14] <rue_shop3> (the avrs are from china, they were wrapped in sawran wrap, I have lots to be suspicious of
[16:47:17] <rue_shop3> )
[16:49:06] <rue_shop3> aha, and my fuse programming is blowing away the firmware
[16:49:24] <rue_shop3> stray -e
[16:50:12] <rue_shop3> ok they are really avrs, and on atleast 2/10 of them, port B0 works
[16:51:03] <inkjetunito> hehe. surprise components
[16:52:43] <rue_shop3> well, sometiems for the price, I wonder if I'm getting laser-etched empty chipsless dips
[16:52:57] <rue_shop3> sometimes it wouldn't surprise me
[16:53:52] <inkjetunito> fake tools are damn annoying
[16:54:24] <inkjetunito> skipping hardening seems to be one way to lower costs
[16:55:54] <sjokkis> hm, this is weirder still. my oled writes fine when i program the avr. but if reset, nothing
[16:56:41] <sjokkis> is the avr started up in a different way when you've just written to it compared to pressing the reset button you'll find on most dev boards?
[17:08:49] <sjokkis> doing a verify also rewrites the display, but disconnecting/reconnecting power leaves it blank
[17:08:52] <sjokkis> weirdness
[17:11:19] <sjokkis> if i power off, attach and then detach the jtag, and then power up, it writes
[17:11:29] <sjokkis> but not if i leave the jtag in when i cycle the power
[17:11:49] <sjokkis> and not if i leave it out while i cycle the power
[17:12:51] <sjokkis> might have been a fluke. doesn't happen again :(
[17:22:52] <Casper> jadew: I sent you a pm yesterday
[17:22:55] <Casper> did you got it?
[18:34:39] <sjokkis> well this is some interesting fuckery
[18:34:53] <sjokkis> the display works just as it should, if i add a wait no shorter than 150ms before initializing it
[18:35:27] <sjokkis> is there anything in the avr startup that takes that long?
[18:35:53] <vsync_> chances are it's on the display's end
[18:36:47] <sjokkis> i'd be interested to know what, but this datasheet isn't the best
[18:37:57] <vsync_> in display datasheets those things are rarely documented
[18:38:15] <sjokkis> i guess that would make things too easy
[18:38:19] <twnqx> i have seen lcd manuals that describe such delays
[18:39:15] <vsync_> i said rarely, i have seen such things also
[18:39:32] <sjokkis> do you know what the deal is?
[18:41:34] <vsync_> not sure. But when i tinker with lcd's i usually wait a moment before initializing it
[18:44:51] <Fornaxian> you might have to do something with a reset line then within a certain amount of time initialize it perhaps?
[18:47:48] <sjokkis> oh, i just had a small nerdgasm
[18:48:00] <sjokkis> since i'm using a scheduler, this wait doesn't even waste cycles
[18:53:33] <vsync_> i really need a scope at home :-)(
[18:53:39] <vsync_> :-(
[18:53:44] <sjokkis> :(
[18:54:10] <vsync_> fast times on the spi bus :(
[19:06:44] <Casper> jadew: where are throu?
[19:13:44] <sjokkis> i'm playing around with printing to my display, and when i print the tick count (goes from 0 to 65k and wraps around), it prints squares at the end of numbers that aren't five digits. what's the common way to pad out strings with spaces at the end?
[19:15:03] <Fornaxian> with,,,spaces?
[19:15:23] <Fornaxian> or display it as 00000 - 65535
[19:15:50] <sjokkis> i'm using itoa to convert the tick count from an integer to a string and then i'm printing it
[19:16:15] <sjokkis> my print function takes a char pointer and a string length. perhaps it should break on NULL as well
[20:05:47] <vsync_> question, how critical is the length of the spi bus leads when running the chip at 8 MHz?
[20:08:01] <vsync_> as to my understanding it shouldn't be that critical
[20:20:49] <Casper> until the delay is too high or the signal too degraded :D
[20:42:04] <vsync_> figures, lol
[20:42:11] <vsync_> ";P;p"
