Back
[00:53:32] <Kevin`> yay, I have an xmega device blinking an led at 0.5 hz
[00:54:00] <Kevin`> I haven't really figured out how to use avrstudio 5 properly though :/
[01:25:24] <vectory> Kevin`: additional knowledge should come when needed
[01:36:05] <Casper> if only it was that easy
[01:36:10] <Casper> I need knowledge for smps
[01:36:16] <Casper> and I can't figure out anything
[03:31:31] <Kevin`> http://pastebin.com/tP4Nygjz - so, who has the most complicated led blinker? :/
[03:32:17] <Kevin`> registers are a bit weird, having only used the tiny/mega chips
[03:32:24] <doublebeta> Polymorphic ASCII blinker gogogo
[03:33:17] <doublebeta> (please don't do this on an AVR; it's certainly one way to ruin your flash)
[03:33:50] <doublebeta> actually, it's practically impossible to perform polymorphic code on AVR.
[03:34:26] <Kevin`> i'm not sure you are using the same definition for polymorphic that I am
[03:34:58] <Kevin`> in some ways it's actually really common in embedded code
[03:35:35] <doublebeta> http://en.wikipedia.org/wiki/Polymorphic_code
[03:35:42] <doublebeta> 'code that modifies itself'
[03:37:29] <doublebeta> I was specifically referring to performing something similar to
http://www.phrack.org/issues.html?issue=57&id=15
[03:44:25] <Kevin`> oh I love looking at stuff like that
[03:44:40] <doublebeta> Phrack is awesome
[04:11:36] <karlp> thta wikipedia article has a different definition of polymorphic to me too.
[04:14:10] <karlp> this is the one I normally think of,
[04:14:12] <karlp> http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
[04:15:34] <mrfrenzy_> doublebeta: it will take many months/years to kill your flash, there have been a few tests
[04:17:22] <karlp> mrfrenzy_: hah
[04:17:26] <karlp> 10000 writes
[04:17:29] <karlp> you may get more,
[04:17:33] <karlp> but don't bank on it
[04:17:47] <karlp> no matter some dude's write test with an lcd and a counter says
[04:18:22] <karlp> being able to write and read the same thing back 2 seconds later, at 25C is not the same as being able to write, and get the same thing back 10 years later at 85C
[04:20:01] <mrfrenzy_> certainly, I would never rely on it for anything important
[04:20:11] <mrfrenzy_> but for a fun short-life test project
[04:28:44] <doublebeta> mrfrenzy_: yah... I'm used to the atmega family which seem to only guarantee 1000 write cycles
[04:28:58] <doublebeta> 1000 write cycles you can easily power through in a day, I'd imagine
[04:29:10] <karlp> doublebeta: that must be old megas,
[04:29:21] <karlp> all the current ones specify 10k for flash, 100k for eeprom
[04:29:25] <doublebeta> IIRC even the '328 is like that
[04:29:33] <karlp> no, 328 is 10k flash, 100k eeprom
[04:29:37] <doublebeta> ah
[04:29:38] <karlp> so is 32u4
[04:30:16] <karlp> but yeah, even 100k writes for eeprom can be powered through pretty quickly.
[04:30:29] <doublebeta> yeah :)
[04:30:45] <karlp> I'd like to find some time to do some experiments with doing eeprom saves whenthe BOD goes off,
[04:30:55] <doublebeta> righto, I gtg for a while; Merry Christmas
[04:31:04] <karlp> rather than writing every X seconds, and doing paged writes
[04:31:08] <karlp> merry christmas
[04:31:44] <doublebeta> Heheh, it would be interesting to keep the voltage level juuuust below the recommended eeprom write level, and just see which bits fail
[04:32:15] <karlp> no. no it wouldn't :|
[05:01:46] <doublebeta> What's not cool about studying the unpredictable and chaotic destruction of things?
[05:06:35] <norbi> hello:)
[05:06:36] <norbi> http://imageshack.us/f/543/puttymyapp.jpg/
[05:06:47] <norbi> look at this please if you have a bit time
[05:07:39] <Kevin`> looks like a bunch of numbers
[05:07:45] <norbi> on the left side is putty outputting x0,x1,y0,y2,z0,z1
[05:07:57] <norbi> the same on the right side but that is my app
[05:08:32] <norbi> top is when x axis has 1g and z has 0g aprox
[05:08:41] <norbi> on bottom is the reverse of this
[05:08:47] <norbi> there are some similarities
[05:09:32] <norbi> but if i do x=x1<<8 | x0; then the number will be not the original number
[05:09:41] <norbi> that was split in these 2 bytes
[05:10:30] <norbi> why is that?
[05:10:34] <Kevin`> well it'll be "backwards", of course, x1x0
[05:10:39] <Kevin`> but I would expect it to be the same
[05:11:24] <norbi> Kevin`: yes, by backwards you mean x1<<8|x0
[05:11:25] <norbi> ?
[05:11:51] <Kevin`> right, on the display there you are printing out x0 then x1
[05:12:10] <norbi> Kevin`: right
[05:12:11] <Kevin`> if you printed out x in a sane way (which isn't guaranteed) you would get x1 x0
[05:12:25] <norbi> but i do calculate x1<<8 |x0
[05:12:34] <norbi> the order is the same im getting from the acc
[05:12:43] <norbi> but in calculation it is backwards
[05:13:05] <norbi> for example im splitting 255 in two bytes
[05:13:10] <norbi> i know that fits 1 byte
[05:13:15] <norbi> but it must be in two
[05:14:00] <norbi> so, 255 should be 00 FF?
[05:14:12] <Kevin`> depends how you are displaying it
[05:14:19] <norbi> hmm
[05:14:26] <norbi> Kevin`: ?
[05:16:18] <Kevin`> some methods (eg hexdump default) display things as words with reverse ordering
[05:16:27] <norbi> 283 should be FEE3
[05:17:04] <norbi> Kevin`: but im sending pure bits in bytes
[05:17:05] <Kevin`> why don't you just print it as "283", btw
[05:17:24] <Kevin`> norbi: but that's not how you are displaying it
[05:17:35] <norbi> im sending over serial port 1byte containing the bits
[05:17:48] <norbi> Kevin`: you may have some point here
[05:18:04] <norbi> because the calculations fits the displaying
[05:18:19] <norbi> im getting even by calculations very high numbers
[05:18:35] <norbi> and the numbers should be max 300
[05:18:55] <Kevin`> um
[05:18:55] <norbi> so probably on sending side is correct, because it sends bytes
[05:19:05] <Kevin`> since the x= caluclation is done on the avr
[05:19:08] <Kevin`> what's the point of it?
[05:19:21] <Kevin`> if you are sending bytes over the uart, you'd just send x0 then x1
[05:19:25] <norbi> but on receiving the calculations of the 2 raw bytes, gives values that fits the displayed values
[05:19:32] <norbi> yes
[05:19:37] <norbi> exactly what im doing
[05:19:49] <norbi> im sending x0,x1
[05:20:07] <norbi> but the values are too high, dont fit
[05:21:08] <Kevin`> how can they not fit, they are one byte each
[05:21:16] <norbi> exactly
[05:21:39] <Kevin`> you just said it
[05:21:42] <Kevin`> and it's your code
[05:22:06] <norbi> this is why i dont understand why instead of 300 is displayed 10000 for example
[05:23:12] <Kevin`> did you tell the display code to interpret things as unsigned integers?
[05:23:41] <norbi> no, they are signed
[05:23:48] <norbi> im even getin` -12000
[05:23:51] <norbi> for example
[05:24:08] <Kevin`> um, the examples you were giving before were unsigned. eg 0x00FF = 255
[05:24:17] <norbi> the display code is not uint16, but int16
[05:24:44] <norbi> FF01
[05:24:45] <Kevin`> are you sure that's correct? it doesn't sound correct
[05:25:03] <norbi> FF 01 should give -255
[05:25:52] <norbi> im giving you a print screen of the values in dec for example
[05:25:54] <norbi> just a sec
[05:28:36] <ziph> 255 is 0x00ff
[05:28:48] <ziph> To get negative you invert each bit and add one.
[05:29:01] <ziph> 0xff00 is the bits inverted, 0xff01 is with one added.
[05:30:05] <Kevin`> norbi: anyway, are you sure the adc outputs signed numbers? that's rather unusual and doesn't fit with what you were saying before
[05:38:16] <norbi> http://imageshack.us/f/193/puttyvsme.jpg/
[05:38:38] <norbi> here is putty displaying the bytes formatted by the mcu with printf
[05:38:49] <norbi> then my app on the rightside
[05:39:21] <norbi> displaying formatted the bytes(not printf() sent by mcu,just simple byte)
[05:39:36] <norbi> first line are x0,x1,...z1
[05:39:48] <norbi> second line is x1<<8|x0
[05:39:56] <norbi> and y,z
[05:41:43] <norbi> maybe you can see trough the numbers, i cant really see the problem
[05:43:43] <Kevin`> so you have two serial ports?
[05:43:54] <norbi> Kevin`: no
[05:44:01] <norbi> firtsly reading with putty
[05:44:25] <norbi> there is a pattern in putty, the numbers are not bigger than 300 on aprox 1g
[05:44:37] <norbi> if there is a fast acc then it may be bigger
[05:44:39] <norbi> 1000 for ex
[05:44:41] <norbi> but
[05:44:46] <norbi> on the other side
[05:45:00] <Kevin`> why are you displaying the individual bytes as signed integers?
[05:45:02] <norbi> after putty, im sending pure bytes and reading them with display app
[05:45:04] <Kevin`> that's nasty
[05:45:30] <Kevin`> nasty because it doesn't correspond to anything
[05:45:32] <norbi> Kevin`: ahh yea
[05:45:39] <norbi> you are right
[05:45:40] <norbi> just a sec
[05:45:41] <norbi> :D
[05:46:18] <norbi> how should i display it ? hex?
[05:46:24] <norbi> %02x?
[05:46:51] <Kevin`> are the numbers the mcu is displaying completely correct?
[05:46:56] <norbi> yes
[05:47:27] <Kevin`> so either your app is receiving them wrong, or it's parsing them wrong
[05:47:56] <norbi> Kevin`: exactly, but the difference between the 2 sendings are:
[05:48:03] <Kevin`> remember that int might not be 16 bit
[05:48:12] <norbi> when sending to putty it sends char formatted by printf()
[05:48:22] <norbi> when sends to my app it sends pure bytes
[05:48:43] <norbi> Kevin`: im using int16
[05:51:53] <norbi> Kevin`: maybe if i would not sending bytes, but printf("%o",x0)? should make some difference?
[05:52:37] <norbi> is there any differnce by sending byte or printf(%o)?
[05:53:18] <Kevin`> sending ascii takes more bandwidth and you have to do different parsing to turn it back into a number
[05:53:28] <Kevin`> why o?
[05:53:41] <Kevin`> I would just send it as space delimited numbers
[05:53:48] <Kevin`> then you can use both eyes and scanf to read it
[05:54:02] <Kevin`> assuming you don't care about efficiency
[05:56:05] <norbi> Kevin`: if im sending it with printf and parsing it, then its ok
[05:56:18] <norbi> but if i send them just as bytes, its not anymore
[05:56:44] <Kevin`> cuz your doing it wrong
[05:57:07] <Kevin`> how are you identifying which byte is which, btw?
[06:01:14] <norbi> im sending a start string, to catch up with the mcu
[06:01:22] <norbi> mcu sends > 's'
[06:01:42] <norbi> if 's' is received then the display code starts to listen
[06:01:59] <Kevin`> s could be part of the data too
[06:02:03] <norbi> then mcu sends 6 bytes in order x0----z1
[06:02:15] <norbi> display code reads 6 bytes, then again 6 bytes
[06:02:31] <norbi> how could be s part of the data?
[06:02:53] <norbi> i understand what are you saying
[06:02:56] <Kevin`> s is 115
[06:03:06] <norbi> but mcu sends just 1 time the s
[06:03:12] <norbi> at the begining
[06:03:29] <norbi> then comes a delay of 1 sec before sending the next 6 bytes
[06:03:54] <norbi> but after sending the next 6 bytes there is no more delay or separator
[06:04:34] <norbi> so this way: 's' then 1 second delay then byte1,b2---byte,b2----------to infinite
[06:05:10] <Kevin`> you could lose framing on the infinite part and it wouldn't recover
[06:06:43] <Kevin`> anyway, is the problem parsing or displaying? you have the ability to have the application display bytes, and I assume you have
[06:06:52] <Kevin`> receiving or displaying*
[06:07:17] <norbi> using c++ dunno, c++ doesnt have binary
[06:07:38] <Kevin`> yes it does
[06:08:09] <Kevin`> for starters you have all of the normal c functions, and there's some c++ specific ones too
[06:08:31] <norbi> int i = 8; char a[10]; itoa(i, a, 2);
[06:08:38] <Kevin`> and if it doesn't have "binary", how are you reassembling the data? no bit shifts? ;p
[06:08:55] <norbi> i mean it doesnt have binary type
[06:09:11] <Kevin`> you said you were using int16
[06:10:21] <Kevin`> also iirc itoa,atoi aren't part of a standard. or maybe one of them. I avoid that whole range anyway
[06:11:00] <norbi> ok
[06:11:58] <Kevin`> displaying the binary values as hex would be the simplest
[06:13:35] <norbi> std::cout << std::bitset<std::numeric_limits<unsigned short>::digits>(8);
[06:14:08] <Kevin`> eh? what's that do
[06:14:16] <norbi> displaying the bits
[06:14:23] <norbi> in binary
[06:15:34] <norbi> here is a way that i have verified that bytes are not lost and the ordering is fine too
[06:16:17] <norbi> i was sending 0x61 ... 0x66 purly bytes to the display code, and it has received abcdef
[06:17:06] <Kevin`> is there a particular reason you never pasted up the code?
[06:17:14] <norbi> so ordering is fine, probably the formatting or something is wrong
[06:18:14] <norbi> Kevin`: ive pasted the code lot of times, here it is: avr code
http://codepad.org/VUP3lLOm and display code:
http://codepad.org/CYFBLtvk
[06:21:44] <Kevin`> print buffer as binary/hex, x/y/z as binary/hex and x/y/z as int, and compare
[06:22:00] <Kevin`> assuming you haven't done so already
[06:23:30] <norbi> Kevin`: i have
[06:23:39] <Kevin`> and?
[06:23:39] <norbi> i have printed buffer in many ways
[06:24:03] <norbi> i will send you the printscreen
[06:24:05] <norbi> just a sec
[06:24:19] <Kevin`> i'd kind of rather you just say where the problem is
[06:24:22] <norbi> Kevin printf buffer as %x or %02x?
[06:24:24] <Kevin`> paste it if you want
[06:24:49] <Kevin`> it doesn't matter, whatever is more readable
[06:28:54] <norbi> http://imageshack.us/f/198/mydisplay.jpg/
[06:29:28] <Tom_itx> norbi did you get it working?
[06:29:32] <norbi> printf("%02x %02x %02x %02x %02x %02x\n",buffer[0],buffer[1],buffer[2],buffer[3],buffer[4],buffer[5]);
[06:29:32] <norbi> printf("%04x %04x %04x\n",x,y,z);
[06:30:22] <norbi> Tom_itx: no, i cant get it working, i mean i just cant figure out if there is just formatting issue, or c++ types may differ or alterate the original byte or dunno
[06:30:28] <norbi> mcu sends it correctly as how i can see
[06:30:39] <Tom_itx> http://tom-itx.dyndns.org:81/~tom-itx/irc/logs/%23avr/2011-12-15.html
[06:30:41] <norbi> but.. i just cant get it display normally
[06:30:46] <Tom_itx> read the bottom part of that
[06:31:22] <Tom_itx> [16:43:27] <norbi> good night
[06:31:26] <Tom_itx> after that line
[06:31:43] <Tom_itx> norbi: i think i'd change x y and z to int16 and data to int8 then typecast: x = ((ushort)data[1]) << 8 | (uchar)data[0];
[06:32:14] <norbi> Tom_itx: ohh!
[06:32:21] <Tom_itx> ushort will move data[1] to 1111111100000000
[06:32:25] <norbi> im sorry that ive gone, didnt expected any result
[06:33:00] <Tom_itx> your types weren't right either i think
[06:33:24] <Tom_itx> something to try anyway
[06:33:44] <norbi> Tom_itx:
http://mbed.org/users/aberk/libraries/ADXL345/leab9k/docs/ADXL345_8cpp_source.html this is fine for me, but i think im having the basics almost the same
[06:34:58] <norbi> i will try to look after the types
[06:35:08] <Tom_itx> that is for arm and default int for arm is 32bit
[06:35:21] <Tom_itx> int for avr is 16bit
[06:35:26] <Tom_itx> char is 8 iirc
[06:35:33] <Kevin`> norbi: in your paste, what's the 32bit hex number?
[06:35:45] <norbi> Kevin`: i cant figure out
[06:35:56] <norbi> z is defined as int16
[06:36:11] <Tom_itx> also they put a delay in there that you may be missing
[06:36:12] <Kevin`> norbi: oh I think I know what the problem is
[06:36:16] <norbi> printf(%04x,z) given that value
[06:36:21] <Kevin`> norbi: printf is expecting an int, not an int16
[06:36:48] <Tom_itx> Kevin`, what size is int in avr? 16... no?
[06:36:56] <norbi> Kevin`: im doing cout<< but the same thing happens
[06:36:59] <Kevin`> Tom_itx: this is windows crap
[06:37:05] <Tom_itx> oh
[06:37:20] <norbi> Tom_itx: im prety sure that on avr side all is fine
[06:37:28] <Tom_itx> mkay
[06:37:31] <Tom_itx> i'm not
[06:37:35] <norbi> why?
[06:37:46] <Tom_itx> if it works it works
[06:37:55] <Tom_itx> i haven't seen the latest i suppose
[06:37:57] <norbi> Tom_itx: but tell me why
[06:38:17] <norbi> i shouldnt use uint8? i should use int8?
[06:38:25] <norbi> for x0,x1...z1?
[06:38:27] <Kevin`> norbi: doesn't matter
[06:38:30] <Tom_itx> same thing
[06:38:33] <Kevin`> since you aren't doing math on it
[06:38:35] <norbi> Kevin`: yea so
[06:38:43] <norbi> ?
[06:38:53] <norbi> what would be the problem on the avr side?
[06:38:56] <Tom_itx> it should be ok
[06:39:02] <norbi> ok
[06:41:56] <Tom_itx> norbi, that cpp example defines all the registers for you too
[06:42:33] <Kevin`> that's all on the avr side
[06:42:41] <Tom_itx> yep
[06:42:47] <norbi> Tom_itx: does avr gcc know c++?
[06:42:53] <Tom_itx> but he's not using all of em right now
[06:43:00] <norbi> Tom_itx: i will
[06:43:01] <Tom_itx> it does but i'd convert it to c
[06:43:21] <Kevin`> norbi: not full c++, but much of it. you probably don't want to use any of the class stuff.
[06:43:36] <Tom_itx> i posted it more for the defines
[06:43:40] <norbi> Kevin`: yea probably converting it would be easy and better
[06:43:53] <norbi> thanks Tom_itx
[06:43:55] <norbi> i will use that
[06:44:04] <Kevin`> that stuff is all in the datasheet, but readable defines is nice
[06:44:13] <Tom_itx> i know
[06:44:54] <norbi> on windows side or c side i would need some help from #c channel but they are mostly refusing help undil you are not giving some testcase and they dont understand that i want to do more like avr not some big programming
[06:45:15] <Tom_itx> you won't get help from #c
[06:45:22] <Tom_itx> they're assholes
[06:45:27] <norbi> yea much of
[06:45:38] <norbi> on avr people are mostly helpfull
[06:45:51] <Tom_itx> rue could help
[06:45:53] <norbi> but when i go on other channels, people act like jerks
[06:45:57] <Tom_itx> but he's asleep
[06:49:45] <norbi> are you guys thinking this may be an endianness error?
[06:49:54] <norbi> or just simple format error?
[06:50:19] <Tom_itx> assign a value to the var and look
[06:50:26] <Kevin`> afair bit shifts are endianness-agnostic
[06:50:27] <Tom_itx> see if it goes where expected
[06:51:26] <Tom_itx> instead of guessing on changing data
[06:51:27] <Kevin`> (which seems strange, hopefully someone with more c knowledge and no pedantry will explain why)
[06:52:02] <Tom_itx> data[1] = 0xFF
[06:52:10] <Tom_itx> data[0] = 0
[06:52:12] <Tom_itx> test it
[06:52:32] <Kevin`> there is one issue though, printf expects ints
[06:52:50] <Kevin`> which is probably 4 or 8 bytes (check)
[06:53:30] <Kevin`> you need a seperate workaround for it to use the standard data types
[06:54:57] <norbi> im testing
[06:54:58] <Kevin`> the compiler WILL yell at you for doing that, though
[06:55:01] <Kevin`> probably even microsoft's
[06:55:09] <Kevin`> as a warning of course, since it's not an error
[06:55:37] <Tom_itx> Return values: 8-bit in r24 (not r25!), 16-bit in r25:r24, up to 32 bits in r22-r25, up to 64 bits in r18-r25. 8-bit return values are zero/sign-extended to 16 bits by the called function (unsigned char is more efficient than signed char - just clr r25). Arguments to functions with variable argument lists (printf etc.) are all passed on stack, and char is extended to int.
[06:57:28] <Tom_itx> http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gaa3b98c0d17b35642c0f3e4649092b9f1
[06:57:39] <norbi> Tom_itx: it displays 255
[06:58:21] <Tom_itx> for the data[1] test?
[06:58:27] <Tom_itx> flip the values and try it again
[06:58:40] <Tom_itx> [1] =0 []0]=1
[06:59:37] <norbi> -256
[07:01:24] <Bushman> ave
[07:01:28] <norbi> so formatting is ok?
[07:01:31] <norbi> Bushman: ave
[07:01:46] <Bushman> any one of you guys used some ethernet modues for avr?
[07:01:49] <Kevin`> norbi: I want to see you print out each step properly
[07:02:07] <Bushman> i've bought this one: ENC28J60, is it any good?
[07:02:46] <Kevin`> I have one of those, but I haven't used it yet. there's code support for it, and it's one of the few spi devices you can get that does normal ethernet
[07:03:40] <Bushman> yea, i've seen there are demos for 8051 and ATmega
[07:04:20] <Bushman> i'm just wondering if any one of you have a working project on it so i can, you know, like test-ride it :P
[07:08:10] <norbi> Bushman: it is very good!
[07:08:21] <norbi> Kevin`: im doing it sep by step
[07:09:50] <norbi> Kevin`: im printig it this way: printf("%6d %02x %02x %6d %02x %02x %6d %02x %02x\n",x,x0,x1,y,y0,y1,z,z0,z1);
[07:13:14] <Bushman> norbi: you have something working on it?
[07:13:35] <norbi> http://imageshack.us/f/684/serialreading.jpg/
[07:14:01] <norbi> Bushman: i did have a webpage, if i remember well that is an ethernet chip, right?
[07:14:18] <norbi> Kevin`:
http://imageshack.us/f/684/serialreading.jpg/ this is the printout in case im rotating the accmeter
[07:14:55] <Kevin`> which numbers don't match the binary value next to them?
[07:14:56] <Kevin`> pick one
[07:15:00] <Bushman> norbi: on what µC?
[07:15:23] <Tom_itx> what does arduino use for it's ethernet chip?
[07:15:36] <Kevin`> Tom_itx: which arduino comes with an ethernet chip?
[07:15:42] <Kevin`> I thought all of that was addons
[07:15:50] <Tom_itx> it probably is
[07:16:37] <norbi> but if i let it, not touching the acc it gives me this:
http://imageshack.us/f/85/serialreading.jpg/
[07:16:50] <norbi> this looks normal, but touching the device gives me bad numbers
[07:16:51] <Kevin`> some of the arduino stuff uses the wiznet controller, which IMO is less flexible (it has an ip stack of some sort)
[07:17:18] <norbi> so there can be 2 problems: 1 formatting data, but im starting to beleive there is no problem
[07:17:45] <norbi> or byte delays causing the spi processing
[07:18:03] <norbi> and to test that i have a solutin
[07:18:22] <norbi> instead of putting the reading values i will put my own values
[07:18:34] <Steffanx> Yay
[07:18:41] <norbi> to see if spi causes the delay or byte loss
[07:18:46] <norbi> Steffanx: hi
[07:18:51] <OndraSter> yo hi
[07:19:23] <norbi> Bushman: ive using it with pic32mx, because pic has a lib for that ic
[07:19:37] <norbi> used*
[07:19:43] <norbi> not anymore
[07:20:14] <Tom_itx> Bushman,
http://wtfmoogle.com/ has used it
[07:20:22] <Tom_itx> he had a webpage up with one once
[07:21:11] <Kevin`> looks like you CAN use the wiznet controllers with raw ethernet frames, if you want to, so either would probably be usable
[07:22:40] <Bushman> Tom_itx: has, as in a past tense, right?
[07:23:03] <Bushman> does anyone has a working project atm?
[07:23:08] <norbi> so
http://codepad.org/SntbBytF this code is fine reading spi? data=SPDR may lose bits, right?
[07:23:24] <Kevin`> Bushman: does it have to be someone online right now? there's tons of projects using it
[07:24:13] <Kevin`> norbi: data=SPDR should not lose bits, unless you tried to use at the same time you were transferring data perhaps
[07:26:09] <norbi> but on datasheet simple receiving writes this: while(!(SPSR & (1<<SPIF))) data=SPDR
[07:26:41] <norbi> so firstly i need to send address, then read
[07:28:08] <Kevin`> it's probably waiting for the transfer to complete (I don't want to look up those registers). I assume your send_byte function is waiting instead of returning immediately from how it was used before
[07:28:32] <Kevin`> why do YOU think you could lose bits?
[07:29:08] <Bushman> Kevin`: well, it's always easier to ask stupid questions to someone who's listening than to someone who's not around :P
[07:33:38] <norbi> sendbyte yes is waiting
[07:33:45] <Kevin`> why do YOU think you could lose bits?
[07:34:28] <Kevin`> using one of those wiznet chips on a device with an external bus interface would be interesting. but so many wires :/
[07:35:15] <norbi> hah
[07:35:18] <norbi> its fine now :d
[07:35:20] <norbi> wow
[07:35:30] <norbi> guess where was the problem?:P
[07:35:38] <norbi> im waitingfor bets :P
[07:36:08] <Kevin`> printf use
[07:36:09] <Kevin`> also just say
[07:37:01] <norbi> Kevin`: no:P
[07:37:08] <norbi> i will give you a hint
[07:37:15] <norbi> problem was on avr side
[07:37:32] <Kevin`> but that's not possible, because you confirmed the data coming from the avr was correct
[07:37:50] <Kevin`> just say
[07:38:17] <norbi> Kevin`: yes, it was correct when i tested it sending 6 bytes ordered :D
[07:38:33] <norbi> but didnt tested it by sending 6 bytes ordered whn using spi
[07:38:53] <norbi> spi and uart together maked this problem
[07:39:05] <Kevin`> why?
[07:39:16] <karlp> because the problem was keyboard side?
[07:39:29] <norbi> the problem was that in main loop here:
http://codepad.org/uCy83Qxd
[07:40:14] <norbi> you can observe that ive 0`ed the dx..dz, just to make sure it is empty before putting new data in it, just for debugging
[07:40:24] <norbi> then added an enourmous delay at the end
[07:40:32] <norbi> delay_ms(4000);
[07:41:12] <norbi> now i just have to figure out, how is that delay affects the byte sending, and how does that delay changes its value, what is its optimal value and it changes in function of what
[07:41:32] <Kevin`> you still haven't said what the problem is
[07:41:35] <Kevin`> or how you fixed it
[07:41:46] <norbi> ive just sayed
[07:41:53] <norbi> the problem was the delay missed
[07:41:56] <karlp> he's not been very big on consistent clear information
[07:42:09] <Kevin`> although, if you wanna make it more sane, you should be reading the adc value every time it gives you an interrupt
[07:42:28] <norbi> while(1) was runned fast, it sent bytes fastly on uart one after the other
[07:42:51] <Kevin`> so you were losing framing, like I said before? ;p
[07:42:52] <norbi> i thought it would be a delay after each 6bytes
[07:43:23] <norbi> yes
[07:43:25] <norbi> probably
[07:43:46] <norbi> i want to guess, what would be the optimal value for that delay
[07:43:53] <Kevin`> don't use a delay at all
[07:44:02] <norbi> i will try with 20ms
[07:44:07] <norbi> Kevin`?
[07:44:08] <norbi> why?
[07:44:26] <norbi> use uart with interrupts?
[07:45:00] <Kevin`> read the adc value every time it completes a conversion. fix your framing so you don't need a delay. if you still want it slower after that, stick a software filter on the avr side
[07:45:31] <norbi> im afraid im not understanding
[07:45:33] <norbi> what adc value?
[07:45:54] <norbi> Kevin`: this is on avr side
[07:45:59] <Kevin`> the chip has a rate that it runs it's internal adc at (you can set this). every time it gets a number, read it
[07:46:28] <Kevin`> then, fix your framing so you can't lose sync
[07:46:47] <Kevin`> then, if you still want really slow data like now, filter it so you get better numbers instead of just dropping data like it is now
[07:46:47] <norbi> Kevin`: you lost me
[07:46:56] <norbi> i really dont know what adc
[07:47:07] <norbi> the atmega has adc port
[07:47:09] <Kevin`> adc is analog to digital converter. the accellerometer has one.
[07:47:16] <norbi> ok, but what has that to do with the uart?
[07:47:22] <norbi> ah
[07:47:26] <Kevin`> you are using a digital accellerometer, not an analog one connected to the avr's adc
[07:47:29] <Kevin`> either would work, of course
[07:47:46] <norbi> ah you are taling about the accelerometers adc
[07:47:57] <norbi> read it and send byte
[07:48:18] <Kevin`> it doesn't directly have anything to do with the uart, but the only reason it was working before is because you are sending data so slowly. the correct solution is not to find the correct value of slow that works with your windows api
[07:48:51] <norbi> ok, but adc value is exactly x0,...z1
[07:49:27] <Kevin`> you are polling it at an obscenely slow rate, that's not good for your results
[07:49:31] <norbi> this is the function that access the adc
http://codepad.org/pguc8Mr9
[07:49:48] <Kevin`> you can do it several hundred times per second just fine
[07:50:01] <Kevin`> don't do it continuously though, do it when the chip tells you there's a new number
[07:50:51] <Kevin`> a low data rate there would be fine if you had an analog low pass filter to match it, but you don't, btw.
[07:51:13] <norbi> pff pff im going to read again the datasheet, to see if the chip does inform me when is the new value, or i should do it 300 times/s and not verify
[07:52:07] <norbi> http://www.analog.com/static/imported-files/data_sheets/ADXL345.pdf im reading the datasheet, yet cant find how can i see if there is new byte on spi
[07:52:37] <norbi> but it does say how to read if the master spi clock is set to a value
[07:53:07] <Kevin`> spi is controlled by the microcontroller, there's a new byte whenever you ask for it
[07:53:20] <Kevin`> that's not what i'm talking about though
[07:55:03] <Kevin`> norbi: look at the documentation relating to interrupts and the device's fifo
[08:00:14] <Kevin`> you don't necessarily need the fifo btw, but it might make your code simpler (assuming you don't drop data)
[08:02:35] <norbi> it seems that the problem is not with spi reads and speed
[08:02:38] <norbi> it is the uart speed
[08:03:17] <norbi> values are alterated on uart, not on spi
[08:03:19] <norbi> somehow
[08:03:30] <Kevin`> right, fix your framing
[08:04:22] <norbi> dont know how to fix that frameing
[08:04:37] <norbi> i have to go out, dhl got me something
[08:04:38] <norbi> :D
[08:04:44] <norbi> just 2 minutes
[08:04:46] <norbi> i will be beack
[08:04:58] <Kevin`> the fastest way, although rather inneficient, would be to send it as ascii, one line per sample
[08:05:08] <Kevin`> fastest to program, that is
[08:34:22] <norbi> how can i calculate optimal baudrate?
[08:34:58] <norbi> for example ive selected 115200 baud
[08:35:08] <norbi> how do i know if that is optimal?
[08:37:31] <norbi> and boud rate here means bytes/s?
[08:38:04] <norbi> or bits?
[08:58:22] <jakllsch> bits
[08:58:28] <jakllsch> actually, it means something else
[08:58:42] <jakllsch> but in the context of RS232 ports, it means bits per second
[09:00:03] <norbi> jakllsch: yea i know what it means in other context, im on cisco :P we learn that there
[09:00:13] <norbi> but in this case i dont really know
[09:00:13] <norbi> :D
[09:00:53] <norbi> what is this mean: to deassert the CS pin
[09:01:30] <jakllsch> well, is it active high or active low?
[09:01:35] <jakllsch> basically, make it inactive
[09:01:56] <norbi> i understand
[09:01:58] <norbi> thanks
[09:42:25] <arnet> hey, people, I would like to ask a twi related question
[09:43:53] <arnet> is it normal when I usually get expected response when reading a byte from i2c, and sometimes I get something strange, like 0x55 ?
[10:04:43] <ziph> arnet: Is that the data register value, or a status register?
[10:06:31] <OndraSter> FINALLY
[10:06:34] <OndraSter> found a way how to route it all
[10:06:35] <OndraSter> http://clip2net.com/s/1pfbE
[10:08:18] <jacekowski> i would have done it differently
[10:08:38] <OndraSter> how?
[10:08:49] <OndraSter> those red "dotted" on X axis are markers where to bend it
[10:09:16] <jacekowski> why you have vias there?
[10:09:26] <jacekowski> you can start on red layer
[10:09:31] <jacekowski> and avoid vias
[10:09:49] <OndraSter> ??
[10:09:53] <OndraSter> those vias are from top to bottom
[10:09:57] <jacekowski> yeah
[10:09:58] <OndraSter> every 3rd pin is ROW pin
[10:10:03] <OndraSter> and these are shared on X axis
[10:10:11] <OndraSter> where every 1st and 2nd pin are COLUMN pins
[10:10:14] <OndraSter> and they are shared on Y axis
[10:10:27] <jacekowski> blue is top or bottom?
[10:10:30] <OndraSter> blue is bottom
[10:10:41] <jacekowski> so you can start on top layer
[10:10:52] <OndraSter> ??
[10:10:55] <OndraSter> these are DIP
[10:11:00] <jacekowski> so/
[10:11:03] <jacekowski> exactly
[10:11:11] <jacekowski> each pad for dip is a via at the same time
[10:11:48] <OndraSter> hmm
[10:12:01] <OndraSter> what difference does it actually make?
[10:12:11] <jacekowski> less vias
[10:12:13] <jacekowski> less drilling
[10:12:23] <OndraSter> it's not mine job to drill
[10:12:23] <jacekowski> and most pcb places charge per hole
[10:12:25] <OndraSter> or make dias
[10:12:32] <OndraSter> they charge per hole above some limit
[10:12:35] <OndraSter> which I am over anyway
[10:12:43] <OndraSter> and per 100s I think
[10:12:47] <jacekowski> well, depends on pcb place
[10:12:54] <OndraSter> or this place doesn't charge extra at all maybe
[10:12:56] <OndraSter> would have to check
[10:21:32] <amee2k> how practical is keeping an "hours meter" or other performance counter in built-in eeprom?
[10:38:42] <jacekowski> well, depends
[10:38:52] <jacekowski> how many write cycles it can do
[10:38:54] <jacekowski> 100k?
[10:39:19] <amee2k> current plan is a tiny44 which specifies 100k cycles
[10:39:36] <amee2k> counters have seconds resolution
[10:44:25] <jacekowski> hmm, i wouldn't do that
[10:44:27] <amee2k> what i don't like is trading off counter accuracy vs. eeprom life. i'm not exactly convinced of the whole save-on-power-loss thing
[10:44:29] <jacekowski> not with second resolution
[10:44:59] <jacekowski> have a backup battery and in case it detects loss of main power it will write data to eeprom
[10:45:48] <amee2k> the MCU is on an auxiliary regulator anyway. does the huge bypass cap + external BOD thing work in practice?
[10:54:15] <amee2k> hmm even saving only every 10 minutes only yields an eeprom life of ~2 years :/
[10:54:29] <amee2k> provided the 100k cycles figure is accurate anyway
[10:56:10] <amee2k> how do i determine how much power saving so-many bytes to eeprom will require?
[11:16:30] <x-fak> hello, is there some channel you know to talk about jtag stuff?
[11:19:09] <ziph> You could give this one a try.
[13:08:49] <amee2k> debugwire doesn't allow flashing, right?
[13:09:28] <OndraSter> it does
[13:09:37] <OndraSter> it can write flash
[13:09:48] <amee2k> hmm really?
[13:10:00] <OndraSter> http://www.ruemohr.org/docs/debugwire.html
[13:10:10] <amee2k> what programmer adapter do you need for that? i have an avrisp2
[13:10:10] <OndraSter> there are commands for writing a page
[13:10:42] <amee2k> interresting
[13:11:24] <OndraSter> does avrisp2 support dW?
[13:11:47] <OndraSter> I can see ISP with classic 10 or 6pin header, nothing more
[13:11:52] <amee2k> i've never used it, and i can't find out how to make it use dW for flashing with it
[13:12:21] <amee2k> but still good to know for planning that it works
[13:13:02] <OndraSter> it maybe doesn't know dW at all
[13:13:14] <OndraSter> I see on the web only normal flashing through SPI
[13:16:40] <Steffanx> The avrisp mkii cant do dW
[13:17:49] <amee2k> hmm then i'd have to get/make another programmer for that. it would still sufficienty simplify the circuit to be worth it i think
[13:18:03] <OndraSter> I wish there was some DIY JTAGICE mkII
[13:19:58] <Steffanx> there is one
[13:20:02] <Steffanx> A buggy one
[13:20:10] <Steffanx> and it isn't finished
[13:20:57] <OndraSter> hmm link?
[13:20:59] <OndraSter> I couldn't find it
[13:47:33] <Steffanx> usbprog OndraSter
[13:47:43] <OndraSter> oh thanks
[13:47:57] <Steffanx> I worked on something too.. but it was jtag only
[13:48:03] <OndraSter> I need JTAG only
[13:48:06] <OndraSter> since JTAG can do anything
[13:48:12] <Steffanx> I even erased the signature of my atmega16 with it
[13:48:17] <Steffanx> I still don't know how
[13:48:26] <Steffanx> I did it with 2 m16's actually
[13:49:23] <OndraSter> o_O I thought that signature was hardwired inside
[15:22:51] <RikusW> http://www.yankodesign.com/2011/12/13/im-yo-yo-over-this/
[15:23:59] * RikusW prefers a ps2 mouse...
[15:26:40] <Steffanx> I like the idea
[15:26:46] <Steffanx> I prefer a usb mouse
[15:29:16] <RikusW> wired anyways
[15:29:47] <RikusW> battery powered mice is looking for trouble, flat battery when you need it most ;)
[15:47:00] <glguy> Anyone using avr-libc 1.6.8+ and willing to look at libc/pmstring/strlcat_P.S with me and tell me if line 102 should actually be "SBIW XL, 1"?
[15:47:38] <glguy> My understanding of this code is that it will fail if the null terminator of the destination pointer mod 256 is 0
[15:48:32] <glguy> or maybe if (pointer mod 256 == 255)
[16:34:59] <Casper> a pointer of 0 should fail
[16:35:05] <Casper> as it is invalid
[16:35:45] <glguy> Casper: if you are responding to me then you didn't understand my concern
[16:37:40] <glguy> The issue is that on that line the "X" register is being treated like an 8-bit variable instead of the 16-bit variable it should be
[16:37:50] <glguy> pointer mod 256 means the low-byte of the variable
