Back
[00:03:08] <l0g1x> ive tried use the avr dragon in atmel 6 but ive seen to get problem with communicating with dragon device. is this a known problem? i have seen online that people have issue with this
[00:03:28] <l0g1x> atmel studio 6*
[03:25:59] <RattusRattus> twnqx -> yes. if I have read the <avr/eeprom.h> document correctly. if I want to read byte data from the eeprom I call eeprom_read_byte and pass it an 8-pit pointer into the eeprom. This is fine for the first 256 bytes of eeprom space, but what about the 2nd half of the eeprom?
[03:26:39] <PHPtest> hi everyone
[03:26:53] <gcanada> hello
[03:27:44] <PHPtest> for inputs which are active high you recommend pull ups or pull downs? after my knowledge there need to be used pull down... to keep the port at 0 level
[03:29:47] <RattusRattus> more interestingly if I want to read 16-bit data back I would use eeprom_read_word and that expects a 16-bit pointer as its input, and eeprom_read_dword wants a 32-bit pointer. Surly I have missed somthing here because the address pointer passed into the read function should be scaled for the size of the eeprom, not the size of the data to be returned (the functions DO return 8, 16, and 32 bit numbers as I would expect) I am just confused how I am suppos
[03:31:09] <RattusRattus> PHPtest: pull inputs to a safe state. so if you want to do somthing when the input goes high, pull it to ground as its safe state. if you want to do somthing when the input is low therefor pull it high as a safe state.
[03:33:00] <PHPtest> RattusRattus thanks
[03:33:38] <PHPtest> RattusRattus and how to use them on output? xmega has the option to use pull ups and pull downs on output in TOTEM or WIRED state
[03:34:22] <gcanada> recently i have updated from avr-gcc-4.5.3 to avr-gcc-4.8.1 and i am having problems with the linker, LDFLAGS are not pointing to the same position with 4.5.3 and with 4.8.1, anybody knows why?
[03:36:17] <gcanada> * 4.5.3 is doing fine, 4.8.1 not.
[03:36:41] <RattusRattus> ok for outputs it also depends what you are doing. again the default state should be 'safe'. it is true that most IO lines are totum pole, but what if you use this to drice a transistor? now the transistor is open collector so the output line is just pulled down when you drive the output high.... but floats when you drive the output pin high. in this case you would probably want to add a pull up resistor on the collector of the transitor.
[03:39:21] <RattusRattus> now consider somthing like I2C where the data line can be both input and output depending on if your device is sending or recieving..... here you would always want to revert back to being an input (with either an external or internal pull up resistor), known as a week pull up. because if you leave the line as an output it driven either high or low (strong pull up/down) and in that state the other devices on the bus cannot drive the line to the oposite st
[03:41:04] <RattusRattus> PHPtest: does that help?
[04:02:01] <RattusRattus> PHPtest: ???
[04:03:02] <PHPtest> RattusRattus sorry my teacher just camed and asked things
[04:03:10] <PHPtest> RattusRattus yes, it helped a lot
[04:03:15] <PHPtest> i mean A LOT!
[04:03:32] <PHPtest> RattusRattus thank you very much that will clear my head up
[04:04:02] <RattusRattus> OK. /me just hates shouting replies into the void..... :-p
[04:04:56] <PHPtest> RattusRattus i hate that too, and im sorry for that, believe i really appreciate your help and i hope that making you waiting didnt offended you
[04:05:26] <RattusRattus> oh. just becuase you can turn on a pull up when you have a totompole output doesn't mean it will have any effect! you would need to look at the datasheet to see how they have wired the port internally.
[04:05:41] <RattusRattus> no offence taken
[04:06:13] <RattusRattus> ..... now if only someone coukld answer my query I could be a very happy bunny :-)
[04:06:21] <PHPtest> RattusRattus :D
[04:30:18] <PHPtest> how to set a pin direction to be bidirectional, can i read an output? if PORTA.DIR0=1; and wired to be at pull down on state 0 then read PORTA.PA0.IN as input<
[04:30:20] <PHPtest> ?
[05:10:01] <gcanada> recently i have updated from avr-gcc-4.5.3 to avr-gcc-4.8.1 and i am having problems with the linker, LDFLAGS are not pointing to the same position with 4.5.3 and with 4.8.1, anybody knows why?
[05:10:08] <gcanada> * 4.5.3 is doing fine, 4.8.1 not.
[05:13:47] <twnqx`> ldflags pointing to positions?
[05:17:10] <RattusRattus> gcanada: if I am reading tyour post correctly you are expecting pointers not to move arround between tool chain versions?! why do you think they shouldnt?
[05:18:56] <gcanada> its not about the pointers, it is about the memory sections
[05:19:55] <RattusRattus> please elaborate
[05:23:32] <RattusRattus> PHPtest: you don't set a pin as bi directional. you can set it as an input and read from it, only setting as an output when you have decided that you want to write on your bus. it is also good practice to look at what you have written to confirm that the bus isn't being held by some other device... a really good intro would be to look at the dallas (maxim) 1-wire bus application notes. it also covers how to use week and strong pullup etc etc.
[05:24:15] <edmont> hi
[05:25:23] <PHPtest> RattusRattus thats interesting, so i need to set it as input and change dir when sending data on it?
[05:25:45] <RattusRattus> you try and leave bi-directional lines as an input with NO pull up or down on the micro (perhaps setting it on the bus master device only) that way all devices on the bus 'see' a high impeadance and so don't need to sink or source a lot of current. you will then need to look at slew rate :-)
[05:25:54] <gcanada> RattusRattus edmont is here to try to explain you better the problem that i asked xD
[05:26:24] <edmont> RattusRattus: yes, i'm working with gcanada
[05:26:33] <RattusRattus> gcanada: :-) (can't say I'll be able to answer but will try)
[05:26:41] <RattusRattus> edmont: hi
[05:26:44] <gcanada> :D
[05:26:54] <edmont> the thing is we are normaly using Atmega128RFA1, and want to use Atmega256RFR2
[05:27:13] <edmont> in order to do it, we need a newer toolchain
[05:27:20] <RattusRattus> ok
[05:28:00] <edmont> gcanada: downloaded it and compiled a Contiki program
[05:28:18] <RattusRattus> and you have rebuilt all of you libuarys?
[05:28:24] <edmont> it seems everything works ok, except memory sections allocation
[05:29:23] <edmont> we use #define ADMINEEMEM __attribute__((section(".admineeprom")))
[05:29:29] <PHPtest> Rattus why using NO pull down or up? i2c is using wired-and and sda is used as output even if its bi-directional
[05:29:46] <edmont> adn LDFLAGS+= -Wl,--section-start=.admineeprom=0x00810100
[05:29:52] <edmont> in the Makefile
[05:30:19] <edmont> but it seems the linker is not taking this option correctly
[05:31:21] <PHPtest> RattusRattus the IN register is used for reading the pin value. The pin value can always be read regardless of the pin being configured as input or output, except if digital input is disabled.
[05:32:22] <PHPtest> RattusRattus so mainly i can set a pin as wired-and output and use it as input also when needed, right?
[05:33:13] <gcanada> the linker worked fine with avr-gcc 4.5.3 but not with 4.8.1
[05:33:14] <PHPtest> for example if i want to bitbang I2C because i have no I2C device on the chip, i have but its used for something else and cant get it unsoldered
[05:34:25] <RattusRattus> edmont: I suspect that I am barking up the wrong tree (my make scripting is poor) but don't you need -Wl, -Bstatic or -WL, -Bdynamic options against individual libs?
[05:35:27] <twnqx`> PHPtest: I2C uses external pullups
[05:36:03] <twnqx`> if you want to save on them, you might get away with the internal pullups, but i don't know if the values match
[05:37:50] <edmont> RattusRattus: what do you mean with individual libs?
[05:38:21] <PHPtest> twnqx` i dont want to get away with them i guess, but still not clear to me if i have to change the DIRn each time i want to switch from reat to write and vice versa?
[05:38:39] <RattusRattus> PHPtest: yes when you have the pin as an output you can read the IN register (and that is what I suggest you read when driving your outputs - to confirm when you asser a line it is in the state you want it to be in) however when you are NOT trying to write on a bi-directional line (i.e. most of the time) you should make it an INPUT with no pull up or pull down) that way the line floats and can be driven by your partner devices. physically fit pull up resi
[05:38:48] <twnqx`> PHPtest: yes, you have to switch every time
[05:38:59] <RattusRattus> edmont: I am assuming you ar linking to more than one lib?
[05:39:26] <PHPtest> thank you guys, that cleared it up
[05:39:28] <edmont> RattusRattus: yes, we are using Contiki OS
[05:43:06] <RattusRattus> edmont: so dont you need somthing like: gcc program.o -llib1 -Wl,-Bstatic -llib2 -Wl,-Bdynamic -llib3
[05:44:39] <edmont> RattusRattus: mmm, not sure, but before it was working like it is :)
[05:45:06] <gcanada> and it stills works fine if i use avr-gcc-4.5.3 xD
[05:45:15] <gcanada> but if i change...
[05:45:51] * RattusRattus is no expert but I wouldn't be at all supprised if you need to make changes to a linker script if you change the tool chain.
[05:47:01] <edmont> :)
[06:59:55] <antto> wut
[07:00:31] <antto> freenode lets nicknames begin with digits? O_o
[08:07:36] <malinus> antto, no
[08:08:31] <antto> then there's a ghost in the channel
[08:18:33] <superware> does it make sense that an SPI slave without an SS line (single slave) might be stuck and eventually out-of-sync with the master clock? if the master was reset, the clock might stop in the middle of a transfer etc..
[08:18:57] <twnqx`> spi has a reset condition iirc
[08:19:37] <superware> twnqx`: i'm using an attiny2313 as the salve (USI)
[08:19:57] <twnqx`> never used avrs as slave, sorry
[08:21:08] <superware> I see
[08:21:15] <edmont> RattusRattus: we found out that the problem is not with memory sections but with variable locations inside the memory section. We have declared 3 variables inside the EEPROM section, and the order they were placed was the order they are declared in the .c file. However, with the new toolchain, the order is reversed
[08:26:14] <RattusRattus> ahh non portable code :-) the toolchain can put data where it wants to. thats why its good to declare a storage struct for variables in NV memory. but great news in getting it working :-)
[08:39:09] <edmont> hahha, RattusRattus, yes actually the 3 variables are structs with lot of variables inside
[08:39:27] <edmont> but there is no option for ordering them?
[08:58:07] <RattusRattus> edmont: only if you axplicityly store the data fixed memory offsets (i.e. in an outer structure)
[08:58:31] <edmont> i see...
[08:58:52] <RattusRattus> just throwing 'global variables at a compiler means that the compiler is free to chouse where it stores them
[08:59:41] <RattusRattus> only in this case you have specified it must be stored in the eeprom region - you have still left the exact location upto the compiler to decide
[09:09:59] <hetii> Hi :)
[09:10:58] <umquant_> hi
[09:39:31] <superware> I'm trying to setup an SPI connection with atmega328p as master and attiny2313 as slave. I'm directly connecting MOSI/MISO/SCK to DI/DO/UCSK, is this the right setup?
[09:43:35] <umquant_> Yup. MOSI->SDI MISO->SDO SCLK->SCK SS->CS
[09:44:22] <superware> attiny2313 has SCL/DO/DI, no CS
[09:45:29] <umquant_> Oh really? Whoops! How do you enable or disable it like you would on any other slave periph?
[09:46:01] <superware> there's no SPI support, it can be imeplemented using USI
[09:48:01] <umquant_> oh okay. Thanks for the info!
[11:46:48] <malinus> why is the atmega168 more expensive than the 328? Becauase of arduino?
[11:49:17] <OndraSter> depends on where..
[11:53:23] <twnqx> 168: 2.40€-3.05€, 328: 2.55-3.10
[11:53:27] <twnqx> depending on model
[12:42:59] <hetii> I have such code:
https://ideone.com/B2NwnM there it return 12695059 what is true, on atmega8 i get instead 12629523
[12:43:36] <hetii> I try use instead unsigned long uint32_t but with the same result.
[12:47:35] <antto> hetii for what reason do you do the bitshifting/masking/adding/multiplying?
[12:50:05] <hetii> antto: I recive from uart 5 bytes that represent RFID token, only 3 of them are used to get id of the card, so at the end of the day i use my method to change 3 hex byte into one decimal value.
[12:50:33] <antto> wait
[12:50:38] <antto> 3 _hex_ bytes?
[12:51:00] <hetii> general 3 bytes.
[12:51:55] <hetii> like 0xc1 0xb6 0x13
[12:52:11] <antto> well, afaik, ((b[2] >> 4) & 0x0F) * 16 + (b[2] & 0x0F) basically does nothing
[12:52:19] <antto> except for wasting time
[12:54:12] <hetii> antto: yep indeed here you have right
[12:54:25] <antto> you might as well do something like: uint32_t tmp = (b[2]<<16) | (b[1]<<8) | b[0];
[12:54:42] <antto> i'm not sure about the byte order, experiment there
[12:55:18] <hetii> ((b[2]<<16) | (b[1]<<8) | b[0]) -> 1291969
[12:55:31] <hetii> and i should get 12695059
[12:56:41] <antto> yes, so, reverse the byte order
[12:57:05] <antto> (b[0]<<16) | (b[1]<<8) | b[2]
[12:57:07] <hetii> hmm :)
[12:57:11] <hetii> indeed work :>
[13:00:48] <hetii> hmm
[13:01:01] <hetii> error: left shift count >= width of type [-Werror]
[13:01:28] <hetii> when i try compile it and declare i as uint32_t
[13:01:59] <antto> maybe try:
[13:02:37] <antto> ((uint32_t)(b[0])<<16) | ((uint32_t)(b[1])<<8) | b[2]
[13:02:48] <antto> or with a temp var
[13:04:01] <antto> uint32_t t = b[0]; t = (t << 8) | b[1]; t = (t << 8) | b[0]; return t;
[13:04:12] <antto> ehm, b[2] at the end
[13:08:28] <hetii> antto: Jupi :) when I cast all buf values to uint32_t then have what I need :D Thx a lot :D
[14:57:23] <malinus> OndraSter, I'm only looking on ebay/chinese vendors
[14:57:44] <malinus> I like keeping my electronics hobby cheap :)
[14:57:59] <malinus> and they do have the best customer service on earth