Back
[05:40:09] <OndraSter> http://www.youtube.com/watch?v=gPKZSuXAVMU
[10:04:03] <amee2k> http://mintel-automation.homepage.t-online.de/Bilder/FTG/FTG_870N-12p_bl_500.jpg << how much current can you put on these PG distribution rail things like on that pic??
[10:05:17] <amee2k> these are really cheap, and i'm looking for something for low-voltage distribution that would be suitable for 10A continuous / 25A at low duty (1-2min max at a time)
[10:05:46] <OndraSter> how big is it in RL?
[10:06:18] <amee2k> the blue base fits on a 35mm DIN rail
[10:06:44] <amee2k> so something around 6-7cm or just under 3" long
[10:08:33] <OndraSter> sorry, gotta run
[10:08:33] <OndraSter> bb
[10:08:52] <amee2k> OndraSter: text says the terminals fit 10sqmm (~7 AWG) single-stranded each
[10:09:40] <amee2k> thinking about using it with 2.5 or 3.5 single stranded, and maybe 10 multistranded for the main feeds
[12:38:32] <kobsu> poll: .cc or .cpp?
[12:44:22] <theos> .asm
[12:45:16] <specing> .s
[12:46:41] <kobsu> ok maybe I'll go with the .S
[12:53:41] <specing> kobsu: chip?
[12:54:08] <kobsu> uc3a1, but does it matter?
[12:54:28] <specing> yeah
[12:54:37] <specing> uc3 are 32 bit, right
[12:54:39] <specing> ?
[12:54:42] <kobsu> yes
[12:54:52] <specing> I'd say go with C++
[12:56:50] <karlp> c--
[12:57:44] <kobsu> specing: yep and i was curios of people's preferences for the C++ suffix :)
[12:59:20] <karlp> heh, c-- has only 1 mailing list post in 2 years
[13:02:20] <specing> Obviously one cant go worse than C
[13:02:25] <specing> only better
[13:03:10] <specing> but better might have some trade-offs that are meaningless on powerfull computers while being quite meaningfull on tiny devices
[13:04:05] <specing> generally, if you are obsessed with looking at the asm output, go with C
[13:04:12] <specing> otherwise there are better ways to waste your time
[13:04:14] <specing> :D
[15:43:14] <cehteh> is the voltage drop on avr outputs relative constant or varies between batches? anyone experience with that?
[15:43:35] <OndraSter> voltage drop?
[15:44:06] <cehteh> output set to high is slightly lower than Vcc right?
[15:44:13] <OndraSter> depends on the load :)
[15:44:34] <cehteh> assume no significant load and same load
[15:44:47] <OndraSter> the outputs are very close to vcc
[15:45:04] <cehteh> i am just interested if its reliable or varies between chips/batches
[15:45:30] <cehteh> thanks
[15:45:40] <OndraSter> check datasheets
[15:45:49] <OndraSter> but should be the same or better on newer chips
[15:45:52] <cehteh> yes i remember it was mentioned there
[15:46:01] <OndraSter> AVR can have fairly high loads on its pins
[15:46:04] <OndraSter> compared to eg ARM
[15:46:44] <cehteh> yes i know, well load is not the problem one output only drives one input or maybe little more and maybe with a 2k pullup/pulldown
[15:47:05] <cehteh> ah and a led ... duh forgot about that :)
[15:47:24] <cehteh> 17mA LED .. thats no problem
[15:48:13] * cehteh is lazy and put some of these 'leds with resistors for 5V included' on the list
[15:48:31] <OndraSter> that's some serious lazyness lol
[15:48:33] <OndraSter> laziness?
[15:49:17] <cehteh> well one digital out drives a analog in .. saving some pins for a configuration input through a trimmer
[15:50:03] <cehteh> but in some cases i want to override the digital out with a switch pulling it up/down
[15:50:22] <cehteh> and the value seen at the ADC should not significantly differ
[18:32:49] <iSaleK> Hey folks, just a quick question that is not that much about avr... When multiplexing several sevensegment displays with MCU, do I have to add a resistor for each sevensegment display or is it enough to add just one per a,b,c,d,e,f,g,h lines?
[19:09:12] <Tom_itx> iSaleK, you may need a driver on them if there are several.
[19:09:39] <iSaleK> I have 3 sevensegmend displays
[19:10:02] <Tom_itx> how much current on each segment x 3?
[19:10:35] <iSaleK> I'm not sure...
[19:10:36] <Tom_itx> the pin may not drive them
[19:11:23] <iSaleK> But I've tested it on breadboard and it's working with resistor for each sevensegment but i'm not sure if it will work without resistor and I've already dissambled my breadboard... :\
[19:11:23] <cehteh> if you want to run at full speed clock, is it recommended to disable the CLKDIV8 fuse, or set the prescaler at startup?
[19:11:46] <Tom_itx> sorta does the same thing
[19:11:50] <iSaleK> cehteh: I've red about that in some tutorial, thank you
[19:11:52] <Tom_itx> read about ckdiv8
[19:12:18] <iSaleK> Tom_itx: Ok, thx!
[19:12:27] <cehteh> sure the effects are the same, thats whyi ask .. do some programmers have problems with full speed clock for example?
[19:13:04] <cehteh> mhm startup at clkdiv/8 will be slower until one unleash it
[19:13:10] <Tom_itx> that has nothing to do with the programming clock
[19:15:03] <cehteh> well i am asking if there are more subtle differences i am not aware about.
[19:15:49] <Tom_itx> i don't thinks o
[19:15:54] <Tom_itx> i don't think so
[19:15:55] <cehteh> stabilization of the 1.1V reference comes in mind, that takes a fixed amount of time and not clock cycles
[19:16:44] <Tom_itx> use startup delay for that
[19:17:24] <cehteh> which you have to calculate differently depending on the CLKDIV8 fuse if you want to be up as fast as possible
[19:17:30] <cehteh> well doesnt matter here
[19:18:06] <cehteh> its connected to a power supply and to be sure i just enable the BOD, then its only started when everything is sane
[19:18:18] <cehteh> lets see :)
[19:18:50] <cehteh> another question: is there some way to preserve a single bit of information over a reset without writing to eeprom?
[19:18:58] <OndraSter> SRAM
[19:19:17] <cehteh> ram is not reset?
[19:19:19] <OndraSter> not sure how about R0-R31 registers
[19:19:20] <OndraSter> no
[19:19:27] <cehteh> cool
[19:19:29] <OndraSter> unless it cuts its power
[19:20:15] <OndraSter> I remember always doing upon startup (with ASM code) always resetting all R0-R31 + whole SRAM
[19:20:31] <cehteh> the case is that i have a timer 32bit in sram plus 8 bit timer register ... i dont want to handle overflows everywhere i use it, so i just doing a reset when the 32bit overflows
[19:20:48] <cehteh> but i have really only 1 bit state to carry over, guess thats manageable
[19:21:01] <OndraSter> BUT
[19:21:05] <OndraSter> check it whether it really works!
[19:21:10] <cehteh> will do
[19:21:12] <OndraSter> there is always rubbish in the RAM after powerup
[19:21:23] <cehteh> thats not a problem
[19:21:46] <cehteh> one can figure the reset reason out
[19:22:00] <OndraSter> ye
[19:22:03] <OndraSter> BUT
[19:22:07] <OndraSter> if you are doing C code
[19:22:12] <cehteh> i do :P
[19:22:13] <OndraSter> the variables in memory ARE reset
[19:22:35] <cehteh> thanks to remind me
[19:22:49] <OndraSter> yaw
[19:23:14] <cehteh> static variables are allocated in order or does gcc some reordering?
[19:23:24] <cehteh> (alignment aside)
[19:23:54] <cehteh> then i can just put that bit behind the last var and read it with asm
[19:23:59] <OndraSter> no idea
[19:24:19] <cehteh> or put it on the stack below the initial stackpointer
[19:24:34] <cehteh> stack wont be cleared thats waste of time
[19:25:05] <cehteh> anyways, thanks, i'll find some way
[19:27:58] <w|zzy> is Dean still over in norway working for Atmel fulltime?
[19:29:28] <OndraSter> sure
[19:53:12] <CapnKernel> OndraSter: Would be interesting to get a bunch of RAM chips and test their initial contents every day over a year.
[19:53:31] <OndraSter> :)
[19:53:34] <OndraSter> SRAMs of course
[19:53:38] <OndraSter> DRAMs are all FFed
[19:53:57] <CapnKernel> Sure RAM is undefined, but perhaps particular bits in a particular chip are always on, or always off
[19:54:30] <OndraSter> :)
[19:54:49] <OndraSter> http://www.windowsphone.com/en-US/apps/f772fc86-96dc-4093-b944-dde8fcd4e8f0?cmpid=TWP_zombiesrun_MKTPL
[19:54:53] <OndraSter> (has iOS and Android versions as well)
[19:55:00] <OndraSter> looks like "great" jog motivation :D
[19:55:03] <CapnKernel> I know AVRs have EEPROM, which removes the need, but in a design without EEPROM, if you found that the bits in a particular RAM chip always had the same starting value, you could hash it to make a device serial number
[19:55:22] <OndraSter> newer AVRs have OTP ROM :)
[19:55:27] <OndraSter> or burnt in serial already even
[19:55:30] <OndraSter> aka xmega devices
[20:07:52] <Kevin`> CapnKernel: the starting value mostly depends on the last state it was in
[20:08:16] <Kevin`> I wonder if that's possible though, for sram
[20:08:23] <Kevin`> dram it wouldn't be
[20:28:33] <CapnKernel> Kevin`: After a day with power off?
