Back
[00:01:17] <Grievar> I think that's it. Haha. adding a single nop anywhere in the fastest code path fixes it
[00:01:23] <Grievar> remove the NOP and the I2C bus goes all screwy
[01:02:51] <creep> Grievar<< the error is probably between the keyboard and the chair
[01:04:49] <creep> but i had some errors similar with gcc before, it did segmentation fault with -o3 optimizations and certain addressing types
[01:05:16] <creep> slight change in code made it work again
[01:12:24] <Grievar> creep: er, the error is not with GCC it is either a glitch in how the chip works or it is something weird with the I2C bus
[01:12:53] <creep> that may be called a "user error"
[01:13:14] <Grievar> creep: what
[01:13:20] <Grievar> creep: Why are you so sure that I'm incompetent?
[01:13:29] <creep> calbe picking up noise, not waiting exxtra time, not terminating a transmission line properly...
[01:15:00] <creep> not sure what are you doing thou
[01:15:22] <Grievar> creep: so in other words you're talking out of your ass
[01:16:27] <creep> Grievar<< i'm not standing behind you and watching what you are doing, and that 2 lines of code does not tell much about the other things around
[01:16:46] <creep> i just did a guess
[01:17:12] <Grievar> creep: Right so you took the opportunity to insult me knowing absolutely nothing about the situation
[01:17:37] <creep> where do you see insult?
[01:18:00] <Grievar> [22:49:23] <creep> Grievar<< the error is probably between the keyboard and the chair
[01:18:02] <Grievar> [22:59:26] <creep> that may be called a "user error"
[01:21:52] <creep> i see so you are perfect, and the error is in the microcontroller
[01:22:01] <creep> why did you ask then?
[01:22:46] <Vutral> :(
[01:22:53] <Vutral> fucking atmega328p
[01:23:04] <Vutral> porting code from arm to avr is not funny
[01:23:21] <Grievar> creep: I didn't ask anything
[01:23:37] <Vutral> bla
[01:24:25] <Vutral> there are 2 possibilites
[01:24:26] <Vutral> but well
[01:24:28] <Vutral> i think the main problem is
[01:24:29] <Vutral> i dont know how the clock logic and these registers work exactly
[01:24:33] <Vutral> at least my spi clock doesnt stop running after transfer
[01:24:42] <Vutral> for some reason
[01:24:46] <Vutral> and i am unsure in how far usarts and spi might share resource
[01:24:47] <Vutral> s
[01:26:58] <creep> they used to be partially shared... so you can use one of them
[01:27:31] <creep> why have both in same time ?
[01:27:55] <Vutral> well
[01:28:04] <Vutral> because i need to communicate with spi ^^
[01:28:09] <Vutral> and with uart
[01:28:41] <Vutral> so i guess you suggest adding buffering ?
[01:29:02] <Vutral> the other thing is then
[01:29:18] <Vutral> in which state the spi peripherial falls after disabling
[01:29:59] <Vutral> i guess a possible explaination for my strange spi clock is then the usart/uart generates a clock
[01:29:59] <Vutral> possibly
[01:30:33] <Vutral> is there is somethign shared
[01:30:44] <Vutral> for what i got no charts etc.
[01:30:49] <Vutral> and no docs
[01:31:04] <Vutral> also the datasheets where unclear
[01:31:25] <Vutral> they suggest at least you got different peripherials
[01:31:28] <Vutral> where it shouldnt matter
[01:40:13] <creep> you have to switch between them anyway...
[01:40:26] <creep> just use a buffer in ram then
[01:41:47] <creep> i remember reading somewhere only one can be used at a time
[01:41:58] <creep> but isn't that clear in the block diagram ?
[01:42:07] <creep> it should be
[01:42:26] <Vutral> yeah
[01:42:29] <Vutral> it should
[01:43:04] <Vutral> well the logic analyzer at least looks like something is horribly wrong
[01:43:14] <Vutral> ^^
[01:44:32] <Vutral> but as i said the code comes from an arm or was written for one
[01:44:43] <Vutral> there is was very good documented which peripherials are unique ^^
[01:46:13] <creep> but if they share the same timer, then how would you expect htem to work in parallel?
[01:46:31] <Vutral> hm
[01:46:35] <Vutral> i dont know if they share the same timer
[01:46:40] <creep> i could think of this as a reason
[01:46:43] <Vutral> they use different Ăpins
[01:46:50] <Vutral> the block diagram dont tell me they would
[01:47:37] <creep> but the thing is, you have a single thread and even if you appear to do something in parallel you are just switching between them.
[01:47:56] <Vutral> eh
[01:48:07] <Vutral> well i dont disable the peripherials
[01:48:13] <Vutral> for this buffering
[01:48:23] <creep> an interrupt stops the executing code and runs, then the code running resumes after interrupt finishes
[01:48:24] <Vutral> i have the buffer to allow mixing the code still a bit
[01:48:40] <Vutral> yeah
[01:48:49] <Vutral> but in an interrupt you shouldnt work with peripherials anyway
[01:48:53] <Vutral> lol assume on an x86
[01:49:04] <Vutral> you would play on your soundcard on network interruĂpts
[01:49:06] <Vutral> ^^
[01:49:41] <Vutral> as long as you dont have shared resources it doesnt matter
[01:49:56] <Vutral> but still
[01:50:05] <Vutral> its logical if you enable another device in an interrupt
[01:50:08] <Vutral> you might cause another
[01:50:44] <Vutral> i got functions for shutting down spi
[01:50:47] <Vutral> after each transfer
[01:50:56] <Vutral> i guess i will add some logic
[01:51:08] <Vutral> to ensure spi enable shuts uart down
[01:51:12] <Vutral> and the other wy round
[01:51:34] <creep> try interrupting while in an interrupt
[01:51:35] <creep> ;<
[01:51:50] <Vutral> you can do that
[01:51:50] <Vutral> if you handle it
[01:51:53] <Vutral> properply
[01:51:56] <Vutral> well if its nmi
[01:51:58] <Vutral> you are doomed ^^
[01:52:10] <Vutral> then you need to guarantee atomicity
[01:52:20] <creep> implement in software.
[01:52:39] <creep> you can control io pins, and read them, it will be just slower
[01:59:47] <Vutral> hm
[02:01:37] <creep> they can do software usb using a 12MHz quartz
[02:02:03] <creep> data rate up to 1.5Mbps
[02:06:54] <Vutral> lol
[02:07:00] <Vutral> well since i guess
[02:07:07] <Vutral> i dont do anything in parallel in ideal case
[02:07:22] <Vutral> i will try what happens if i just disable the other peripherail when enabling the other etc.
[02:31:25] <creep> that should work
[02:31:38] <Vutral> should
[02:31:46] <Vutral> i studying the PRR right now
[02:32:12] <creep> but if you have low speed you can do it in software
[02:32:31] <Vutral> well
[02:32:37] <creep> or enable one and code the other
[02:32:52] <creep> clock and data is not hard to do
[02:32:56] <Vutral> why should i prefer bitbanging
[02:32:58] <Vutral> i mean
[02:33:07] <Vutral> if the peripherial works
[02:35:17] <Vutral> annoying ^^
[02:35:38] <Vutral> • Bit 1 – PRUSART0: Power Reduction USART0
[02:35:39] <Vutral> Writing a logic one to this bit shuts down the USART by stopping the clock to the module. When
[02:35:43] <Vutral> waking up the USART again, the USART should be re initialized to ensure proper operation.
[02:35:49] <Vutral> *g*
[02:36:05] <Vutral> well i set them to zero
[02:36:10] <creep> how do you like this?
http://en.wikipedia.org/wiki/File:Symmetrical_5-set_Venn_diagram.svg
[02:36:35] <Vutral> whats that
[02:37:54] <Vutral> know what sucks
[02:38:02] <Vutral> that i dont have small schmitt trigger gates
[02:38:08] <Vutral> i could need one
[02:40:35] <creep> cd4093
[02:40:47] <creep> 40106
[02:41:08] <Vutral> well
[02:41:12] <creep> 74hc14
[02:41:19] <Vutral> i got some pure schmitttriggers here
[02:41:28] <Vutral> from 74 series
[02:41:30] <Vutral> but well
[02:41:47] <Vutral> since it doesnt make sense to put them far apart from the device
[02:41:59] <creep> 74hc14 used to be on some motherboards, and stuff
[02:42:32] <creep> or just hct ( that is 5V +-0.5V )
[02:45:33] <Vutral> i got a list
[02:45:36] <Vutral> hm
[02:45:37] <Vutral> the are useful
[02:45:43] <Vutral> i dont have to detach the programmer ^^
[02:46:09] <Vutral> i just abuse the reset signal ^^
[03:00:56] <sabesto> are the prices randomized?
http://store.atmel.com/CBC.aspx?q=c:100112
[03:01:16] <sabesto> or is it because the MKII is going out of production?
[03:10:23] <creep> ask for a free sample
[03:45:22] <sabesto> creep: i wasnt looking to buy, i was just checking the price
[05:09:16] <Vutral> hm
[05:09:21] <Vutral> what about polling for edges
[05:09:23] <Vutral> on a pin
[05:09:25] <Vutral> in software
[05:09:27] <Vutral> creep: ?
[05:09:40] <Vutral> instead of interrupts
[05:10:04] <Vutral> since i want to count edges
[05:14:40] <jacekowski> ?
[05:14:45] <jacekowski> you could do that
[05:17:09] <Vutral> any suggestions ?
[05:17:41] <Vutral> something like reading the pin and counting the changes or anything more?
[05:18:11] <jacekowski> i would just use a shmitt trigger and counter
[05:18:11] <Vutral> i can let it run at full speed i guess
[05:18:33] <jacekowski> 7490 or something
[05:18:47] <Vutral> ^^
[05:19:11] <Vutral> i dont think i want to integrate more digital parts
[05:19:38] <Vutral> isolated supply isolated digital signals
[05:19:41] <Vutral> that would just introduce more noise
[05:20:35] <Vutral> they should sell optocouplers with integrated schmittrigger
[05:22:19] <inductiveload> Vutral: which part?
[05:22:27] <inductiveload> avr part, i mean
[05:22:34] <Vutral> ad7714
[05:22:54] <Vutral> atmega328p not best combination
[05:23:02] <Vutral> but it guess it will work
[05:23:17] <Vutral> it just collects the data and puts it on a differential link
[05:25:19] <inductiveload> can you use the 16 bit timer to count edges?
[05:25:36] <Vutral> uhm
[05:25:54] <Vutral> well i know the device flashes a pin
[05:26:09] <Vutral> once per cycle while its more or less deselected
[05:26:43] <Vutral> so if i just count the edges i know how long i should wait for keeping in the specs for it
[05:27:10] <Vutral> i thought about using the pin interrupts but hm
[05:27:12] <Vutral> well
[05:27:18] <Vutral> that doesnt work till now
[05:27:27] <Vutral> and since i know when i care about it
[05:28:17] <inductiveload> well, you can use pin T1 as a clock for the timer, and so that will increment whenever the source pulses (you can set rising or falling as the trigger)
[05:28:35] <inductiveload> then you can read the T1 value out to get the number of cycles
[05:28:48] <Vutral> hm
[05:29:35] <Vutral> at least that could give a relation between the frequencies of the devices
[05:48:48] <Vutral> hm
[05:48:53] <Vutral> clock needs to idle high
[05:48:59] <Vutral> but i wonder
[05:49:09] <Vutral> can it be when reenabling the spi peripherial
[05:49:12] <Vutral> it goes low ?
[05:49:13] <Vutral> *g*
[05:49:21] <Vutral> creating spurious clock
[08:40:25] <Malinuss> so I'm looking at this:
http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html So will simply doing something like wdt_enable(WDTO_1S); _delay_ms(5000); wdt_disable(); reset the device, or will it just trigger the interrupt by default?
[09:32:17] <iSaleK> What does this error mean and how can I fix it? Error attempt to use poisoned "SIG_USART0_UDRE"
[09:34:49] <discorpia> iSaleK: i believe poison is used when destructively flagging a feature as deprecated
[09:34:53] <discorpia> to prevent usage
[09:36:32] <iSaleK> So I guess I need to change all the lines in my uart.h from SIGNAL(SIG_USART0_UDRE) to ISR(USART0_UDRE_vect) ? Right?
[09:37:40] <discorpia> that sounds about right
[09:37:43] <discorpia> not sure on the specifics
[09:38:35] <iSaleK> Ok, It's wierd since that code was compiling ok with previous version of Atmel Studio :)
[10:56:26] <RikusW> lets start an OS war
http://www.shamusyoung.com/twentysidedtale/?p=18309 :-P
[11:37:36] <Malinuss> eh could someone help me with setting up the WDT, to not fuck me over and reset every time? I follow the procedure in the datasheet, but every time I end up with a reset instead of simply triggering a intterupt...
[11:39:55] <r00t^home> reset is just another interrupt, after all
[11:44:20] <Malinuss> r00t^home, yeah but I set it up, so it should only interrupt on overflow, neverless it always resets...
[11:44:51] <Malinuss> Action on Time-out "Interrupt" - it resets anyway, EVERY TIME... sigh
[11:48:13] <Malinuss> r00t^home, you have a min. to help me ?
[11:49:21] <r00t^home> isn't that the point of a watchdog anyway?
[11:51:46] <OndraSter_> <r00t^home> reset is just another interrupt, after all
[11:51:47] <OndraSter_> not really
[11:51:47] <OndraSter_> reset resets all the registers
[11:51:47] <OndraSter_> interrupt does not
[11:52:04] <Malinuss> r00t^home, no - it could be use to wake up your avr from sleep
[11:52:16] <Malinuss> r00t^home, or anything else for that matter - use it as an extra timer!
[11:52:28] <Malinuss> reset is just something it also can do
[11:53:18] <Malinuss> OndraSter_, ehh any idea why it does that too me though :)? I think I read those 4 pages on the datasheet 10 times now ;D
http://pastebin.com/8vS9ihSf
[12:15:22] <Malinuss> >pleas respond
[12:20:53] <creep> h
[12:21:58] <r00t^home> Malinuss: as you can see, i'm not the best to help really...
[12:22:10] <Malinuss> hehe ;D
[12:22:33] <r00t^home> i'd have to look at the datasheet myself... would also help you if you mentioned which chip you are using...
[12:23:26] <OndraSter_> this is how they teach thread synchronization with semaphores at our school:
http://sphotos-f.ak.fbcdn.net/hphotos-ak-ash4/482195_4886192431587_269170399_n.jpg
[12:25:18] <r00t^home> :D
[12:25:32] <r00t^home> what software is that?
[12:25:50] <OndraSter_> duh
[12:25:56] <OndraSter_> you do not know OpenTTD?
[12:26:00] <OndraSter_> the best game ever?
[12:26:04] <OndraSter_> multiplayer game
[12:26:14] <r00t^home> no
[12:26:50] <OndraSter_> dude
[12:27:00] <OndraSter_> what did you play in '93
[12:27:05] <OndraSter_> or whenever it came out?
[12:27:42] <Malinuss> r00t^home, its the attiny85
http://www.atmel.com/Images/doc2586.pdf page 45-47
[12:31:06] <r00t^home> 93...? i'd guess on a '64 or an NES...
[12:31:27] <OndraSter_> eh?
[12:31:30] <OndraSter_> this came out for DOS
[12:31:44] <OndraSter_> not long before Win95 came out
[12:32:22] <OndraSter_> '94 for TT in the UK, '95 for TTD in the UK
[12:33:26] <r00t^home> i'm pretty sure i did not have (my own) PC back then
[12:34:01] <OndraSter_> I was born in '92...
[12:35:05] <r00t^home> my parents bought our first PC in 95'
[12:35:32] <OndraSter_> we had 386 as the oldest one what I remember
[12:35:37] <OndraSter_> supposedly we had 286 before that too
[12:35:42] <OndraSter_> and 486 after it too
[12:35:51] <r00t^home> (an only to annoy us kids left it in it's packaging for a couple weeks, and even then we were very rarely allowed to use it)
[12:35:57] <OndraSter_> but I remember only 386, Celeron, P III..
[12:36:41] <OndraSter_> I still have got the 386 motherboard here
[12:36:43] <OndraSter_> with 40MB HDD :)
[12:36:47] <OndraSter_> or was it 80MB...
[12:36:54] <OndraSter_> it was 3.5" width but twice as high
[12:37:16] <r00t^home> i also still have the board of that first PC... and a couple 486 and 386 ones and whatever
[12:37:56] <r00t^home> i also have two full-height 5.25'' HDs, they are 200 and 300 megabyte scsi iirc
[12:38:13] <OndraSter_> I have got two 5.25" .. 20MB
[12:38:15] <OndraSter_> mfm
[12:38:42] <r00t^home> mfm is kinda useless, can't connect it to a modern pc anymore
[12:38:50] <OndraSter_> nope
[12:39:00] <OndraSter_> but I have got few controllers
[12:39:03] <OndraSter_> the HDDs are dead
[12:39:08] <OndraSter_> they spin, but that's all they do
[12:39:15] <r00t^home> poor hdds :(
[12:39:19] <OndraSter_> yeah
[12:39:22] <OndraSter_> trash found
[12:46:09] <abcminiuser> So, anyone install the AS6.1 beta yet?
[12:47:07] <Steffanx> No guinea pigs here ..
[12:51:46] <abcminiuser> :(
[12:51:57] <abcminiuser> It's actually much more stable
[12:52:17] <Steffanx> and it still doesnt run on os x :D
[12:53:12] <Malinuss> abcminiuser, would it be possible to give a compiler warning when compiling a code that would cause a jump to a invalid vector? I didn't even know a jump to 0x00 would be a result of that!!!
[12:53:33] <Malinuss> abcminiuser, I will install it soon, I want to play around with LUFA :)
[12:55:15] <abcminiuser> Malinuss, you mean work out if you enable an interrupt that has no handler?
[12:55:31] <Malinuss> abcminiuser, yeah, it should at least give a compiler warning :)
[12:55:38] <abcminiuser> That's essentially a Halting Problem, but you can hook the "unhandled vector" and add some code there
[12:55:55] <abcminiuser> ISR(BADISR_vect) { /* Code */ }
[12:56:20] <abcminiuser> So if an unhandled ISR fires your BADISR handler is run
[12:58:03] <Malinuss> abcminiuser, I see thanks...
[13:05:45] <OndraSter_> oo abcminiuser
[13:05:47] <OndraSter_> 'sup in the north?
[13:07:01] <abcminiuser> Heyo
[13:07:14] <abcminiuser> Digging through my inbox tonight, I guess it's time I answered some mail :(
[13:07:32] <abcminiuser> FYI I get one email for every freaking LUFA AS6.1 extension download
[13:07:41] <abcminiuser> I have to set up a mail filter for it...
[13:08:18] <Steffanx> I bet you only received 2 emails yet :P
[13:08:24] <abcminiuser> Aww sadface
[13:08:27] <abcminiuser> 100
[13:08:29] <abcminiuser> ish
[13:09:20] <Steffanx> why you receive them and not some marketing guy?
[13:11:41] <Malinuss> abcminiuser, haha just wait till it's out of beta and it updates officially.. If you got 100 mails now, you will get 1000s ;D
[13:11:45] <abcminiuser> Since I uploaded the extension
[13:12:05] <abcminiuser> Malinuss, I think I'll change the owner email address to Steffanx's...
[13:12:21] <Steffanx> Go go
[13:12:27] <Steffanx> do it
[13:13:16] <Roklobsta> why is it still in beta?
[13:13:19] <Roklobsta> it's been years
[13:13:37] <Steffanx> this is 6.1 ..
[13:14:23] <Roklobsta> oh misread, i meant LUFA in general
[13:15:36] <Roklobsta> atmel is making it hard for mcuzone with all these update
[13:15:45] <abcminiuser> Roklobsta, why so?
[13:16:22] <Roklobsta> because each time an update comes i have to wait about 6 weeks for a firmware update from them for the mk-IICN JTAG unit
[13:17:35] <Roklobsta> that said, is 6.0SP2 terribly different to 6.1?
[13:19:49] <OndraSter_> mk-IICN has no purpose anymore
[13:19:57] <OndraSter_> JTAGICE3 is $99
[13:20:43] <Roklobsta> true still, i have one
[13:20:53] <Roklobsta> and it's very good
[13:21:38] <abcminiuser> The tool system backend was completely refactored in AS6.1
[13:21:51] <abcminiuser> That said, it was for stability reasons, so the protocols and all that should be the same
[13:22:05] <abcminiuser> But OndraSter_ is right, get a much faster, much more reliable ICE3
[13:22:18] <abcminiuser> And freaking upgrade, there's a bajillion bug fixes in AS6.1
[13:22:52] <Roklobsta> not a gajillion?
[13:23:14] <OndraSter_> no
[13:23:18] <OndraSter_> exactly a bajilion
[13:24:30] <Roklobsta> anyway, i also have a dragoon and it seems just as fast as the mk-iiCN. How much faster is an ICE?
[13:26:44] <Roklobsta> how much faster can things get, really?
[13:27:06] <OndraSter_> faster than light :)
[13:28:15] <Roklobsta> i use avrdude with an FTDI232H and it's faster
[13:28:45] <Roklobsta> using my precision Perception Timing System.
[13:29:32] <abcminiuser> Roklobsta, you're kidding, right?
[13:29:39] <abcminiuser> The Dragon is the slowest tool we have
[13:29:59] <Roklobsta> I said I use PTS. It's not accurate
[13:30:14] <Roklobsta> and is affected by beer
[13:34:14] <OndraSter_> abcminiuser, Dragon does not seem that slow to me
[13:34:31] <OndraSter_> 8kB code is uploaded immediatily
[13:36:10] <abcminiuser> Ah, call me when you're dealing with debugging of 64KB and above
[13:36:15] <OndraSter_> :)
[13:36:17] <abcminiuser> It's damned near instant
[13:36:28] <OndraSter_> on jtagice?
[13:36:34] <abcminiuser> ICE3
[13:36:39] <OndraSter_> of course
[13:36:53] <OndraSter_> how come that ice3 is $99 and ice2 is more? :D
[13:40:28] <Roklobsta> is dragon being slow above 64kb a technical limit or a managment limit?
[13:43:48] <abcminiuser> OndraSter_, because we really, really don't want you to buy the ICE2
[13:43:57] <OndraSter_> lol
[13:44:02] <OndraSter_> not even sell out old stock?
[13:44:04] <abcminiuser> The IC3 is faster, much much cheaper to manufacture and maintain
[13:44:12] <OndraSter_> of course
[13:44:22] <abcminiuser> We keep the IC2 around with old stock for those that need it for some reason
[13:44:31] <OndraSter_> oh ok
[13:44:35] <abcminiuser> But since it costs so much more to produce the consumer price is higher
[13:44:42] <OndraSter_> wow
[13:44:54] <OndraSter_> I thought the ICE3 was much more expensive to make.. you know, AVR32
[13:44:59] <Roklobsta> made by trolls above the artic circle
[13:45:00] <abcminiuser> Roklobsta, it's a technical one - the design is, ah, cobbled together somewhat
[13:45:05] <abcminiuser> OndraSter_, AHAHAHAHA
[13:45:06] <abcminiuser> No.
[13:45:14] <OndraSter_> heh
[13:45:27] <abcminiuser> One chip, a few discretes and a small plastic enclosure is cheap
[13:45:29] <OndraSter_> I can exactly picture that smile
[13:45:32] <OndraSter_> oh
[13:45:41] <OndraSter_> and what is in ice2?
[13:45:42] <Roklobsta> finally a use for the AVR32
[13:45:53] <OndraSter_> lol
[13:46:09] <abcminiuser> A big thick translucent plastic, throughhole parts, two AVRs, external USB chip from another company and level converters costs more to make
[13:46:18] <OndraSter_> holy crpa
[13:46:20] <OndraSter_> crap
[13:46:31] <OndraSter_> I thought ice2 was some at90usb + buffer
[13:46:41] <abcminiuser> Nope, it's way way older than that
[13:46:42] <OndraSter_> something like avrice mkii with bigger chip
[13:46:53] <abcminiuser> The ICE3 is basically an ICE2 done correctly
[13:47:01] <abcminiuser> REALLY fast, cheap, simple
[13:47:06] <abcminiuser> No plastic ribbon cable
[13:47:07] <OndraSter_> :)
[13:48:21] <Roklobsta> what's stopping something like JTAG mode on an FTDI232H being used on AVRStudio? Are there trade secrets involved in programming an AVR?
[13:48:22] <abcminiuser> Also I wasn't done yet
[13:48:25] <abcminiuser> AHAHAHAHAHAHHA
[13:48:26] <Roklobsta> and dubugging?
[13:48:26] <abcminiuser> HAHAHA
[13:48:28] <abcminiuser> HA.
[13:48:30] <abcminiuser> Now I'm done
[13:48:34] <OndraSter_> lol abcminiuser
[13:48:43] <OndraSter_> Roklobsta, commands
[13:49:04] <abcminiuser> We publish JTAG programming commands in the datasheet
[13:49:06] <abcminiuser> But not debugging
[13:49:15] <Roklobsta> right
[13:49:27] <Roklobsta> it's odd no-one has sniffed it out yet then
[13:49:27] <abcminiuser> So you could make a JTAG programmer and fool AS6 into thinking it was a JTAG ICE3 or whatever
[13:49:30] <abcminiuser> But it wouldn't debug
[13:50:06] <OndraSter_> Roklobsta, such atxmega128a4u is cheaper than ft232h
[13:50:13] <OndraSter_> or is the 232h the cheap one?
[13:51:04] <Roklobsta> i just think it's the principle. OpenJTAG uses 232H and freidns just fine for ARM debugging.
[13:51:31] <OndraSter_> feel free to emulate ft232h in the xmega :)
[13:51:42] <Roklobsta> maybe atmel make their money from debuggers
[14:05:19] <Malinuss> anyone knows if the coorelation between power consumption, and the uC speed is linear? At least around the "normal" values (let's say 3-20mhz)? I can't really find a plot like that in the datasheet
[14:05:42] <Malinuss> wiht "uC speed", I simply mean the F_CPU
[14:07:37] <Posterdati> hi
[14:07:48] <Posterdati> is there a way to use stl on avr_gcc?
[14:11:21] <OndraSter_> Malinuss, you can not?
[14:11:22] <OndraSter_> http://clip2net.com/s/2SWq7
[14:11:23] <OndraSter_> ...
[14:12:41] <Malinuss> Why in the world would anyone want to run at lower frequencies then? That's not a way to save power....
[14:13:17] <OndraSter_> lol it is
[14:13:41] <OndraSter_> on 180mAh battery (if you are lucky!) you are glad for every mA less
[14:13:55] <OndraSter_> while doing nothing you disable every single peripheral to drop to nanoAmp range
[14:14:16] <OndraSter_> (and disable the core and flash controller and everything, keep just some wake up source - watchdog or int or whatever)
[14:14:51] <Malinuss> OndraSter_, it is not.... since it's linear - you normally just need to do x number of instructions, and then sleep... so the speed of the cpu won't matter for power consumption... the amount of power consumed will be the same!
[14:15:03] <OndraSter_> not really
[14:15:07] <OndraSter_> you have to sometimes wait for somethin
[14:15:07] <OndraSter_> g
[14:15:14] <OndraSter_> so you can either drop to sleep mode
[14:15:15] <OndraSter_> or not
[14:15:47] <OndraSter_> also bigger mA = beefier power supply. Battery can discharge much quicker if you do higher currents
[14:16:17] <Malinuss> ah I see, also in the setup you present it makes sense... thanks for clearing it up..
[14:16:35] <OndraSter_> when you don't see the reason != there is none
[14:16:53] <OndraSter_> for PCINT stuff you need to have IO clock running
[14:16:57] <OndraSter_> which is directly divided from core clock
[14:17:00] <OndraSter_> so you can not use sleep mode
[14:17:10] <OndraSter_> (at least on tiny13a if I read the datasheet correctly)
[14:20:31] <Malinuss> OndraSter_, you can use sleep mode, iirc the power down mode will only leav the watchdog left
[14:20:33] <OndraSter_> I said that PCINT requires IO peripheral clock
[14:20:33] <Malinuss> OndraSter_, in my setup it won't make much sense with lower frequency, because I just need x amount of cycles to execute each y time... so I just sleep, execute x cycles, and sleep again. but like you said, the battery discharges quicker at higher currents, I didn't think of that
[14:20:33] <OndraSter_> which runs off core's clock
[14:20:33] <OndraSter_> I actually tested that in an emulator
[14:20:33] <OndraSter_> and no, PCINT did not wake the core up because the clock was not running
[14:20:33] <Malinuss> OndraSter_, but the IO cllock sleeps in deep sleep mode, as do the core
[14:20:34] <OndraSter_> yes
[14:20:34] <OndraSter_> that is what you would want to use if you want to go down to nanoAmps
[14:23:00] <Malinuss> OndraSter_, ah so your point being, that if I need to use the PCINT to wake up the cpu while sleeping, at higher frequency, it would use more power.. I see.. You think the higher discharge rate with higher current is something I should worry about if I want optimal battery life?
[14:23:16] <OndraSter_> no, I am saying that you can not use PCINT when in deep sleep mode :)
[14:23:26] <OndraSter_> so you would not be able to use that
[14:24:07] <Malinuss> yeah exactly, so IF you wanted to use it to wake up with, it would be running very fast in that sleep mode - using more power ;D. I follow you :)
[14:24:24] <OndraSter_> ok
[14:24:34] <OndraSter_> I had to change the design to use the real INT0 pin
[15:47:37] <creep> h
[16:24:42] <creep> what's up ? everybody hacking something?
[16:25:55] <r00t^home> everybody's hacking YOU!
[16:26:41] <creep> oh okey
[16:43:48] <r00t^home> creep: and by "you" i don't mean your computer! we're into mind-hacking, ghost in the shell style!
[17:00:25] <r00t^home> i have today, hacked the pcb of a phone docking-station (=ftdi breakout) to connect a usb-a plug directly instead of a cable...
[17:02:40] <r00t^home> and i just installed a 35w discharge lamp in my fridge... the stock incandescent just doesn't cut it ;)
[17:03:03] <creep> ;/ you can use a 3W led
[17:03:17] <creep> just seal it air-tight
[17:06:13] <r00t^home> well, just for cleaning... it's so depressing trying to clean something when it's so dark you can't see the result
[17:06:58] <r00t^home> why would an led need to be sealed anyway?
[17:09:30] <creep> because leds dislike humidity
[17:09:48] <creep> they will rot away in your fridge
[17:10:22] <r00t^home> why? they are sealed in plastic anyway...
[17:10:35] <creep> the 5mm type will mostly only corrode at leads
[17:11:01] <r00t^home> yeah, the leads and solder might corrode... the LEDs themselves won't care
[17:11:09] <creep> well you can't clean the soft silicone on some high power leds for example
[17:11:24] <krphop> fridges are generally quite dry
[17:11:24] <creep> it is best to put a thin plexiglass or something before it
[17:12:07] <r00t^home> i don't think getting it tight would be worth the trouble
[17:12:12] <creep> by dry you mean wet right?
[17:12:28] <r00t^home> no
[17:12:51] <creep> every piece of humidity in your house will condense inside your fridge and turn into water
[17:13:00] <r00t^home> should install a humidity and thermo sensor in the fridge and monitor it with an #avr ;)
[17:13:01] <creep> ( if you open it )
[17:13:30] <creep> a fridge is basically a dehumidifier
[17:14:12] <krphop> yeah, which means, its dry inside...
[17:14:16] <creep> no
[17:14:28] <r00t^home> and then that water is collected and evaporated on the fridge's chiller...
[17:14:36] <creep> yes
[17:14:42] <r00t^home> just to avoid the effect ;)
[17:16:32] <creep> krphop<< the RH inside the fridge will be much higher than outside of it, but the absolute water content of the air will be much lower.
[17:16:50] <creep> because of the lower temperature
[17:19:34] <krphop> if RH is high in a fridge, why does food dry out more quickly in a fridge?
[17:19:48] <creep> does it ?
[17:20:19] <creep> i doubt food is heated from the inside in the fridge
[17:20:30] <krphop> it isn't, but the moisture is extracted
[17:20:49] <creep> while it is hot it evaporates more i'm sure
[17:22:30] <krphop> well, at least with my house humidity, the fridge RH is lower than ambiant
[17:23:00] <r00t^home> so you do have a humidity sensor in your fridge? ;)
[17:23:05] <krphop> yes
[17:23:07] <creep> ;>
[17:23:17] <creep> then it is inaccurate
[17:23:34] <krphop> i beg to differ
[17:23:52] <krphop> well it could be
[17:24:05] <krphop> but if EVERY humidity sensor i have is off by the same amount then sure
[17:24:29] <creep> it may only be bacause of the temperature difference
[17:25:00] <krphop> it is a RH sensor, not just straight humidity
[17:25:29] <creep> but a fridge is a dehumidifier, if the cooling side is colder than the inside air then water vapor condenses on it
[17:25:52] <krphop> yup
[17:26:25] <krphop> like how your freezer has ice buildup?
[17:28:24] <creep> it depends on what kind of fridge we are talking about ;/
[17:28:59] <creep> 5C will not freeze water
[17:39:08] <creep> hm, well evaporation also depends on pressure, and a deep freezer will create negative pressure after freezing air from outside inside
[17:39:19] <krphop> ah ok
[17:39:22] <creep> things might actually dry out faster.
[17:39:38] <krphop> like freezing bread
[17:39:49] <krphop> you can thaw and re-use, but its somewhat stale and dry
[17:39:54] <creep> i don't like that, baking fresh bread is best
[17:40:02] <krphop> heh
[17:40:10] <creep> and real bread
[17:40:28] <creep> they sell crap everywhere nowadays
[17:40:54] <creep> you know how this goes, the more weight, less materials needed the more profit
[17:42:31] <creep> if you wouldn't buy crap then they wouldn't try to manufacture it
[17:43:07] <creep> so consumers are responsible for food quality degradation, they do not require quality food
[17:43:55] <krphop> and then people blame the crappy food for them getting fat
[17:44:09] <creep> mcdonalds yeah
[17:44:22] <krphop> then you get states like New York that ban large soft drinks
[17:44:24] <creep> and not even that cheap
[17:44:48] <krphop> i want a LARGE soda damnit!
[17:44:58] <creep> hahaha i'd ban them all
[17:45:18] <creep> make junk food production a felony in the state
[17:45:51] <krphop> eft that
[17:47:27] <krphop> why should the government be able to tell me what i can and cannot eat?
[17:48:02] <creep> FDA does it all the time.
[17:48:28] <Casper> the FDA however goes too far me think
[17:48:52] <creep> and they let mcdonalds sell you synthetic food that has no energy content, and kills you slowly
[17:49:04] <Casper> creep: proof?
[17:49:49] <creep> well they test everything on rats and if rats don't die in 2 weeks from a dose it is safe for you, well approved, have a good appetite
[17:50:38] <Casper> that's rumor, not facts
[17:50:41] <creep> Casper<< take a look at the E numbering scheme somewhere on the internetz
[17:52:07] <creep> natural and harmless ingredients also have E numbers near the experimental chemicals
[17:52:21] <creep> mixed well
[17:54:22] <creep> hey sourcec0de hax0r
[17:55:56] <creep> Casper<< obviously i can't prove you that you will have certain type brain cancer eating mcdonalds hamburgers for 15 years
[17:56:44] <creep> long-term effects are unknown for most experimental food additive
[17:56:54] <Casper> "experimental"
[17:57:15] <Casper> you mean like aspartam?
[17:58:39] <creep> yes
[17:59:26] <creep> and E621 E631, MSG
[17:59:40] <creep> coloring agents
[17:59:54] <creep> there are some totally useless junk too
[18:00:12] <creep> making food more colorful at the cost of carcinogens
[18:00:16] <Casper> which is the world most studied chemical, that zero reliable source could point to any increase of health issue unless some insane quantity is consumed (like 10L of diet soda per day, for 30 years)
[18:00:57] <creep> MSG is just an addictive drug
[18:01:04] <creep> made perfectly legal
[18:02:18] <creep> i have nothing more to say about this, consume whatever you want
[18:22:27] <[z_z]> If I'm trying to use a JTAG interface on an atmel avr32 and I accidentally feed TDI 5v when the chip is powered with 3.3v I won't damage anything right? I mean the chip is 5v compatible so...
[18:23:11] <creep> and what does the regulator say about this? ( backfeeding it )
[18:32:49] <creep> oh and while you power the device from 3.3V the internal clamp diodes will clamp if you apply higher voltage
[18:33:04] <creep> may cause self-destruct, latch up
[18:33:26] <[z_z]> right. thats what i was thinking... the clamping anyway.
[18:34:04] <creep> a series resistor might be enough to protect it, dpeneding on circuit
[18:34:23] <creep> this will degrade high frequency performance though
[18:42:52] <creep> [z_z]<< a 100 ohm resistor in series with the port would do for you
[18:43:18] <[z_z]> thanks creep
[18:43:22] <creep> np
[19:40:09] <[z_z]> hmm. Just had an idea. I can use the pin change interrupt and the adc on the same pin right?
[19:40:24] <Horologium> probably.
[19:42:15] <Tom_itx> adc setup time is slow
[19:45:14] <Malinuss> [z_z], like Tom_itx said... also I'm wondering when that would be practical :)
[19:46:32] <creep> i doubt pin change interrupt works as analog
[19:47:04] <creep> but there is a big chance a 10 bit adc input value will change
[19:50:38] <Malinuss> creep, well if he is doing something like - turning the adc on when the pin changes from low to high, because he knows that it's always around VCC, then it could make sense
[19:53:06] <Tom_itx> not sure you can use 2 alternate functions at once
[19:53:18] <Tom_itx> adc or pinchange but not both
[19:53:36] <Horologium> would have to look at how it is wired up.
[19:54:03] <creep> or just fire it up
[19:54:22] <Horologium> fire up a chip and test it.
[20:16:06] <Valen> http://www.engadget.com/2013/02/27/freescale-worlds-smallest-arm-powered-microcontroller/
[20:16:14] <Valen> 1.9 x 2.00 x 0.56 millimeter
[20:16:23] <Valen> A 48 MHz ARM Cortex-M0+
[20:16:28] <Valen> 32KB of flash memory and 4KB of RAM
[20:17:38] <Valen> 75 cents (USD) in 100,000-unit quantities
[20:17:53] <Valen> so that'll be what $50 at digikey?
[20:19:04] <creep> yes
[20:19:56] <Valen> handy size though
[20:20:12] <Valen> I just like how much more powerfull than the apollo computers that is
[20:20:31] <Valen> and if you got it jammed under a fingernail it would only be mildly uncomfertble
[20:20:36] <creep> and it would live like 5 minutes in space :)
[20:20:52] <creep> due to radiation damage
[20:20:54] <Valen> eh, mebe, depends on the feature size somewhat
[20:20:59] <Valen> put 4 of em in
[20:21:08] <Valen> plenty of stuff in space isnt "rad hard"
[20:21:08] <creep> that'd be 20 minutes only
[20:21:24] <creep> smaller transistors need less damage to die
[20:21:27] <creep> :P
[20:21:42] <Valen> thats the thing, theres no mention of what lithography thats on
[20:21:56] <Valen> i think 32nm or more is generally ok
[20:22:16] <Valen> i mean sure it may have lifetime issues but your talking months at least
[20:23:26] <[z_z]> erm. shield it?
[20:24:15] <Valen> you can shield from lightweight stuff
[20:24:31] <Valen> but a high energy cosmic ray will punch through meters of lead
[20:24:59] <Valen> but anyway I wasn't saying to specifically use that in space
[20:25:19] <Valen> i was more pointing out the crap things are awesome now, why cant we do anything cool?
[20:30:54] <Horologium> lets build a rocket and put a man on the moon.
[20:30:57] <Vutral> bla
[20:30:59] <Vutral> fucking shit
[20:31:07] <Vutral> i want debugwire
[20:31:08] <Vutral> lol
[21:02:38] <creep> let's make human regrow a hand or other body part
[21:02:51] <creep> Valen<< cool enough?
[21:03:54] <Tom_itx> don't like what you got? grow it longer
[21:04:34] <creep> i believe that'd require DNA manipulation
[21:04:49] <Tom_itx> not out of reach
[21:04:53] <creep> you can have wings then
[21:05:14] <Valen> I think they need to get some really good comp-sci people into genetics
[21:05:35] <Valen> I reckon all the biologists thaught DNA would be like a blueprint
[21:05:42] <Valen> its not, its more like those 64k demos
[21:05:52] <Valen> everything is proceduraly generated
[21:05:54] <creep> i'd want a 2-3m spider instead of a dog outside on a chain
[21:06:33] <Valen> Also (and i'm starting to be proven right on this) cells do stuff based on what their neighbours doe
[21:06:34] <Valen> do
[21:07:03] <creep> every living cell contains your DNA, and the cell knows what it should do
[21:07:10] <Valen> so if you wanted a bigger wang you need to a) cut it off b) re-grow it and c) subtly change its starting conditions
[21:07:45] <Valen> all your cells contain all your dna, yet the ones on the inside of a blood vessel are totally different to the ones in the middle
[21:10:21] <Valen> and recently they are doing stuff with printing up new blood vessels they are finding that just sitting cells of the rightish type doesn't work
[21:11:04] <Valen> they found that putting pulsing blood in the new tube actually turns it into a real blood vessel, the cells all properly differentiate and start working right
[21:24:46] <Vutral> lol
[21:24:56] <creep> how do you like this?
http://en.wikipedia.org/wiki/File:Symmetrical_5-set_Venn_diagram.svg
[22:10:48] <rue_house> scarry
[22:11:13] <rue_house> now make it 3d and see how many bits you can stuff in
