Back
[04:09:57] <bitd> Is it normal for a STK500 to take 30 seconds to write 1400 bytes to an ATTiny? O_O
[04:10:54] <RikusW> what is the sck speed ?
[04:11:05] <RikusW> aka programming clock
[04:11:26] <specing> bitd: no
[04:11:44] <specing> should be sub second
[04:11:57] <RikusW> and which version of studio / or avrdude did you use ?
[04:14:36] <bitd> Eh, using a makefile, cant find that sck speed. I am using avrdude 5.11.1
[04:16:25] <RikusW> try setting a higher programming clock speed
[04:16:45] <bitd> Its not specified at this point.
[04:16:52] <RikusW> use -B
[04:17:16] <bitd> Yeah, found that :)
[04:17:34] <RikusW> seems the stk500 will remember the last used setting
[04:17:44] <RikusW> (stored in its eeprom)
[04:17:50] <specing> there should be avrdude -B '>9000'
[04:17:57] <RikusW> try 4us ?
[04:18:45] <RikusW> that is 250kHz which should mostly work fine
[04:18:45] <bitd> Alright, thank you, lets try that.
[04:18:45] <RikusW> assuming your tiny runs at >= 1MHz
[04:18:54] <bitd> 8MHz indeed.
[04:20:23] <bitd> Haha, all done.
[04:20:23] <bitd> Thanks guys :)
[04:20:39] <RikusW> how fast is it now ?
[04:20:54] <bitd> 0.93s :P
[04:20:59] <RikusW> nice :)
[04:21:08] <RikusW> you probably don't have to use -B again
[04:21:31] <bitd> Uh oh.
[04:21:31] <bitd> avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
[04:21:31] <bitd> avrdude: safemode: Fuses OK
[04:21:40] <bitd> Going too fast I guess.
[04:22:04] <RikusW> try -B 8 or 16 then
[04:23:29] <bitd> 128 is the first value to not error O_O
[04:23:39] <bitd> Oh well, 15 seconds.
[04:24:24] <RikusW> what is your isp wiring like ?
[04:24:49] <RikusW> are there any other wires connected to the isp pins ?
[04:25:15] <bitd> No just the flat cable.
[04:25:46] <bitd> The ISP pins are dedicated to just that purpose.
[04:25:52] <bitd> No IO or anything like that.
[04:25:53] <RikusW> good
[04:26:45] <RikusW> I've found it can become an issue, particulary at >=1MHz
[04:27:02] <bitd> Using the STK with a usb to serial converter, which I hear is very problematic.
[04:27:32] <RikusW> So I've heard as well
[04:27:48] <bitd> Too bad I no longer have a serial port :(
[04:28:35] <bitd> Perhaps its time to invest in an AVRDragon.
[04:29:14] <RikusW> get an Atmel Ice instead
[04:29:28] <RikusW> nearly the same price
[04:29:51] <RikusW> though its connectors are 50mil not 100
[04:30:09] <RikusW> and only the dragon can do HVSP/PP
[04:30:18] <Jartza> or arduino ;)
[04:30:25] <RikusW> noooo
[04:30:36] <bitd> Arduino is very problematic to be used as a programmer.
[04:30:53] <bitd> Had huge trouble with resets.
[04:31:15] <Jartza> I use arduino as HVSP
[04:31:48] <bitd> Yeah, but HVSP gets messed up if you use external pullups for the reset.
[04:32:10] <bitd> I need the strong pullup because of the noisy environment. stated in the atmel sheet.
[04:32:22] <bitd> So HVSP is no option for me.
[04:32:26] <RikusW> how strong ?
[04:32:41] <bitd> 4.7K
[04:33:00] <bitd> The ATTiny has internal pull ups as well, which should keep it from resetting.
[04:33:35] <bitd> But in one of those atmel application notes I read in noisy environment you should also use the 4.7K external.
[04:35:02] <bitd> AVR042: AVR Hardware Design Considerations
[04:35:05] <bitd> Thats the one.
[04:36:21] <bitd> Anyway, atmel ICE it is. Thanks RikusW
[04:37:06] <RikusW> :)
[04:41:34] <Jartza> atmel ice is quite affordable, if you don't need the full cable set
[04:43:06] <RikusW> make it yourself ?
[04:43:24] <RikusW> I'd prefer to have it in the plastic case though
[04:43:34] <Jartza> nope, fully assembled
[04:43:39] <Jartza> $49
[04:43:49] <Jartza> http://store.atmel.com/PartDetail.aspx?q=p:10500377;c:100112#tc:description
[04:46:36] <bitd> Yeah, not going to be assembling anything for that price :)
[04:48:30] <Jartza> indeed
[04:48:37] <Jartza> except I didn't buy mine from atmel shop
[04:48:49] <Jartza> as the total price would've been >$80 with shipping
[04:48:55] <Jartza> plus taxes, plus customs
[04:51:50] <vsync_> hmmm
[04:52:42] <vsync_> Jartza: there are no additional customs fees for electronics
[04:52:45] <vsync_> just VAT
[04:53:07] <vsync_> over here...
[04:53:27] <Jartza> except DHL "customs security deposit fee", which is >18€
[04:53:37] <Jartza> or whatever robbery they call that :)
[04:53:45] <Jartza> but yeah, no customs as such
[04:54:10] <Jartza> you need to pay 18€ to dhl to be able to pay VAT to release the package from customs
[04:54:27] <vsync_> yeah, but you don't necessarily have to
[04:54:33] <Jartza> anyways, I oredered mine from Digikey UK
[04:54:50] <Jartza> was around £44 or something
[04:54:55] <vsync_> if you are willing to do the paperwork yourself, i.e. show up at the airport
[04:55:19] <Jartza> true
[04:55:23] <vsync_> DHL/UPS/Fedex are just willing to do the customs clearance for you, if you're feeling lazy. That's what they charge you for
[04:55:37] <Jartza> you can also do it yourself online :)
[04:55:39] <vsync_> you need to provide them with the invoice or an item list usually
[04:55:45] <vsync_> yep
[04:55:59] <vsync_> i think that's sort of a new thing, ran into that myself only recently
[04:56:11] <Jartza> it's been available at least 2 years
[04:56:33] <vsync_> well, that's kind of new in my books
[04:56:35] <vsync_> hah
[04:57:54] <Jartza> it sort of is, yes :)
[04:58:20] <Jartza> ohh. didn't remember that t84 had 16-bit timer too
[04:59:58] <Jartza> well, that would be ok for 8192 bps uart then :)
[05:00:18] <Jartza> with 16MHz oscillator the accuracy is good enough I guess
[05:52:12] <vsync_> mega vs xmega in terms of power consumption?
[06:28:10] <RikusW> afaik xmega use less
[06:28:39] <RikusW> per MHz that is
[08:42:52] <hypermagic> vsync_, atmega 168PA
[08:43:13] <hypermagic> set it at 32768Hz ^^
[08:47:09] <bitd> Anyone know how to make an ATTiny84 work at 16MHz without external crystal?
[08:50:35] <twnqx> use an external resonator!
[08:51:12] <bitd> Let me rephrase.
[08:51:22] <bitd> Anyone know how to make an ATTiny84 work at 16MHz without external crystal or external resonator?
[08:51:27] <bitd> ;D
[09:12:30] <bitd> Righto, you cant do that with the 24/44/84. Its the 85 you need.
[12:34:27] <robinsz> so, I have some structures holding some function pointers ... structs are declared static const, so are the functions, and all is good, except the structs reside in RAM.
[12:34:38] <robinsz> programme runs fine
[12:36:01] <robinsz> I add a PROGMEM storage specifier to the typedef of the structs, they get stored in flash, but .. the programme no longer works, the move to progmem seems to have screwed up some of the pointer or something
[12:36:29] <robinsz> why woudl a change in storage location acrew that up?
[12:36:53] <tk`> are you reading the PROGMEM data properly?
[12:37:27] <tk`> i mean with functions like pgm_read_word
[12:37:29] <tk`> etc
[12:44:11] <robinsz> hmm. no?
[12:45:15] <robinsz> the structure is fairly nested with structs within structs
[12:45:34] <tk`> adding PROGMEM attribute to data will only inform compiler that they must be stored in flash
[12:45:49] <tk`> to read them you need to use these functions
[12:45:58] <tk`> which in your case may be complicated
[12:46:48] <robinsz> so ...
[12:47:10] <robinsz> for example, I call some function from its pointer like so:
[12:47:12] <robinsz> (*colp[mainMenu.columnId]->rows[mainMenu.rowId].menuFunction)();
[12:47:56] <robinsz> but thats from data memory, so in progmem, I would have to modify that?
[12:48:28] <tk`> yes
[12:48:51] <tk`> well, i'd say it's impossible to do in reasonable way
[12:49:46] <tk`> progmem data is good for some constant arrays, lookup tables etc
[12:50:09] <robinsz> all this data is static const, unchanging
[12:50:16] <robinsz> and im running low on RAM
[12:50:38] <robinsz> it just defines a static menu structure
[12:51:41] <rue_bed> static info can go in flash or eeprom
[12:51:58] <rue_bed> but to use it, it usually copies it to an area of ram
[12:52:14] <rue_bed> from what I'v seen in the gcc assembler output
[12:52:49] <robinsz> so pgm_read_pointer looks good
[12:59:37] <tk`> you'd need to do sth like: ptr = pgm_read_ptr(&colp[mainMenu.columnId]);
[12:59:39] <tk`> and then
[13:00:24] <tk`> (*pwm_read_ptr(&ptr->rows[mainMenu.rowId]))();
[13:00:37] <tk`> but i'm not sure of it
[13:00:47] <tk`> pgm*
[13:31:25] <robinsz> tk`, thanks, I'll try that
[13:31:49] <robinsz> is there some automatic way to detect if something is in pgm memory?
[15:16:06] <mulvane> Tom_itx How much are you selling your programmer for now adays?
[15:25:27] <LoRez> all of the monies
[15:27:09] <mulvane> Well, I have .73 cents on my table right now.. He can has it all
[16:22:03] <malinus> mulvane:
http://tom-itx.no-ip.biz:81/~webpage/commerce/commerce_index.php
[21:17:48] <Bardes> Hey there, I've got a quick question that I can't seem to find an answer to....
[21:19:08] <Bardes> Some pieces of code seem to imply that timers stop running during interruptions, but I don't see it mentioned explicitly anywhere in the datasheets or the avr-gcc library
[21:19:31] <Bardes> So... Do timers really stop during interrupts?
[21:19:39] <Valen> nope
[21:19:51] <Valen> timers are just hardware counters hooked up to the clock
[21:20:11] <Valen> unless you have some kind of rtos or whatever
[21:20:45] <Valen> you may find that if you are in an interrupt and your timer should fire that it will be delayed until you leave the interrupt
[21:22:03] <Bardes> Right, that's what I thought... It made no sense to have timers if they'd stop for interrupts...
[21:23:55] <Bardes> And yes, I've read that interrupts are disabled automatically at the beginning of the handlers, so you cant get "recursive" interruption calls
[21:25:04] <Bardes> From what I saw the best policy to avoid "collisions" is to make handlers as simple and little as possible
[21:37:07] <Valen> thats one option
[21:37:14] <Valen> or go nuts the other way
[21:37:15] <rue_house> ALL interrupts should do the bare minimum and exit as fast as they can
[21:37:26] <Valen> my mainloop does nothing, interrupts do *everything* ;->
[21:37:27] <rue_house> if you put a delay in an interrupt routine, you dont know what your doing
[21:38:02] <rue_house> ANYTHING that isn't ABSOLUTLY time critical should happen in the main loop
[21:38:23] <rue_house> to the piont where the interrupts just set flags to make the main loop do things
[22:52:56] <tpw_rules> rue_house: that's not necessarily a good idea
[22:53:14] <tpw_rules> delays are bad, but having a main loop that doesn't do anything isn't bad either
[22:55:23] <Casper> if you have a main that consist of while(true); then you might want to check if some sleep mode can be possible