#avr | Logs for 2014-05-13

Back
[00:00:17] * Xark notes great site (even for non-AVR and baud rates). :)
[00:13:13] <Casper> wormfood used to be always here
[03:27:53] <Daulity> hi
[03:32:13] * PHPtest sayin hello to everyone
[03:44:37] <PHPtest> guys, im reading about bootloaders, i understand the concepts about NRWW and RWW sections and general stuffs about bootloader, but cant find apropriate help or tutorial how to set fuse bits and some sample with avr/boot.h, i saw that sample on its wiki but thats unclear...
[03:45:43] <PHPtest> can someone explain me what fuse bits are needed to set for the usage of the bootloader and to be able to rewrite it, because if my tiny custom bootloader would fail i dont want to throw the chip away
[03:59:24] <PHPtest> what is this SPM?
[04:21:02] <Daulity> where do you put interupt related stuff in asm ? in which segment ?
[04:40:56] <malinus> PHPtest, this is neat http://www.engbedded.com/fusecalc/
[04:44:47] <PHPtest> malinus thanks but thats for atmega and i have xmega...
[05:12:53] <PHPtest> can i reset the fuse bits to default after ive set them?
[05:17:46] <PHPtest> if i set bootrst then avr studio will programm the code into the bls?
[05:26:04] <PHPtest> how can i tell avr studio that i have 1 hex file for the bls and another for app sector?
[05:26:33] <PHPtest> guys anyone? i have no ideea how to use this avr studio 6, its so different from 5
[05:41:23] <PHPtest> making a bootloader for xmega is only possible with IAR? i mean how do i choose in AVR Studio where the hex should be uploaded?
[06:10:34] <malinus> PHPtest, I don't know about the xmega, but in normal atmegas there are no "rest the fuse bits to default". All you can do is look up the default settings in the datasheet and burn them like that
[06:46:51] <RattusRattus> hi there. I am having 'fun' with <avr/eeprom.h>. Probably because I have missed somthing important. my avr has 512 bytes of eeprom, but the function to read from eeprom is defined as uint8_t eeprom_read_byte (const uint8_t * addr ) doesn't the address pointer need to be const uint16_t * addr) well at least 9 bit wide?
[06:51:48] <Lambda_Aurigae> RattusRattus, that does seem odd.
[06:53:17] <RattusRattus> Lambda_Aurigae: indeed the read word function has data as uint16_t *and* address as uint16_t* whilst dword is uint32_t data and uint32_t * for the address pointer.
[06:54:00] <RattusRattus> I find it hard to beleive that I am the first to think that this is a problem so suspect there is somthing I misunderstand.
[06:54:03] <RattusRattus> any ideas?
[06:56:03] <Lambda_Aurigae> no clue...it's the first time I've looked at it. I usually don't use more than 16 bytes of eeprom anyhow so never thought about it.
[07:02:28] <Lambda_Aurigae> http://www.fourwalledcubicle.com/AVRArticles.php
[07:02:35] <Lambda_Aurigae> some tutorials from abcminiuser
[07:02:41] <Lambda_Aurigae> there is one for eeprom in there.
[07:02:53] <Lambda_Aurigae> it doesn't explain why but does show how.
[07:03:29] <RattusRattus> oh indeed, Deans artical is good. but it doesn't talk about how to access byte data over element 255 i.e. he uses address 46 in his example.
[07:04:00] <Lambda_Aurigae> if I remember, I will ask him next time he is in.
[07:04:16] <RattusRattus> ahh you are at atmel as well?
[07:04:19] <Lambda_Aurigae> no
[07:04:25] <Lambda_Aurigae> but he comes in here sometimes.
[07:04:36] <RattusRattus> 'k
[07:05:56] <Lambda_Aurigae> and he isn't with atmel anymore.
[07:06:01] <Lambda_Aurigae> he moved on to bigger and brighter things.
[07:06:05] <RattusRattus> oooh he's moved jobs.... no longer at atmel!
[07:06:06] <Lambda_Aurigae> anyhow, off to work.
[07:06:11] <RattusRattus> thx!
[09:34:30] <rue_more> haaha who made the function use an 8 bit pointer!
[09:35:33] <malinus> rue_more, which function?
[09:36:09] <rue_more> zlog,
[09:36:21] <rue_more> <RattusRattus> hi there. I am having 'fun' with <avr/eeprom.h>. Probably because....
[10:43:04] <twnqx> no, why would that be the reason
[10:43:54] <twnqx> or hm... is the uint8t * addr a pointer to the address inside the eeprom?
[13:37:20] <PHPtest> hi guys, can someone pls explain why does an xmega output need pull up or pull down? im used with them in case of inputs...
[13:38:20] <myself> Google "Arduino pullup" for lots of helpful pages
[13:39:15] <PHPtest> myself thanks, i hope that will explain the usage of output pull ups
[13:41:13] <myself> waaaaait. output?
[13:41:41] <PHPtest> myself so mainly pull ups and pull downs are to protect the pins from shorts and disabling them only in case if i need more current, and by more is meant to be max 40mA
[13:41:41] <myself> who told you you needed pullups on *outputs*?
[13:41:54] <PHPtest> myself well im reading the datasheet
[13:42:56] <PHPtest> myself for example: Table 2-1. Output/pull configurations: PORT_OPC_WIREDORPULL_gc Wired-OR Pull-down
[13:43:25] <myself> that's for input usage. read the Arduino pages...
[13:43:38] <PHPtest> n the “Wired-OR” configuration, writing a ‘1’ to OUTn causes pin n to be driven hard to VCC. Writing ‘0’ to OUTn releases the pin, allowing the pin to be pulled to GND with an internal or external pull-down resistor
[13:43:57] <PHPtest> myself im not using arduino, im using a simple xmega chip alone
[13:44:46] <PHPtest> and this talks about internal pull up and pull down resistors in case of output direction
[13:45:22] <myself> huh. i don't know then.
[13:45:57] <PHPtest> the only reason i can imagine an internal pull up to be activated on output is to protect the pin from shorts, but that limits its current source, will pull up disabled it can provide more current source up to 40mA
[14:25:44] <PHPtest> guys whats the difference between totem and wired IO pin? both used on output?
[14:32:24] <hjohnson> PHPtest: a totem does push-pull on the pin
[14:32:34] <hjohnson> ie it will drive it to 3.3V or GND
[14:32:39] <hjohnson> (or whatever your VCC is)
[14:33:21] <hjohnson> not sure what you mean by wired, but typically the other options are open collector (second most common) or open emitter (very rare). Open Collector will pull the line to ground, but will leave it floating otherwise, open emitter does the opposite
[14:38:05] <PHPtest> hjohnson and why is that good for me?
[14:38:20] <hjohnson> why is what good for you?
[14:38:34] <PHPtest> hjohnson http://www.atmel.com/Images/doc8050.pdf
[14:39:23] <PHPtest> hjohnson i mean if im using the open collector with line pulled to ground, why would i care about that?
[14:39:32] <hjohnson> PHPtest: it basically comes down to what you actually want to achieve with the pin
[14:39:39] <hjohnson> if it's just connecting one IC to another, then you want totem pole
[14:40:00] <PHPtest> but totem also has pull up and pull down
[14:40:07] <hjohnson> if you're connecting multiple ICs together (say an I2C bus) then you have a wired-or situation, so you want open-collector.
[14:40:12] <hjohnson> right
[14:40:21] <hjohnson> it both pulls things up to VCC, and pulls them down to GND
[14:40:36] <PHPtest> hjohnson i mean totem pole can be configured on output even and also on output with pull up and pull down, so whats the difference then between it and wired one
[14:41:07] <N2TOH> are there good examples of GPS based spedometers?
[14:41:32] <hjohnson> N2TOH: doubtful, GPS isn't usually accurate enough on short timeframes to be all that useful
[14:41:56] <PHPtest> hjohnson why do i have wired-or in case of I2C?
[14:42:00] <N2TOH> I have seen them used for hot rods and boats
[14:42:08] <hjohnson> PHPtest: since you have multiple outputs connected together
[14:42:24] <hjohnson> since both your micro and the device you're talking to could theoretically try and write data to the pin at the same time
[14:42:42] <N2TOH> I have a spedometer on a bike that has a good odometer with a questionable speedometer
[14:42:43] <hjohnson> PHPtest: what you don't want ot have happen is for one chip to try and drive it to 3.3V, and the other trying to pull it to GND
[14:42:51] <hjohnson> then you basically have a short circuit and you let the smoke out
[14:43:35] <hjohnson> N2TOH: they're generally not all that acurate... usually what the hotrods are doing is also combinng the data with an acelerometer, and some other stuff rather than purely relying on GPS
[14:43:50] <hjohnson> on boats, it's a bit different, since things are relatively slow, and change slowly
[14:44:10] <hjohnson> the problem on boats is that GPS speed only gives you course over ground, not your speed through the water
[14:44:20] <hjohnson> though for motorboaters, I suppose that's all they care about)
[14:44:42] <hjohnson> as a sailor, I actually care more about the speed through the water, since that affects how I sail the boat.
[14:44:45] <kastein> depends on what I'm motorboating
[14:44:52] <hjohnson> lol
[14:45:44] <PHPtest> hjohnson but when one has 3.3v output and the other is pulling it to gnd, it means its pulling it with a resistor so why would it smoke out?
[14:45:59] <hjohnson> actually our instrument pack can also combine the data from the knotlog, a GPS, compass, to determine the speed/direction of currents
[14:46:19] <hjohnson> PHPtest: because the pulling to ground is usually very strong (if both are in output mode)
[14:48:01] <hjohnson> in the context of the AVRs, "pull up" and "pull down" is what the pin does when it's an input
[14:48:19] <hjohnson> basically it eliminates the need for an external pullup/down resistor
[14:48:22] <hjohnson> that's now how it's driven
[14:48:23] <PHPtest> hjohnson by strong you mean?
[14:48:32] <megal0maniac> 50K
[14:48:35] <megal0maniac> 30K
[14:48:36] <PHPtest> i have to make some research on this
[14:48:36] <megal0maniac> 20K
[14:48:43] <megal0maniac> Something like that. It's in the datasheet
[14:49:28] <PHPtest> oh, so it means when it pulls down the ground then it mainly cuts off the ground, so the 3.3V output will meat another even if 0V output and burn out the pin
[14:49:31] <PHPtest> one of the pins
[14:49:44] <hjohnson> yeah, and you don't know which one
[14:49:52] <PHPtest> ive got it
[14:50:14] <PHPtest> be right back
[14:50:26] <hjohnson> so the safe thing to do, if you're doing I/O on two different devices, is to run open-collector
[15:26:40] <Duality> i am not sure howto use intterupts and timers in assembly, it seems to generate pulses on a pin, but the duty cycle doesn't change when i load tcnt with a value any ideas ?
[15:29:42] <Duality> this is what my assembly code looks like http://pastebin.com/j5fCy0kC
[15:59:30] <megal0maniac> Can anyone tell me how much of a drag it is to get code from an Arduino library working in Atmel Studio? I don't mean program in Arduino, but in normal C using functionality of the library. Is it as painful as I think?
[16:01:33] <Xata> hello everyone
[16:22:00] <Tom_itx> megal0maniac it's rather exciting!!
[16:31:25] <Xata> is there any difference if i use an transceiver IC as client for wifi network, or as a access point? i mean - should it be done with same ICs?
[16:34:19] <megal0maniac> Tom_itx: Have you done it?
[16:34:41] <megal0maniac> I know it depends on which library to a large extent, but the process should be similar
[17:27:34] <hjohnson> Xark: what are you trying to accomplish?
[17:53:34] <Tom_itx> megal0maniac no i haven't and i doubt i will
[23:17:31] <nofxx> Is there some write protection fuse? atmega32u4 no matter what I try I get avrdude: verification error, first mismatch at byte 0x0000 on this board
[23:20:34] <Casper> yes and no
[23:20:42] <Casper> there is a few lock bits
[23:21:00] <Casper> if set, the verification will always fail
[23:21:17] <nofxx> Casper, on the fuses?
[23:21:23] <Casper> on the flash
[23:21:24] <nofxx> the lock bits are set*
[23:21:38] <Casper> lock bit prevent the read of the flash and eeprom
[23:22:13] <Casper> and unless you do a complete chip erase, it won't accept any new code in
[23:23:19] <nofxx> i'll need a icsp prog or can avrdude can do over usb?
[23:23:38] <nofxx> Casper, and thanks
[23:24:06] <Casper> depend on your programmer
[23:24:19] <Casper> if your programmer is a real one, then it shall work
[23:24:40] <Casper> if you use a bootloader then check your bootloader documentation
[23:25:04] <Casper> some do not allow the reading of the code (so will fail verification)
[23:25:41] <nofxx> on the code? not importing anything, just a simple serial init
[23:26:40] <nofxx> on it there's bitslash...
[23:26:48] <nofxx> guess it doesn't want to be overwrited
[23:55:04] <l0g1x> hey im fairly new to avr programming, but i had a question about using a programmer with debugging capabilities
[23:55:36] <l0g1x> ive used a isp programmer before and i know that that is to just load the code onto my atmega8
[23:56:07] <l0g1x> and i have read that the dragon is pretty common for debuging in JTAG
[23:56:13] <Casper> there is many ways to debug
[23:56:22] <Casper> debugwire is one, jtag is the second...
[23:56:32] <l0g1x> what is debugwire?
[23:56:49] <Casper> then you have the homebrew solution: led, lcd, serial output and the like
[23:57:04] <Casper> another debug protocol, mainly used on the smaller µC
[23:57:12] <l0g1x> yes ofcourse but i would like to step through my code