Back
[05:15:35] <abcminiuser> Err
[05:15:40] <abcminiuser> Emails, get your free emails here
http://delivery2.emailcontact.com/nl/tmp/
[05:15:42] <abcminiuser> :S
[05:40:24] <Lambda_Aurigae> umm.
[05:40:37] <Lambda_Aurigae> got my free gmail account...don't need any more.
[06:00:52] <inflex> hiya abcminiuser
[09:47:26] <balrog-k1n> does the RAM get cleared on a watchdog reset?
[09:47:37] <RikusW> no
[09:47:42] <balrog-k1n> cleared or otherwise lost
[09:47:52] <RikusW> or it depends, the C runtime does that
[09:48:03] <RikusW> in asm you have to manually clear it
[09:48:15] <RikusW> registers remain the same
[09:49:01] <balrog-k1n> yeah, i'm manually cleaning the .bss section and it wouldn't work without that (it's in a bootloader), so i thought the whole ram would persist over the watchdog reset too,
[09:49:15] <balrog-k1n> but it doesn't seem to work.. i may have a bug elsewhere though
[09:51:05] <balrog-k1n> BTW is there a good way to find out if the watchdog reset happened in the bootloader or in the app?
[09:51:34] <balrog-k1n> i was trying to store a magic value somewhere in sram, and then checking if it's there after reset, but this is what i'm having issues with
[09:55:49] <RikusW> Use registers for the magic ?
[09:56:09] <RikusW> for SRAM you need to check before its erased in code
[09:56:24] <RikusW> Which AVR do you use ?
[09:57:44] <RikusW> NetworkManager+PPP :S
[09:58:33] <RikusW> When the other PC on the crossover ethernet cable gets turned on/off Pidgin disconnects :(
[10:01:58] <balrog-k1n> RikusW: atmega328, the code only overwrites the ~46 bytes at the start of RAM (.data and .bss), i tried saving the magic somewhere in the middle and at the end (and moving SP a little lower)
[10:02:28] <balrog-k1n> RikusW: are you sure the registers persist over reset?
[10:02:44] <balrog-k1n> i guess i could reserve some so that gcc doesn't use them
[10:03:05] <RikusW> registers persist, IO doesn't
[10:03:14] <balrog-k1n> ok
[10:03:19] <balrog-k1n> i'll try that next then
[10:03:24] <RikusW> you can create a .noinit section for ram
[10:04:13] <RikusW> volatile u8 conf_nr __attribute__ ((section (".noinit")));
[10:04:23] <RikusW> and place variable in it like this
[10:05:12] <RikusW> you can even set the .noinit address to a fixed value if required
[10:05:54] <RikusW> LDFLAGS += -Wl,-section-start=.noinit=0x800100
[10:05:55] <RikusW> LDFLAGS += -Wl,-section-start=.data=0x80010e
[10:06:01] <RikusW> from my AS4 generated makefile
[10:10:44] <balrog-k1n> that would work provided that the ram is indeed not mangled at reset
[10:14:13] <clever> balrog-k1n: one minute
[10:14:36] <clever> balrog-k1n: look at the MCUSR register
[10:14:42] <clever> it tells you exactly what caused the last reset
[10:15:14] <JFK911> browntown detection reset
[10:16:01] <balrog-k1n> clever: already using it, but I'm trying to distinguish between two watchdog resets
[10:16:20] <clever> ah
[10:16:23] <balrog-k1n> i.e. between watchdog reset in the bootloader and watchdog reset in the app
[10:17:38] <clever> let me pull out my stack overflow code, it may be of us
[10:17:38] <clever> e
[10:18:01] <clever> extern uint8_t __bss_end;
[10:18:35] <clever> balrog-k1n: this points to the end of the bss segment, i'm setting it to a semi-random number which i then check at regular intervals
[10:18:42] <clever> if the stack overruns into bss, it will change
[10:18:54] <clever> you could use the same trick to store data beyond the bss segment
[10:19:56] <balrog-k1n> clever: yeah, but questoin is will any of that persist over the watchdog reset?
[10:20:19] <clever> not sure
[10:20:30] <clever> seems easy to test
[10:21:24] <balrog-k1n> yeah.. maybe a good idea to actually test it :)
[10:32:43] <clever> balrog-k1n: section 10 in my pdf, system control and reset
[10:33:38] <clever> it appears to not touch the ram after reset
[10:33:40] <clever> only registers
[11:10:00] <x3medima17> hello, I'm newbie in AVR. I did a device that sends something by USART, but when I try to see info on my computer I see 2 more bits. For example if I send number 64 I get 11001000
[12:46:48] <The_Coolest> if I use a 2.048v voltage reference for Vref, what zener size should i used for over voltage protection without degrading the resolution of the adc?
[12:46:59] <The_Coolest> considering the datasheet states MAX input of Vref
[12:48:17] <JFK911> is that an electrical limit
[12:48:27] <JFK911> 'absolute maximum rating'
[12:48:46] <The_Coolest> ADC Characteristics
[12:49:05] <JFK911> i would think a zener hurts
[12:49:14] <The_Coolest> Voltage on any Pin except RESET
[12:49:14] <The_Coolest> with respect to Ground ................................-0.5V to V
[12:49:14] <The_Coolest> CC
[12:49:14] <The_Coolest> +0.5V
[12:49:26] <The_Coolest> JFK911 yup, it's not the best idea
[12:49:43] <JFK911> but on Vref (I dont know for sure) I would think that an input greater than that would just make it spit out ones
[12:50:02] <JFK911> and not cause any smoke
[13:01:46] <The_Coolest> mhmm
[13:02:27] <Casper> The_Coolest: zener ain't needed
[13:04:45] <Casper> The_Coolest: past VREF the ADC will read the max value
[13:05:13] <Casper> at VCC+0.3V the internal diodes will kick in and "short" the pin to VCC
[13:05:48] <Casper> if you expect it to excede VCC then you hsould consider to put a series resistor to limit the current to a safe value
[13:05:58] <myself> yeah, because those internal diodes aren't very strong
[13:06:05] <myself> rely on them at your peril :P
[13:06:14] <Casper> but such resistance can cause issues due to the internal capacitance of the pin
[13:06:31] <Casper> atmel push 1mA throught them
[13:06:42] <Casper> but I couln't figure out what is the official limit
[13:10:37] <myself> the scanlime rfid tag abuses them pretty hilariously
[13:10:50] <myself> but I'd shoot any designer who did that in anything but jest :P
[13:13:21] <The_Coolest> Casper thanks!
[13:13:52] <The_Coolest> so should I perhaps use an external diode just in case (I already have a resistor before the pin)
[13:14:04] <The_Coolest> a diode instead of the zener
[13:28:58] <The_Coolest> hmmm?
[16:28:44] <logic|fm> Can anyone explain why i'm getting "Error: Garbage at end of line" on:
[16:28:45] <logic|fm> LDI R16, high(0x8FF)
[16:28:58] <logic|fm> or LDI R16, high(RAMEND)
[16:29:26] <logic|fm> avr-gcc 4.8.1 Crosspack AVR, atmega328p
[16:32:18] <Jordan_U> I'm looking for a rugged display for an industrial control, operating and storage temparature rance at least -40 to + 70 Celsius, lifetime in the range of decades (though it seems we'll have to compromise and have the display off for most of its life to accomplish that) to be used with an Atmel microcontroller. Right now I'm looking at
http://www.newhavendisplay.com/specs/NHD-2.7-12864UCY3.pdf which looks like it will be a good fit ...
[16:32:24] <Jordan_U> ... but I'm wondering if there are displays which already have nice a nice AVR library or are otherwise recommended. A graphical display would be nice, but this will primarily be displaying text and reduced cost or reduced complexity of code could easily convince me to go with a text only display instead. Any recommendations or advice?
[16:37:27] <logic|fm> where is high/low() macros defined?
[16:44:20] <The_Coolest> Jordan_U well an oled display is probably your best bet for such extreme temps
[16:45:54] <Jordan_U> The_Coolest: That's what I've discovered. It seems like OLED and Vaccum Flurescent are my only options, and I can't find good data on lifetime for any of the VFDs I've found.
[16:47:38] <The_Coolest> checked noritake? they often send out free samples
[16:48:09] <JFK911> really?
[16:48:19] <The_Coolest> yeah i got 2
[16:48:23] <JFK911> what size
[16:48:27] <Jordan_U> The_Coolest: No I haven't, but I'm doing so now :)
[16:48:29] <The_Coolest> some other guy got a massive 512x32
[16:48:33] <JFK911> wow
[16:48:40] <JFK911> they denied me 5-6 years ago
[16:49:07] <The_Coolest> http://www.noritake-elec.com/evalkit-sample.php
[16:49:35] <Jordan_U> The_Coolest: How difficult was it to use (software wise)? Good libraries available?
[16:50:11] <The_Coolest> well i haven't actually tried mine yet, but should be easy enough
[16:50:18] <The_Coolest> they have AVR libs I think
[16:50:21] <JFK911> they should be as easy as 44780
[16:50:31] <The_Coolest> yeah
[16:50:41] <The_Coolest> they have a built in MCU
[16:50:44] <Jordan_U> "This promotion has ended." :(
[16:51:06] <The_Coolest> :[
[16:52:00] <JFK911> of course they will SELL you them
[16:52:39] <The_Coolest> they also had some left over CU20045SCPB-W5Js for $18 but i think they're out
[16:54:12] <Jordan_U> I've never driven any type of display before so I'm not really sure what to expect. Can I expect nice libraries for pretty much any display I find that otherwise matches my criterion? What should I be looking for when trying to find a display that's easy to work with?
[16:54:19] <The_Coolest> well they have sample prices :\
[16:55:45] <The_Coolest> Jordan_U hard to say
[16:56:06] <The_Coolest> there are plenty of good libs for graphic LCDs
[16:56:54] <Jordan_U> I can afford to spend a little buying multiple displays to try, but I can't afford to try all of the displays that I've found that match the criterion and I don't want to end up having purchased 5 different displays that all have terrible interfaces when there are displays with nice ones avaialble.
[16:56:55] <The_Coolest> really depends what type you need. if you can make due with text display it'll probably be simpler
[16:57:30] <The_Coolest> http://noritake-vfd.com/cu20045-uw5a.aspx
[16:57:53] <The_Coolest> there you go, hd44780 compatible, -40-+85
[16:58:04] <The_Coolest> standard 20x4 pcb size
[16:58:24] <The_Coolest> but this isn't a graphic display
[16:58:45] <The_Coolest> VFDs are also power hungry, so keep that in mind compared to LCDs
[17:00:14] <Jordan_U> The_Coolest: Heaters are even more power hungry, and it seems like all of the LCD displays that advertise "Operating Temperatures" of -40 C have a build in heater, and cannot even be stored at -40 C, making them not an option for our use.
[17:00:37] <The_Coolest> I see
[17:52:59] <Valen> Jordan_U: e paper?
[17:53:38] <Valen> also if you are planning decades of life, watch out for the data retention of flash and eeprom stuff
[18:07:52] <Jordan_U> Valen: I hadn't thought of e-paper. I wonder if there is e-paper rated for rugged use like this. I also hadn't thought about flash data retention (only write cycles), so I'll definitely look into that. Thanks.
[19:06:13] <scoy> trying to program my new xmega128a4u with avrispmkII + avrdude ... linker fails with crtx128a4u.o not found. verified it does NOT exist on my HD. avr-libc/avr-gcc/avrdude all up to date. any ideas?
[19:07:00] <scoy> avrdude can connect to the xmega and read its signature. even get the green light on the avrispmkII
[19:09:31] <Tom_itx> what's the linker file got anything to do with avrdude?
[19:10:13] <Tom_itx> does the mkII do PDI?
[19:11:36] <Lambda_Aurigae> the linker error has nothing to do with avrdude at all.
[19:18:30] <scoy> i was throwing that out there to outline my scenario. regardless, avr-gcc recognizes -mmcu=atxmegaa4u as a valid option, but the linker complains that it cannot find crtx128a4u.o
[19:19:34] <scoy> i can get it to compile when I change -mmcu=atxmega128a3
[19:19:57] <Tom_itx> maybe gcc doesn't support that chip yet
[19:21:09] <scoy> yea, that's my thought. it's misleading that avr-gcc lists "atxmega128a4u" as a valid mmcu option but won't compile it. figured i'd ask about it hear in case i'm overlooking something
[19:21:27] <scoy> *here
[19:21:45] <Tom_itx> you can get gcc from atmel ya know
[19:21:52] <Tom_itx> probably not for linux
[19:21:56] <Tom_itx> i haven't checked
[19:22:14] <Tom_itx> it would be more current
[19:22:55] <Valen> Jordan_U: whats the application anyway?
[19:23:12] <scoy> Tom_itx, is that the "Toolchain for Linux?"
[19:23:42] <Tom_itx> it's the toolchain for avr
[19:24:20] <Tom_itx> http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx?tab=overview
[19:27:23] <Tom_itx> it's in the supported device list
[19:29:36] <scoy> i've a cross compile setup on gentoo with the most recent versions of avr-libc, avr-binutils and avr-gcc. must be an issue with my cross-compile setup
[19:36:12] <scoy> or a bug. i have all of those packages installed with the ~x86 keyword. downgrading to stable now.
[19:39:25] <Lambda_Aurigae> maybe a patch needed for that particular chip to work right.
[19:41:34] <Lambda_Aurigae> is that file not part of avr-libc?
[19:46:20] <Lambda_Aurigae> scoy, avr-libc official webpage doesn't list that chip as supported.
[19:49:12] <Tom_itx> the atmel provided toolchain does
[19:49:46] <Tom_itx> pretty sure that's yer problem
[19:53:56] <scoy> Lambda_Aurigae, i'm guessing it is part of it, but for whatever reason gentoo's version doesn't have it.
[19:54:12] <scoy> if the downgrade fails I'll pull the source from Atmel and try their version
[19:55:46] <Lambda_Aurigae> ubuntu's version doesn't have it in avr-libc
[21:25:06] <Jordan_U> Valen: A control box for industrial prelube (among other things).
[23:45:50] <Valen> Jordan_U: that does sound particularly dirty, (well it does to me but then I have a *dirty* mind) ;->