Back
[01:39:07] <rue_shop3> here too
[01:40:24] <rue_shop3> chineese buying them for more than asking price and driving prices up
[02:38:44] <inflex> extra money lubricates the approval process
[02:40:25] <xa0z> Anyone ever messed with a smoke/gas sensor?
[05:20:02] <doev> hi. are there any problem with "Int. RC Osc. 128 kHz" or something to know?
[05:20:54] <doev> I am not sure, I ve read something that you dont use it in combination with "Divide Clock by 8"
[06:53:59] <cehteh> doev: i am using that, works well
[06:54:26] <cehteh> progrramming with avrdude needs to be a lot slower (-B)
[06:56:28] <doev> cehteh, I read about the timing problem, when the clock is to slow, you cant you the ISP anymore. I alos see the -B parameter, but I am not sure if it will help.
[06:56:44] <cehteh> here it does
[06:56:50] <cehteh> attiny45
[06:56:51] <doev> actually I only have one ATTiny13A and I don't want to brick it.
[06:57:39] <cehteh> for testng i use the normal clock and clockdiv to scale down to 125khz
[06:57:51] <cehteh> only in production i fuse it for 128 OSC
[06:58:05] <cehteh> that might be worthwhile for you too
[06:58:15] <doev> 128khz, but without the clock divider?
[06:58:47] <cehteh> there is the 'normal' high power RC oscillator which runs at 8mhz or so
[06:58:52] <cehteh> you can scale it down
[06:59:34] <cehteh> and there is a 128khz low power rc osc for the watchdog which is quite inprecise .. you can use a fuse to use it as main clock for extreme low power applications
[06:59:38] <cehteh> http://git.pipapo.org/?p=battswitch.git;a=blob;f=src/battswitch.c
[06:59:50] <doev> but when I use 128Hz with the clockdivider, it will be run with 16kHz
[07:00:20] <cehteh> see line 264 ff
[07:00:26] <cehteh> yes
[07:00:46] <cehteh> then you dont need any divider
[07:01:07] <cehteh> you can do that dynamically, divider can be changed at runtime and fuses can be read by your program
[07:01:19] <doev> well, I want to clock it as low as possible.
[07:01:41] <cehteh> why that?
[07:02:27] <doev> to reduce power consumption.
[07:03:14] <cehteh> better use the highest 'sensible' clock (aka you get your work done in a reasonable time frame) and use proper sleep modes
[07:03:17] <cehteh> see datasheet
[07:03:37] <cehteh> 128khz RC osc is quite low power, i wont divide it down any more
[07:04:06] <cehteh> and try to be in sleep as much as possible, that saves energy much more
[07:04:16] <doev> hmm ok, I thought less clock => less timer interrupts => less power consumption
[07:04:48] <cehteh> the timer interrupts happen how you configure them
[07:05:00] <cehteh> of course you want the least possible
[07:06:44] <doev> I am pretty new, what I basically need is a Timer and PWM for some leds.
[07:07:05] <doev> I want to freely set the indivisuall brightness.
[07:07:46] <doev> And I want to do it in ASM-.
[07:08:04] <cehteh> omg
[07:08:07] <cehteh> why? :D
[07:08:32] <cehteh> tiny13 has only one timer or?
[07:08:33] <doev> The memory is nearly filled when I include delay.h
[07:08:45] <doev> yes, one timer
[07:09:00] <cehteh> that is a but ugly
[07:09:19] <cehteh> do never ever use delay()
[07:09:34] <cehteh> and i did a lot in the tiny13 in C
[07:10:12] <DKordic> IIRC delay.h is BusyWait.
[07:10:18] <cehteh> anyway i think with only one timer you get into trouble
[07:10:20] <cehteh> yes it is
[07:10:50] <cehteh> for led brightness you need fast enough pwm, and then you can drive up to 2 outputs by pwm
[07:11:25] <cehteh> but if you want some wakeup timer it would at least trigger on each timer overrun, which, because of the pwm speed would be quite often
[07:11:38] <DKordic> doev: +1 for assembly.
[07:11:45] <cehteh> alternatively you *may* use the watchdog interrupt as 2nd timer
[07:11:55] <cehteh> thats getting a bit tricky
[07:12:10] <cehteh> but imo you should consider a tiny25 or tiny45
[07:12:12] <doev> ok
[07:12:26] <cehteh> much less memory pressure and more hardware capabilities for almost the same price
[07:12:42] <cehteh> and way more common
[07:12:44] <doev> Aktually I have only the attiny13a and I want to order some other stuff if my list is long enougth.
[07:13:06] <cehteh> consider to switch to tiny45
[07:13:18] <cehteh> you can to some tests with the 13
[07:13:52] <cehteh> btw there are dedicated LED controllers for such things
[07:13:58] <cehteh> dunno what else you wanna do
[07:14:12] <cehteh> but these led controllers do a better job
[07:15:11] <doev> the application flow is very simple: After Reset the controller have to do some led patterns for about 10 minutes, then wait 1,5h and do the pattern again, wait 1,5h, ... a.s.o.
[07:15:18] <cehteh> 8bit pwm gives a quite coarse brightness only, because you need to fit human perception on brightness which may then result in about 16-32 different brightness levels only
[07:43:23] <_ami_> doev: use asm for delay :D
[07:43:48] <cehteh> dont use any busy loop when you value your battery charge
[07:45:46] <_ami_> i meant its okay to have busy loop for 1 or 2 sec
[07:46:15] <_ami_> but definetly not for 10m or 1.5hrs
[07:48:02] <cehteh> 10-.20 nanosecond ... yes :)
[07:48:14] <cehteh> 1-2 seconds .. no, not even milliseconds
[07:49:09] <cehteh> i do a busy loop in my timer when it decides that the next wakeup would be too close in time to set up an compare-match interrupt for it
[07:49:46] <cehteh> thats something along less than 30 cycles or so, dunno exactly
[07:54:59] <_ami_> cehteh: one q, _delay_ms for 10 ms and _delay_ms for 1hr byte difference won't be much as _delay_ms is based on timer? only difference would be to difference in size of timeout value?
[07:56:10] <cehteh> delay_ms is always a busy loop and never a timer
[07:56:18] <_ami_> ok. i did a small test, difference in .text section _dela_ms 10000 - _delay_ms 1 = 1982 - 1962 = 20 bytes
[07:56:32] <_ami_> oh, ok makes sense
[07:57:03] <cehteh> well i dont use it
[07:57:38] <cehteh> for the busy loop i talked about above i do a as-hoc loop while (TCNT < destination);
[07:58:06] <cehteh> thats all timer based here
[07:59:07] <_ami_> cehteh: got it.
[08:00:36] <_ami_> cehteh: what u just said abt comparing TCTN is not exactly a busy loop.
[08:01:34] <cehteh> of course it is
[08:01:48] <_ami_> TCCR0 |= (1 << CS00); TCNT0 = 0; while ... { if (TCNT0 >= X) { //do somthing... TCNT0 = 0; }
[08:02:13] <cehteh> not that way
[08:02:39] <_ami_> aha, got it :D
[08:02:42] <_ami_> my mistake
[08:02:45] <_ami_> misunderstood
[08:02:46] <cehteh> almost exacty like i saied while (TCNT0 < X); /* do nothing */
[08:02:50] <_ami_> yeah
[08:03:12] <cehteh> http://git.pipapo.org/?p=muos;a=blob;f=src/muos/muos.c;h=0b5b703317c09bb4e883434438630be065ada3ee;hb=36a2eb6560080ac1a2e95b038205d963197e387e#l34
[08:04:21] <_ami_> aha moment for me. :D , its a smart way of doing buys loop. i am sure while (TCNT0 < X); code size is a lot less than other way of doing busy loop.
[08:04:46] <_ami_> cehteh: nice ~~~
[08:18:28] <antto> mm, i got parallel port on this optiplex comput0r >:)
[09:08:27] <kre10s> Is there a way to set a pin in portd without touching sreg or using a register?
[09:11:04] <kre10s> ah. cbi apparently can access those addresses... what was i thinking?
[09:22:18] <antto> cbi would set it to zero i think, sbi to one
[09:26:43] <cehteh> gcc optimizes ioreg |= and ioreg &= ~() to sbi/cbi
[09:28:10] <_ami_> cehteh: without optimization, its out ? right? it saves 1 word for sure in size
[09:28:51] <cehteh> without optimization it would be lots more code
[09:29:08] <cehteh> reading ioregister and&or it, write it back, non atomic
[09:30:03] <_ami_> ldi r16, 0b0000001 and out DDRB, r16 => sbi DDRB, 0 thats only difference i think
[09:31:35] <cehteh> no you need to consider the actual content of the register
[09:34:01] <liwakura> _ami_: the first variant would set all other bits to zero
[09:34:05] <liwakura> the second not
[09:34:48] <_ami_> liwakura: aha, its like PORTB |=
[09:35:03] <liwakura> no
[09:35:22] <liwakura> PORTB |= does a read first, and then the write. that non-atomic thing cehteh said
[09:35:49] <cehteh> liwakura: gcc optimizes that to sbi
[09:35:51] <liwakura> except when its only one pin, then the compiler optimizes to sbi/cbi
[09:36:01] <cehteh> yes
[09:37:26] <liwakura> also, i haven't ever seen the compiler use the T status flag for bit operations
[09:38:33] <_ami_> does gcc optimize for multiple pins set at one go too? PORTB |= 1 << PB0 | 1 << PB1 => gcc optimizes it to sbi DDRB, 0 and sbi DDRB, 1
[09:39:37] <DKordic> _ami_: Why would `PORTB' become `DDRB'!?
[09:39:50] <_ami_> ah, typo
[09:39:50] <cehteh> i am pretty sure thats not what one wants
[09:39:59] <_ami_> i meant PORTB
[09:40:00] <cehteh> sometimes pins have to be set atomically on a instant
[09:41:00] <cehteh> imagine driving complementary fets
[09:41:20] <_ami_> cehteh: alright, so it won't do that. so it needs to first read PORTB
[09:41:25] <_ami_> got it.
[09:41:25] <cehteh> yes
[09:42:07] <cehteh> dunno if one can or/and on ioregs
[09:44:09] <DKordic> ``out PINn ,GPR'' will eor `PORTn' on newer devices. Xmega has more SFRs per port, like set and clear.
[09:44:46] <cehteh> ah
[09:46:17] <WormFood> [22:01:50] <cehteh> without optimization it would be lots more code <-- Just for fun, see what happens with the different optimization levels in GCC. (I've done this before, the optimization is fuckin' amazing)
[09:46:38] <cehteh> .. and then look at arduino :D
[09:46:51] <cehteh> http://pastebin.com/dSRSxgax
[09:46:53] <WormFood> Arduino? What's that? Never heard of it before.
[09:47:01] <cehteh> :)
[09:47:07] <cehteh> so i am out bbl
[09:47:09] * WormFood doesn't look at pastebin.com
[09:47:17] <WormFood> gonna pick up then?
[09:49:20] <_ami_> cehteh: haha
[09:49:34] <_ami_> bloated arduino sdk APIs
[09:51:08] <DKordic> Yes, it's hard to beleive till You see it Yourself.
[10:43:27] <twnqx> <cehteh> sometimes pins have to be set atomically on a instant <- i wonder if there's a #pragma for that
[12:00:49] <doev> musst the stackpointer really initiallized as you can read on many documents?
[12:01:52] <learath> that depends - do you like deterministic behavior?
[12:03:30] <_ami_> doev: if you are gonna use call/rcall <function> then SPH and SPL should be initialized with RAMEND
[12:03:47] <_ami_> if u r not gonna use functions, then its not required
[12:05:07] <learath> _ami_: do so few instructions require it?
[12:09:31] <doev> ok, there musst be a reason why SPH/SPL not automatically initialized after reset.
[12:10:09] <DKordic> doev: Acording to DS it's initial value is RAMEND.
[12:10:40] <doev> DKordic, yes, but I have to set it manual.
[12:12:30] <DKordic> It's just 12 bytes and 6 cycles? So why not?
[12:12:58] <DKordic> What is Your question?
[12:13:08] <doev> 12 of 1024bytes
[12:14:16] <DKordic> Have You ran out of FLASH?
[12:14:18] <liwakura> learath: if you want to use the stack (push,pop,*call,*ret codes), you should init the Stackpointer
[12:15:20] <doev> DKordic, not in asm so far, but with c.
[12:16:32] <DKordic> `-Os' switch?
[12:16:44] <doev> <es
[12:16:47] <doev> <es
[12:16:55] <doev> yes
[12:17:38] <doev> I think for the attiny13a with only 512bytes-flash, I have to only set SPL
[12:18:02] <DKordic> Yes.
[12:18:59] <doev> so, there are always stored words on the stack
[12:19:36] <DKordic> ENOSENSE
[12:20:08] <doev> than I have to init SPH and SPL
[12:21:11] <_ami_> doev: you are writing asm? pure asm code?
[12:21:34] <_ami_> if you are mixing c with asm then you don't need it as C compiler will take care of it.
[12:21:35] <doev> _ami_, I try
[12:22:15] <_ami_> doev: are you writing for learning ? or doing some project?
[12:22:43] <_ami_> writing asm requires patience and time.
[12:22:45] <doev> learing, but there is a project behind as goal.
[12:23:21] <_ami_> doev: is your target board is very tiny attinys e..g t10, t13 etcs
[12:23:37] <doev> attiny 13A
[12:23:48] <_ami_> then it makes sense. :D
[12:24:29] <_ami_> doev: attiny13a is DIP? or sot23. i think t10 is sot23 only.
[12:24:56] <doev> dunno, there are 8pins
[12:26:52] <doev> ok, there is no constant SPH for the attiny13A
[12:27:07] <_ami_> doev: which assembler are you u
[12:27:11] <_ami_> using?
[12:27:19] <_ami_> avra or the official one?
[12:27:30] <doev> I don't undertsand why I can address 512bytes with a 8-bit register.
[12:27:38] <doev> _ami_, avra
[12:27:57] <_ami_> doev: included the t13a def file in the codE?
[12:28:27] <doev> tn13Adef.inc
[12:28:31] <twnqx> doev: the key is "word addressing"
[12:28:38] <twnqx> operating on 16bit words
[12:28:44] <twnqx> 512 byte = 256 16bit words
[12:28:44] <_ami_> there is no SPH and you don't need it for tiny13
[12:29:02] <twnqx> just like how you address 128kB rom on the larger chips
[12:29:49] <doev> than I waste one byte when I push/pop a register.
[12:31:19] <_ami_> twnqx: push opcode = 1 nibble?
[12:31:50] <twnqx> actually, i was speaking in a general way, not specifically regarding stack
[12:33:10] <_ami_> doev: SRAM is tn13 is only 6 bytes
[12:33:13] <_ami_> 64*
[12:33:41] <_ami_> that is why SPL is good enough to handle it.
[12:35:53] <_ami_> doev:
http://www.atmel.com/images/doc8126.pdf
[12:38:34] <_ami_> doev: tn13a is very cheap..
[12:41:33] <inkjetunito> 6 byte ram would be an interesting constraint
[12:41:40] <twnqx> for certain definitions of cheap
[12:41:59] * twnqx still compares every avr 8bit to 50ct arms
[12:42:00] <_ami_> now, i got one q, little confused with RAMEND value. For tn13a, RAMEND = 0x9f = 159 but DS says internal sram is 64 bytes.
[12:42:28] <twnqx> does that maybe include the memory mapped IO range?
[12:42:33] <DKordic> _ami_: GPRs, SFRs, RAM.
[12:43:16] <_ami_> oops yea. the SRAM_START is 0x60
[12:43:40] <_ami_> 0x9f - 0x60 = 63
[12:43:43] <_ami_> makes sense
[12:43:56] <_ami_> twnqx: indeed.
[12:47:59] <doev> _ami_, I see. its only 64byte. my fault.
[12:48:23] <_ami_> doev: it depends on RAMend value
[12:48:39] <_ami_> RAMEND is 159 which a byte can hold
[12:48:49] <_ami_> hence you don't need SPH for this.
[12:49:55] <doev> I think 512bytes is the sram size of the larges attiny.
[12:50:51] <_ami_> doev: which project are you gonna work after you learn ASM?
[12:52:38] <doev> _ami_, its simple ... I hope. There are two leds (same port). I want to produce light patterns, best if I can store them in a table. But I need a timer, cause the light patterns should start and stoped by a timetable-
[12:53:04] <_ami_> doev: ok, cool. sounds fun.
[12:53:07] <doev> for example
[12:53:35] <doev> wait 1,5h than blink 10 times with brightnes 5.
[12:53:44] <_ami_> doev: i am also learning asm these days whenever i get time. which book/article are you referring?
[12:53:49] <_ami_> doev: ah, nice
[12:54:41] <_ami_> doev:
https://sites.google.com/site/avrasmintro/ - is my favorite
[12:55:23] <_ami_> doev: you could refer this too.
http://www.avrbeginners.net/new/tutorials/
[12:55:28] <_ami_> very nice ones
[12:55:35] <xoom> hello :)
[12:55:45] <DKordic> Hi.
[12:55:46] <doev> _ami_ this is the commercial product ... cause it has an easy logic, I want to build something similar.
[12:55:54] <xoom> have a little problem :)
[12:55:54] <doev> http://sleepwithremee.com/
[12:56:13] <xoom> reading 20bit ADC with AVR
[12:56:47] <xoom> so i read 3 bytes in total
[12:56:57] <xoom> 4 MSB is status bits
[12:58:07] <xoom> sorry got disconnected
[12:58:30] <doev> Hello xoom
[12:58:40] <xoom> so the problem is that i cant fit in calculations
[12:58:54] <xoom> i guess doing it very bad way :)
[12:59:10] <xoom> adcvalue=((Data[2]<<16)|(Data[1]<<8)|Data[1]);
[13:00:17] <xoom> damn connection :/
[13:00:22] <xoom> adcvalue=((Data[2]<<16)|(Data[1]<<8)|Data[1]);
[13:00:37] <xoom> so this is how i add up 3 bytes
[13:00:44] <DKordic> xoom: ``Data[0]'' at the end!
[13:00:55] <xoom> oh
[13:01:07] <DKordic> You mean _put_ together?
[13:01:35] <xoom> Data[0] corrected
[13:01:43] <xoom> yes i mean put :)
[13:01:52] <xoom> i hope its right way?
[13:02:19] <twnqx> what's the type of your adcvalue var?
[13:02:29] <DKordic> Don't forget ``-Os'' optimization switch :) .
[13:02:31] <xoom> uint32_t
[13:03:54] <xoom> as now its 24bits total and i only need 20LSB of them
[13:03:57] <xoom> i do this:
[13:04:25] <xoom> adcvalue=(adcvalue & 0xFFFFF);
[13:05:06] <xoom> up to here maybe (just maybe) everything is ok
[13:05:22] <xoom> but when i want to calculate measured value
[13:05:31] <xoom> there i think i get in to trouble
[13:05:43] <xoom> ch2=(32000*adcvalue)/0xFFFFF;
[13:06:50] <DKordic> What should that mean?
[13:07:15] <xoom> its ADC value
[13:07:21] <xoom> 32000mV
[13:09:29] <xoom> but im geting like 3 times same values when adjunsting potenciometer
[13:09:33] <xoom> to that ADC
[13:09:51] <xoom> and also 3.xxx values
[13:09:58] <xoom> not 32.xx
[13:10:25] <xoom> i think adcvalue gets overflowed
[13:11:22] <xoom> any ideas how to do it right? :)
[13:18:29] <twnqx> the formula vor calculation of the voltage from the value is given in the data sheet
[13:18:32] <twnqx> for*
[13:19:17] <twnqx> <xoom> adcvalue=(adcvalue & 0xFFFFF); <- you want to truncate the upper bits off?
[13:19:35] <xoom> yes
[13:19:49] <xoom> 4 upper bits are status bits
[13:20:13] <xoom> there is no formula in datasheed
[13:20:14] <twnqx> <xoom> ch2=(32000*adcvalue)/0xFFFFF; <- might be a bit of a problem still
[13:20:29] <twnqx> 15 bits * 20 bits = 35 bits, overflowing your 32bit int
[13:20:45] <xoom> yes
[13:21:05] <xoom> but how to solve that :)
[13:21:12] <twnqx> iirc i simply used floats
[13:21:20] <twnqx> as inefficient as it is on avr :P
[13:21:38] <twnqx> or you use a uint_64t
[13:21:51] <xoom> i tryed uint_64t
[13:22:03] <xoom> bit better but still something goes wrong
[13:22:11] <xoom> when use 64bit
[13:22:23] <xoom> i get that 32.XX value
[13:22:57] <xoom> but still when adjusting voltage to ADC i get 3 times same values
[13:23:17] <twnqx> what's your vref, and what's your maximum input voltage?
[13:23:25] <xoom> its like voltage going up - down - up - down - up - down
[13:23:35] <xoom> vref is 2.5v
[13:23:48] <xoom> now i only input 12v
[13:23:54] <twnqx> ...
[13:23:54] <xoom> via resistor divider
[13:24:15] <twnqx> 2.5V is your upper measurable voltage then
[13:24:22] <xoom> yes
[13:24:35] <twnqx> and your formula kind of does not seem to match up
[13:24:39] <xoom> thats why resistor divider is in front of input pin
[13:24:50] <xoom> 32V - 2.5V
[13:26:16] <twnqx> i still doubt your formula
[13:26:49] <xoom> its same formula like in AVR datasheet
[13:27:16] <twnqx> in the end that formula is the same as multiplying with 0.0305
[13:27:34] <twnqx> or dividing roughly by 32.768
[13:27:51] <twnqx> which would first of discard the lower 5 bits of your measurement completely
[13:28:50] <twnqx> secondly, you have not corrected the measured voltages for the factor of your resistor divider
[13:29:20] <xoom> why not
[13:29:42] <twnqx> ok, let me take a step back
[13:29:44] <xoom> i calculated resistor values
[13:29:47] <twnqx> what's your chip?
[13:29:54] <xoom> atmega32
[13:30:53] <xoom> ADC chip is LTC2420
[13:31:12] <twnqx> ah, ok, i thought you're using internal adc
[13:31:29] <xoom> no
[13:31:45] <xoom> atmega dont have 20bit ADC :)
[13:31:58] <twnqx> i was also wondering about having status bits iin there ;)
[13:32:11] <xoom> :))
[13:33:23] <twnqx> next question what are the values of your resistor divider?
[13:35:56] <twnqx> also, are you sure you are reading in the right order?
[13:35:58] <xoom> 4Mom + 320K + trim pot
[13:36:16] <xoom> i think yes
[13:36:24] <xoom> i can see on scope data
[13:36:44] <twnqx> so you are first reading to data[2], then data[1], then data[0]
[13:36:46] <xoom> and if i put one byte on 7seg display it shows good data
[13:37:59] <twnqx> and you are throwing everythijng away if data[2] & 128 is set, as that means that the conversion is still running
[13:38:37] <xoom> im not reading so fast
[13:38:47] <xoom> read only every 500ms
[13:38:56] <xoom> conversion takes 160ms
[13:43:35] <xoom> damn have to go :/
[17:30:34] <LeoNerd> Anyone good with implementing SPI slaves? I find that on a tiny841 (which has a real SPI module, not the USI), the moment the last bit of a byte of transfer happens, the chip's MISO (i.e. its output) line gets raised high, and stays high during the inter-byte blank and for the first bit of the next work
[17:30:59] <LeoNerd> So every subsequent byte that the driving master reads effectively has a 0x80 ORed onto it
[17:34:34] <LeoNerd> Hrm. Seems to be timing-related. If I run the SPI chatter slower, that goes away
[17:35:54] <LeoNerd> (or, in this case, remember to clear the CKDIV8 fuse like I always seem to forget to, so I get a faster chip :) )
[18:39:55] <kre10s> LeoNerd, You could try placing a resistor in the MISO line and hanging a scope onto it, to find out who is driving the line.
[18:40:40] <kre10s> If it's the host driving the spi wrong or the slave fudging it up.
[18:48:28] <LeoNerd> Oh, mmmm that's a thought... I notice the timing of that glitch does vary with the clock speed of the attiny slave though. Hence my suspiscion is there
[19:01:07] <inflex> LeoNerd, you using the T13 RC clock?
[19:03:51] <inflex> Anyhow, if you're using the internal RC for clock, the T13 is known for jitter, makes it impossible to use for driving servos etc
[19:04:12] <inflex> ( and it's full spectrum, so it doesn't just 'average out' )
[19:10:46] <kre10s> How would I get the following not to compile away? uint16_t i = 1500; for (; i>0 && IS_SET(TRX_CD); i--);
[19:12:59] <Casper> there is something for gcc that I hear exist for that, no idea of the name however
[19:15:29] <kre10s> oh... it doesn't. how could it. IS_SET uses volatile. turns out gcc just rearranges the code.
[19:27:24] <cehteh> mhm so i've ordered 5 SOT-23 chips from reichelt, lets see what packaging they choose this time
[19:28:53] <Tom_itx> no package, just the die
[19:29:21] <cehteh> last time it was:
http://public.pipapo.org/GEDC0020.JPG
[19:29:36] <cehteh> lighter only for reference
[19:29:57] <cehteh> 5 smd LEDs in a huge box
[19:35:57] <Snert> that's outrageous
[19:38:27] <kre10s_> what is the context of the Unique Device ID bytes? like on the atmega48. is it like a date and lot code or just and incrementing number?
[19:39:29] <kre10s_> whats outrageous, is the size of that image, or rather, the lack of speed at which my connection is fetching it.
[19:39:48] <cehteh> get a better connection then :D
[19:43:08] <cehteh> where do you get 'unique' device id's
[19:43:19] <cehteh> i only know the signature byte which gives the chip type
[19:44:29] <cehteh> nothing unique at all, if i'd need a unique id i' d generate it on first boot
[19:44:34] <cehteh> (in eeprom)
[19:45:32] <kre10s_> some chips, like the atmega48, have 8 extra registers. The register address locations are located at 0xF0 to 0xF8. and are said to be unique. "Each individual part has a specific unique device ID."
[19:45:45] <kre10s_> err. 9 regs actually.
[19:46:08] <cehteh> i dontk now that
[19:47:37] <cehteh> i have the ATmega48PA datasheet here, that doesnt have such
[19:48:32] <kre10s_> atmega48pb section 13.6.8.
[19:49:14] <kre10s_> "13.6.8.1. SNOBRx - Serial Number Byte 8 to 0" doesn't even need SPM to read apparently.
[19:49:15] <cehteh> thats new then with the B versions
[19:49:28] <kre10s_> It's awesome!
[19:50:04] <cehteh> dunno
[19:50:23] <cehteh> i dont believe in vendor burned in numbers. i rather trust my own stuff
[19:51:32] <cehteh> anyway thats brand new and nowhere its mentioned how its generated
[19:52:10] <kre10s_> :/ It's not so awesome anymore.
[19:53:34] <kre10s_> for some reason I keep picking these new chips that avr-dude doesn't even know the signiture of yet.
[19:55:18] <cehteh> haha
[19:56:33] <kre10s_> now that you mention it. SNOBR0-8 aren't in my io defs... or in the datasheets register list.
[19:56:38] <Tom_itx> start by going thru avrdude's list then :D
[19:58:22] <kre10s_> hmm? what do you mean?
[19:58:52] <kre10s_> Oh. pick one from avrdudes list... What's the fun in that.
[19:59:00] <Tom_itx> if you can't find one avrdude supports
[19:59:02] <Tom_itx> hah
[20:00:18] <kre10s_> actually since the SPI programming protocol is standardized, you can program most any chip. you just have to make sure the size matches.
[20:01:07] <kre10s_> s/SPI/ISP
[20:01:19] <Tom_itx> size and signature
[20:01:31] <Tom_itx> and regs
[20:02:01] <cehteh> avrdude is completely configuration driven, you'll find a new avrdude.conf file somewhere on the web for the newer chips
[20:02:15] <kre10s_> you can override the sig with -F/
[20:02:25] <cehteh> yes but thats sometimes a bad idea
[20:02:34] <Tom_itx> i know or write you're own
[20:03:34] <kre10s_> my projects now come with a striped version of avrconf for the specific chip.
[20:03:42] <cehteh> fuse bits are not standardized iirc, at worst you may fuck up fuses with -F which then bricks the chip unless you can do high voltage programming
[20:58:21] <kre10s_> If you don't change the fuses that would be fine though right?
[20:59:11] <Tom_itx> they move bits around in the regs on different chips
[21:05:57] <LeoNerd> inflex: tiny841 on ceramic res
[21:08:46] <inflex> np
