Back
[03:33:21] <DanFrederiksen> anyone know off hand what the differences are between atmega8 and 88 series? does it have new function? or just newer wafer tech
[03:35:13] <inflex> 88 has built in debugging (hardware), vastly lower power consumption
[03:36:08] <inflex> it does have one more instruction, not sure which one though
[03:36:16] <DanFrederiksen> k thx. they could make an atmega8 that's code compatible but execute 16bit native
[03:36:32] <inflex> O_o
[03:36:36] <inflex> not sure what you asked/said then
[03:36:57] <DanFrederiksen> ok thanks..
[03:37:02] <DanFrederiksen> are you leet blind :)
[03:37:33] <inflex> if you want 16-bit, then the xmega is what you're after afaik
[03:37:57] <grummund> only if you believe the hype
[03:37:59] <DanFrederiksen> ok. I only thought they had 8 and 32 bit
[03:38:11] <grummund> s/hype/marketing spin/
[03:38:51] <DanFrederiksen> so no 16bit?
[03:38:54] <inflex> The Xmega has been a bit of a strange one
[03:39:08] <DanFrederiksen> like Ash? :)
[03:39:44] <DanFrederiksen> that's an evil dead reference. philistines :)
[03:39:59] <inflex> about the biggest thing I lust for on the Xmega is the 12-bit ADCs... well, and some other things - but it's not enough to compel me to use it
[03:40:25] * inflex knows Evil dead... come get some.
[03:40:37] <DanFrederiksen> whooooooooooose next? :)
[03:41:09] <inflex> Shop smart, Shop S-Mart.
[03:41:16] <DanFrederiksen> :)
[03:42:52] <inflex> Got to love tha movie
[03:43:02] <DanFrederiksen> he is quite the character :)
[03:43:06] <inflex> Surely one of the highest quotable-dialog movies ever
[03:44:02] <DanFrederiksen> many good one liners yes :)
[03:44:33] <DanFrederiksen> what kind of ADC is on the 32bits?
[03:45:39] <inflex> 10 or 12 depending on the model
[03:46:08] <inflex> Does anyone really actually use the AVR32 for something meaningful? I mean... versus using an ARM or something else?
[03:46:34] <DanFrederiksen> I'm new and only used 8 but why not..
[03:46:52] <DanFrederiksen> powerful chip. can run quake
[03:47:13] <inflex> I've considered getting a couple of AT32UC3L064 's to see what the fuss is about - experiment etc...
[03:47:25] <DanFrederiksen> they are cheap enough
[03:47:37] <DanFrederiksen> 4$ or so
[03:47:42] <DanFrederiksen> wonder if arm is cheaper
[03:47:54] <inflex> yeah, the 36 PWM channels is something that would attract some people
[03:48:02] <grummund> about twice the price of an ARM then :P
[03:48:16] <DanFrederiksen> grummund, also in low volume?
[03:48:49] <DanFrederiksen> I'd like the 32bit math precision. 8 bit is a little confined
[03:49:23] <DanFrederiksen> but chose the 8 to keep it simple and hoping a simpler 8 is more stable
[03:50:25] <DanFrederiksen> does the 88 have a way to set higher default clock without external?
[03:50:33] <DanFrederiksen> higher than 1Mzh
[03:50:35] <DanFrederiksen> MHz
[03:51:09] <inflex> yes, 8MHz it will go to
[03:51:23] <DanFrederiksen> ok that's perhaps also interesting
[03:51:24] <inflex> using the internal RC. You can change that on the fly in software
[03:51:51] <DanFrederiksen> I run 1MHz for stability and power but I'd probably like a little higher for reaction time and sampler
[03:52:01] <DanFrederiksen> I'd really like it if the ADC was per clock
[03:52:07] <DanFrederiksen> that'd be nice
[03:52:14] <DanFrederiksen> 23 cycles is too much
[03:52:26] <inflex> ADCs are a bit of a weakpoint on the AVRs, always has been
[03:52:41] <DanFrederiksen> xmega is better in that regard?
[03:52:42] <inflex> I suppose they figure you should just go use an SPI/I2C one if you want more
[03:52:53] <inflex> yes, Xmega has the 12-bit ADCs, but I'm not sure of the sampling rate
[03:52:56] <DanFrederiksen> nah integration for the win
[03:53:40] <DanFrederiksen> 8 or 10 is ok for my use actually but I'd really like 1MHz ADC
[03:53:56] <DanFrederiksen> 23us is a lifetime in electronics
[03:54:05] <DanFrederiksen> plus calculation
[03:54:52] <inflex> the Xmega ADC is certainly a lot niceer in terms of what you can do... adjusable gain, adjustable 8/12 bits, two individual ADC units
[03:54:58] <DanFrederiksen> plus it's ugly to have to catch the result via interrupt
[03:55:21] <DanFrederiksen> it should just be a register I can read dammit :)
[03:55:35] <DanFrederiksen> and no multiplex nonsense. one ADC per input
[03:55:48] <inflex> looks like Xmega is 3.5us conversion time
[03:55:58] <DanFrederiksen> das war ein befehl! :)
[03:56:02] <inflex> oh, multiplexing is useful - don't knock it ;)
[03:56:16] <DanFrederiksen> better than ADC for each channel?
[03:56:54] <inflex> actually, it can be in one respect, knowing that your results are measured with the same errors
[03:57:07] <DanFrederiksen> naah : )
[03:58:02] <DanFrederiksen> imagine just being able to read a register for a channel and you have the value. no interrupt nonsense, no delay
[03:59:01] <DanFrederiksen> how it should be
[03:59:04] <grummund> depends on the model but xmega adc acn run at up to 2MSa/s
[03:59:33] <inflex> DanFrederiksen: it can be, just run it in 'free running' mode and read the register when you desire
[03:59:38] <DanFrederiksen> that's pretty good but is it still interrupt based? and require cpu clock to be sky high
[03:59:52] <inflex> o
[03:59:53] <inflex> no
[04:00:05] <DanFrederiksen> I meant grummund
[04:00:08] <inflex> ooh ok
[04:00:17] <grummund> interrupt and/or dma
[04:00:54] <DanFrederiksen> in dma the ADC just writes a cyclic buffer in mem?
[04:02:28] <grummund> at 2M it's just about possible to copy out the data in a free-running loop
[04:05:44] <DanFrederiksen> hehe a chip could have a bullet time mode where by command the chip jumps from 1 to 60MHz to quickly handle a critical situation
[04:07:13] <grummund> many micros can do that
[04:07:23] <DanFrederiksen> yay, it was my invention :)
[04:08:48] <DanFrederiksen> is xmega code largely the same as 8 or completely different?
[04:09:18] <RikusW> seems the instruction are the same in binary too
[04:09:35] <RikusW> xmega got the DES instruction extra
[04:10:03] <RikusW> the registers is organized differently
[04:18:16] <DanFrederiksen> RikusW, no native 16bit?
[04:19:02] <RikusW> seems not
[04:19:17] <RikusW> AVR32 does have a mixed IS
[04:19:25] <karlp> do you have existing 16 bit code or applications?
[04:19:26] <RikusW> not looked at it much yet
[04:19:44] <karlp> or an existing team experienced with 16bit micros?
[04:21:02] <devilsadvocate> the msp430 is 16 bit
[04:21:40] <DanFrederiksen> karlp, no it's not a legacy thing. more psychological in real time code that anything 16 bit runs much slower
[04:23:40] <RikusW> why would that be ??
[04:24:05] <DanFrederiksen> why it runs slower? isn't 16bit simulated by multiple 8 bit commands?
[04:24:15] <RikusW> on AVR yes
[04:24:35] <DanFrederiksen> and xmega too right?
[04:24:40] <RikusW> yes
[04:24:45] <DanFrederiksen> then that is why :)
[04:25:02] <RikusW> if you only have a few 16 bit variables it won't matter much...
[04:25:11] <DanFrederiksen> sure true
[04:25:28] <soul-d> din't it have few larger regs for that stuff ?
[04:25:34] <DanFrederiksen> I guess part of it is that I'm not sure how much slower it is
[04:25:59] <DanFrederiksen> if it's exactly 2x it's still countable
[04:26:12] <RikusW> actually AVR8 got an 16bit instruction... movw
[04:26:34] <RikusW> and adiw + sbiw
[04:26:37] <DanFrederiksen> happens in single cycle?
[04:26:51] * RikusW checking
[04:27:16] <DanFrederiksen> I like single cycle everything. and synchronous
[04:27:32] <DanFrederiksen> I'm a control freak :)
[04:27:34] <RikusW> adiw + sbiw == 2
[04:27:38] <RikusW> and movw == 1
[04:27:40] <theBear> single cycles are nice, but at least with avr8 if you have to use a multi cycle one you know how long it will take
[04:28:05] <DanFrederiksen> theBear, always 2?
[04:28:22] <theBear> i forget, but maybe, either way the sheet tells you
[04:29:02] <DanFrederiksen> it doesn't tell me shit. I have to read the whole damned thing :)
[04:29:12] <soul-d> we all did
[04:29:21] <RikusW> add + adc for each 8 bits you add
[04:29:24] <soul-d> and actualy you probably need to read it 4 times
[04:29:29] <theBear> most of us read it a few times, but for a given asm, you just go to that page and it says
[04:29:30] <RikusW> so add adc adc adc for 32 bit
[04:30:20] <RikusW> DanFrederiksen:
http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf
[04:30:24] <theBear> probly not in order tho... i mean i read the timer and clock stuff a bunch of times when i was messing with various pwm and syncey stuff, i went over the adc regs and sections a lot when i was doing adc stuff etc etc
[04:30:49] <grummund> the general problem with 16/32-bit access is not how many clock cycles it requires but the fact that read/write is not atomic
[04:31:06] <theBear> everyone knows atomic commands have the most bang for buck <grin>
[04:31:37] <theBear> hehe einstein is my co-pilot
[04:31:40] <grummund> so you end up having to wrap stuff in cli()... sei()
[04:31:51] <soul-d> http://i.imgur.com/7VHPD.jpg
[04:31:53] <soul-d> look
[04:32:00] <soul-d> no more searching ion datasheet
[04:32:16] <soul-d> oh wait
[04:32:20] <theBear> printed datasheet eh ? fanc-eee
[04:32:41] <DanFrederiksen> grummund, it's related
[04:32:50] <soul-d> actualy i did that myself only once ill tell you that
[04:33:40] <soul-d> but does read better when you have programing windows open and searching for somthing ;)
[04:34:12] <KebabBob> I assume you have just one monitor then? :)
[04:34:38] <soul-d> no 22 and 24 inch wide screens
[04:35:58] <soul-d> i just have 30 + tabs open ad end of the day or somthing but i like reading from paper a bit more then from screen
[04:39:34] <alabd> Good day all , at page 9 of this article
http://wenku.baidu.com/view/9acdca0b79563c1ec5da7172.html?from=rec&pos=0&weight=3&lastweight=1&count=5 , is written to power on Crous PTZ device we should send 12 NULL bytes ... but this AVR (codevision) code
http://pastebin.com/WWycaeWZ does not get respond from Crous device , why ?
[04:39:54] <theBear> what ? simultaneous crossposts ? no no no
[04:41:25] <alabd> theBear: hi would you check question , it's related to the crous device
[04:41:35] <alabd> that we have talked about it
[04:42:21] <theBear> not now, maybe in a bit... other people understand serial handshakes too you know...
[04:43:13] <soul-d> is codevision some kind of compiler no-one wants to use ? also the pastebin is hardly avr code
[04:44:15] <alabd> soul-d: it's part of code , that though it's enough for you understand communication ... does code send NULL byte to device correct ?
[04:45:23] <soul-d> i don't know what it does it does printf wich is scary on avr and has no relation to sending bits on uart
[04:46:26] <theBear> mmmm.... printf is a rough kinda functioney thing in avr-land (at least avr-gcc/avrlibc land) ... just write bytes to the whatsit, use a err, magic-pointer from memory
[04:46:44] <theBear> and by magic i mean, it points at the uart instead of some random mem location
[04:48:03] <alabd> soul-d: theBear see we should send 12 NUll bytes to device to power on it , but our coder says communication is ok , but he is not sure about those 12 NULL bytes
[04:48:33] <theBear> that sentence doesn't make sense, and i told you i'm not thinking serial right now
[04:49:41] <soul-d> me neither thats why a printf statement is so scary :)
[04:51:43] <alabd> see we should send 12 NUll bytes to device to power on it , but our coder says communication is ok and he have used this way to start serial communication for long time so he is sure about seril communication , but he is not sure about those 12 NULL bytes that are sent to device , are they sent correctly ? also he has tested putchar(0); instead of printf(); ...
[04:51:48] <alabd> the same result
[04:51:55] <RikusW> alabd: why not use putc(0) instead ??
[04:52:01] <alabd> issue is about NULL BYTES and protocol ...
[04:52:17] <RikusW> is the baud set right ?
[04:52:22] <theBear> how can he say 'communication is ok' AND 'not sure about those 12 null bytes' ? they are kinda the opposite of mutually exclusive
[04:52:54] <alabd> RikusW: different baud rates have been tested
[04:53:17] <theBear> RikusW, it's a weird handshake, SIMILAR to how dmx does it on rs485... pretty sure the nulls are just a "hello, here i am" kinda thing, THEN the device sends back some stuff to confirm an ACTUAL speed and communication protocol
[04:53:30] <theBear> ie. "nulls for more than X ms"
[04:53:54] <karlp> nothing wrong with printf on avr :)
[04:54:11] <soul-d> but then again my code is from 2009 and ugly first test :P but i've come to conclusion best is to get some measuring devices to get to see it
[04:54:11] <karlp> alabd: if you want nulls, that's not pritnf("%d")
[04:54:16] <RikusW> doesn't it maybe want a break ?
[04:54:57] <RikusW> more like %c ?
[04:54:59] <karlp> are you sure it doesn't just want an idle line for 12 byte times?
[04:55:16] <karlp> printf('\0')
[04:55:37] <alabd> karlp: pleasse look at page 9 at
http://wenku.baidu.com/view/9acdca0b79563c1ec5da7172.html?from=rec&pos=0&weight=3&lastweight=1&count=5
[04:57:27] <karlp> ok, so 12 times printf('\0'),
[04:57:48] <soul-d> is device 16 bits ?
[04:57:50] <RikusW> hi abcminiuser
[04:58:25] <soul-d> i cleary asks for 0x00
[04:59:08] <alabd> karlp: what do you mean of "is device 16 bits ?"
[04:59:28] <alabd> soul-d: what do you mean 0x00
[04:59:59] <RikusW> abcminiuser: I'm having a problem with LUFACDC (101122) bootloader working on XP but giving IO error on Linux.....
[05:00:01] <soul-d> 2.3
[05:00:04] <abcminiuser> Yahoyoy
[05:00:13] <soul-d> note : null charater in ascii format is 0x))
[05:00:17] <soul-d> 0x00
[05:00:20] <abcminiuser> RikusW, got a log?
[05:00:23] <soul-d> wich is a 16 bit
[05:00:26] <RikusW> I think it might be related to the 0x24 descriptors...
[05:00:27] <soul-d> notation
[05:00:31] <karlp> soul-d: which is 8 bit....
[05:00:35] <karlp> 0x00 is only 8 bits.
[05:00:35] <RikusW> abcminiuser: how do I get a log ?
[05:00:57] <soul-d> oh sry
[05:01:02] <soul-d> that early still
[05:01:04] <soul-d> :p
[05:01:10] <karlp> before my coffee too :)
[05:01:15] <abcminiuser> RikusW, where is the error? In AVRDude, the kernel driver, or something else?
[05:01:16] <RikusW> abcminiuser: cannot read or write anything to it on Linux
[05:01:20] <abcminiuser> Ah
[05:01:22] <abcminiuser> dmesg
[05:01:33] <RikusW> minicom won't even open it
[05:01:35] <abcminiuser> Wait, did you try as root?
[05:01:48] <RikusW> but it enumerates as ttyACM0
[05:01:49] <abcminiuser> IIRC the kernel won't mount the device as user accessable
[05:01:50] <alabd> karlp: no respond from device by printf('\0')
[05:02:08] <abcminiuser> RikusW, "sudo cat /dev/ttyACM0"
[05:02:14] <RikusW> tried as root...
[05:02:26] <alabd> karlp: oh it respond one 0
[05:02:35] <alabd> does it mean it's powered on
[05:02:38] <RikusW> cat: /dev/ttyACM0: Input/output error
[05:03:06] <soul-d> ah well to fight this kind of problem i started on a side project to
http://i.imgur.com/0Ciot.jpg
[05:03:21] <soul-d> so i can get my stream stuff out correctly before hooking device up :P
[05:03:24] <alabd> karlp: should not device respond more 0 s ?
[05:03:24] <abcminiuser> RikusW, hrm. Are you using latest LUFA trunk?
[05:03:38] <RikusW> 101122
[05:03:44] <karlp> alabd: you need 12 don't you, not just one...
[05:04:03] <RikusW> abcminiuser: did you have any such issues with LUFACDC before ?
[05:04:04] <karlp> I was just saying to print a "null" you print \0, not "%d", 0
[05:04:38] <RikusW> abcminiuser: when I removed the 0x24 descriptors from my own project it failed on Linux too, so I put it back.
[05:04:48] <soul-d> to clarify karlp " The null character is often represented as the escape sequence \0 "
[05:05:16] <RikusW> abcminiuser: will try loadingthe latest one...
[05:07:02] <RikusW> abcminiuser: I have kernel 2.6.18
[05:08:12] <theBear> 2.6.18 is ANCIENT
[05:08:40] <abcminiuser> Wowza
[05:08:45] <abcminiuser> RikusW, that kernel is older than I am
[05:08:51] <abcminiuser> Anything interesting in dmesg?
[05:09:08] <theBear> .35 is about the oldest "current" kernel, as far as things like udev and other userspace stuff depending on kernel-side stuff rely on
[05:09:30] <theBear> i can still boot a .34, but udev isn't happy about it
[05:09:36] <RikusW> not really
[05:09:50] <soul-d> i run 2.6.35
[05:10:00] <soul-d> fedora 14 still with broken rpm :P
[05:10:07] <RikusW> seems 2.6.18 is a bit finicky about the CDC descriptors...
[05:10:08] <alabd> karlp: yes printf('\0') is sent 12 times and device respond one NUll byte , shouldn't device respond 3 NULL bytes ? please look at page 9 ...there is SEVC-D respond with 3 NULL bytes ..
[05:10:48] <grummund> i very much doubt printf('\0') even compiles.
[05:11:13] <alabd> grummund: compiles ..
[05:12:18] <theBear> you watching optimisation and error output during compile ? sometimes the optimiser is brutal on avr, -O3 might be turning all those nulls into nothing
[05:12:41] <soul-d> -o3 is a bad idea anyhow
[05:13:20] <grummund> alabd: please add -Wall -Wextra -Werror to avr-gcc compile command
[05:14:06] <alabd> oh my God , that's not gcc , it's Codevision
[05:14:28] <soul-d> yeah i had that response on "codevision "
[05:14:29] <theBear> soul-d, i dunno, it helps mplayer a lot :)
[05:14:39] <alabd> and code compiles and is ok
[05:14:47] <alabd> problem is that :
[05:14:53] <theBear> alabd, you sure it's ok ? you looked at the asm ?
[05:15:01] <alabd> printf('\0') is sent 12 times and device respond one NUll byte , shouldn't device respond 3 NULL bytes ? please look at page 9 ...there is SEVC-D respond with 3 NULL bytes ..
[05:15:08] <grummund> alabd: well turn on warnings then
[05:15:28] <theBear> alabd, have you in ANY WAY confirmed that you are sending 12 null bytes to the device ?
[05:15:30] <alabd> theBear: he is a professional coder , code is not problem , we have protool and talking issue
[05:15:44] <grummund> printf('\0') is just plain WRONG, no matter whether it compiles.
[05:15:48] <theBear> ffs, fine then, don't take any advice from people that know better
[05:15:58] * theBear goes to poor another drink
[05:16:02] <theBear> pour ? yeah, that one
[05:16:04] <soul-d> get a profesional measuring device that makes you'r data stream visable
[05:16:20] <soul-d> or a debugger
[05:16:25] <soul-d> simulator
[05:16:28] <karlp> alabd: clearly you _do_ have a code problem.
[05:16:45] <soul-d> if he was a profesional coder would he be using codevision i wonder ?
[05:16:54] <abcminiuser> alabd, that's is definetely wrong
[05:17:05] <abcminiuser> printf() expects a string at a minimum, not a character
[05:17:10] <karlp> I'll take responsbility for that
[05:17:12] <karlp> that was me,
[05:17:15] <karlp> my bad,
[05:17:26] <karlp> but to send a null, you still want \0, not %d with 0
[05:17:41] <abcminiuser> Indeed.
[05:17:42] <karlp> printf("\0\0\0\0\0... 12 times")
[05:17:43] <alabd> so what ?
[05:17:51] <grummund> karlp: still wrong :P
[05:17:52] <abcminiuser> Is RikusW coming back?
[05:18:19] <karlp> grummund: what now?
[05:18:23] <grummund> karlp: you can't put \0 in the format string, it'll just terminate it.
[05:18:42] <karlp> I guess I've never tried :)(
[05:18:46] <karlp> putc?
[05:18:54] * grummund nods
[05:19:21] <soul-d> i woulnd think of printf to start with
[05:19:40] <karlp> soul-d: from looking at the rest of the protocol document, I would have gone for printf too :)
[05:19:54] <soul-d> why ?
[05:20:06] <theBear> most of the protocol doesn't matter till you get past the handshake stage
[05:20:28] <theBear> i'd be tempted to implement the handshake by hand even if i was using printf later once a speed/stop/start/parity had been established
[05:20:50] <karlp> yeah, what the bear said
[05:20:50] <theBear> i really shouldn't remember that document so clearly.... oh the curse of hubris
[05:21:29] <karlp> odd handshake, I guess it's for autobauding?
[05:21:47] <alabd> doc
http://wenku.baidu.com/view/9acdca0b79563c1ec5da7172.html?from=rec&pos=0&weight=3&lastweight=1&count=5
[05:21:52] <alabd> page 9
[05:22:10] <theBear> i assume so... similar one i've seen (dmx protocol/rs485) is more about 'syncing' to the end of a potentially long (approx 44100/th of a second from memory) packet stream
[05:22:13] <alabd> grummund: putchar('\0'); ?
[05:23:05] <theBear> but as you notice, at the end of the handshake you get told the baud, so no doubt, it's for that... the idea (common to both dmx and this) i believe is that nulls for X or larger time kinda look the same at all speeds
[05:23:06] <soul-d> so why use printf ?
[05:23:18] <theBear> 'cos he's got a professional programmer
[05:24:03] <alabd> karlp: putchar('\0'); ?
[05:26:02] <alabd> karlp: grummund do we need MAX232 between AVR and Device ?
[05:27:33] <abcminiuser> Hehe, the AVR Apps team has my countdown on the build server
[05:29:44] <soul-d> k the null bytes send is wakeup and also sets baud speed if one of the accepted it does talk about rs232 port on that page
[05:29:45] <alabd> RikusW: do we need MAX232 between AVR and Device ?
[05:30:12] <RikusW> not sure
[05:30:31] <RikusW> what levels does the device use ? 12V rs232 or logic levels ?
[05:31:04] <alabd> 12 RikusW
[05:31:20] <RikusW> then you need max232
[05:32:37] <alabd> RikusW: but to be sure see page 15
http://wenku.baidu.com/view/4a7689d4b9f3f90f76c61b72.html
[05:34:16] <alabd> and this cod is crous protocol
http://wenku.baidu.com/view/9acdca0b79563c1ec5da7172.html?from=rec&pos=0&weight=3&lastweight=1&count=5 at page 8 and 9 you can see how to talk ...
[05:34:20] * RikusW don't understand 并付出相应财富值
[05:35:09] <alabd> RikusW: can not you see catalog ? you can get it
http://www.4shared.com/document/SpkqyA5x/CORUS_GUIDE_V13_ANG_FAUVE8.html
[05:39:29] <alabd> RikusW: we send 12 NULL in codevision code like putchar('\0'); sending is ok , but regarding to page 9 at crous protocol ,device should respond 3 Null bytes but it responds differents values each time e.g one time 114 064 another time 255 251 and so ...
[05:40:53] <soul-d> did you read page 23 and beyond ?
[05:51:33] <alabd> soul-d: which doc ? protocol ?
[05:53:47] <alabd> soul-d: 23 chart is the same as page 8 chart that mentioned some times
[05:54:52] <alabd> RikusW: karlp grummund we send 12 NULL in codevision code like putchar('\0'); sending is ok , but regarding to page 9 at crous protocol ,device should respond 3 Null bytes but it responds differents values each time e.g one time 114 064 another time 255 251 and so ...
[05:55:49] <RikusW> abcminiuser: just compiled with LUFA 111009, same result
[05:56:09] <abcminiuser> But it works under Windows?
[05:56:16] <abcminiuser> (Same firmware)?
[05:56:24] <RikusW> 101122 works in XP
[05:56:29] <RikusW> but not Linux
[05:56:38] <RikusW> not rebooted to test this one in XP
[05:56:46] <RikusW> guess it will work too
[05:57:43] <RikusW> abcminiuser: I think its the type 0x24 descriptors...
[05:58:30] <RikusW> anyone installed -> avr8-gnu-toolchain-linux_x86 ?
[05:58:42] <RikusW> I set the path, but how do I set the include path ?
[05:58:50] <RikusW> and the lib path ?
[05:59:01] * RikusW don't like editing makefiles...
[05:59:06] <RikusW> echi time
[05:59:09] <abcminiuser> RikusW, can you do a lsusb -vvvv > OUT.txt
[06:01:36] <alabd> any opinion ?
[06:02:31] <RikusW> abcminiuser:
http://pastebin.com/PcMYmuje
[06:03:41] <abcminiuser> cannot read device status, Broken pipe (32)
[06:03:44] <abcminiuser> That's interesting
[06:03:49] <abcminiuser> The driver's horking on it
[06:04:03] <RikusW> http://pastebin.com/Xcq4Gk98
[06:04:17] <alabd> RikusW: device does not respond anthing with MAX232
[06:04:17] <RikusW> this is my U2S board's
[06:04:37] <RikusW> broken pipe too.... but it works
[06:07:36] <alabd> anyway thanks all
[06:10:02] <abcminiuser> RikusW, try chaning the CDC_Functional_ACM capabilities from 0x03 to 0x06
[06:10:13] <abcminiuser> But it really sounds like your CDC driver is horked
[06:11:18] <RikusW> seems like it is
[06:12:48] <abcminiuser> If the capabilities change doesn't fix it, you'll need to fix the CDC driver
[06:12:59] <abcminiuser> Since it sounds like it's using hard coded endpoint addresses or something
[06:14:48] <abcminiuser> Hrm, Atmel has a Call Management descriptor too
[06:14:59] <abcminiuser> But IIRC I removed that, because it isn't actually needed (supposedly)
[06:20:23] <RikusW> abcminiuser: my board does work...
[06:26:14] <abcminiuser> Without more Linux-foo, I can't really tell you why not unfortunately
[06:26:20] <abcminiuser> Unless you know how to debug the kernel?
[06:26:31] <abcminiuser> (Later kernel versions do definetely work with my code)
[06:28:18] <RikusW> Maybe I'll just try modifying the descriptor
[06:28:49] <RikusW> where is USB_CDC_Descriptor_FunctionalACM_t defined ?
[06:29:26] <RikusW> seems common/cdc.h ?
[06:31:03] <abcminiuser> Descriptors.c in the bootloader folder
[06:31:10] <abcminiuser> Oh wait
[06:31:15] <abcminiuser> Yes, that
[06:33:12] <inflex> hiya abcminiuser
[06:33:19] <abcminiuser> Hey inflex
[06:37:22] <inflex> That's about all I had to say
[06:37:44] <Tom_itx> morning
[06:38:05] * inflex finds it interesting that R/C modellers tend to use wire gauges a fair bit smaller for their current carrying that what is specified in most wire gauge sheets
[06:38:06] <abcminiuser> Morning Tom_itx
[06:38:12] <abcminiuser> It's a regular party in here now
[06:38:31] <inflex> I suppose they get away with it because they're usually not going at max amps all the time
[06:38:53] <Tom_itx> inflex, it's lighter and will get hot in air so you can see a firey death
[06:38:57] <inflex> abcminiuser: you missed the fun with crazy_pete the othe rnight
[06:39:14] <abcminiuser> Oh?
[06:39:24] <Tom_itx> he just felt like arguing i think
[06:43:25] <abcminiuser> What about?
[06:43:38] <Tom_itx> c vs c++
[06:43:38] * abcminiuser doesn't feel like downloading and grepping a ton of logs :P
[06:45:07] <inflex> you'd be seriously bored to do so
[06:45:47] * inflex ponders getting into Xmega or AVR32 ... but can't think of an application
[06:47:29] <Tom_itx> inflex started it...
[06:47:49] <Tom_itx> http://tom-itx.dyndns.org:81/~tom-itx/irc/logs/%23avr/2011-11-26.html
[06:47:59] <inflex> *laugh*
[06:48:30] <abcminiuser> inflex, they're both sexy chips
[06:51:39] <inflex> yes, and the prices are looking nice now ($5 or simialr)
[06:53:40] <RikusW> abcminiuser: can I only change #define CDC_TXRX_EPSIZE 32 in descriptor.h ?
[06:55:05] <abcminiuser> And the notification size
[06:55:32] <Tom_itx> abcminiuser, what's LUFA_OPTS += -D INVERTED_ISP_MISO for?
[06:56:04] <RikusW> abcminiuser: FIXED_CONTROL_ENDPOINT_SIZE can be changed in the headers too ?
[06:57:45] <abcminiuser> Tom_itx, a user had a board using a diode as a level converter on MISO, needed that to re-invert the logic
[06:57:55] <abcminiuser> RikusW, Yes, in the makefile
[06:59:20] <Tom_itx> abcminiuser have you happened to try the code on win7 - 64bit with studio 5?
[06:59:53] <Tom_itx> apparently jungo pukes there
[07:00:25] <grummund> How come CDC devices require a .inf "driver file" to register with Windows, but HID devices do not?
[07:00:49] <abcminiuser> Tom_itx, yup, that's what I use
[07:00:56] <abcminiuser> Well, used as well as AS4 nowadays
[07:01:02] <Tom_L> It says " found new hardware", then automatically finds and installs a
[07:01:02] <Tom_L> driver: "Jungo AVRISP mkII".
[07:01:02] <Tom_L> Then Studio 5, Tools offers the selection "AVRISP mkII 0000A00128255",
[07:01:02] <Tom_L> When I click "Apply", Studio 5 says: "Unable to connect to tool AVRISP
[07:01:02] <Tom_L> mkII (0000A00128255)"
[07:01:05] <abcminiuser> grummund, Microsoft.
[07:01:27] <abcminiuser> Specifically, I've no idea why they don't just auto-bind to the internal driver for CDC-ACM devices
[07:01:41] <abcminiuser> But it's probably a legacy thing, since the internal CDC driver in Windows is pretty crappy
[07:01:58] <abcminiuser> Tom_L, I'll try again with latest trunk tomorrow
[07:02:04] <abcminiuser> But it certainly used to work for me
[07:02:22] <Tom_itx> you running 64bit?
[07:04:27] <abcminiuser> Yup
[07:16:45] <Tom_itx> abcminiuser, using TPI studio 5 doesn't execute a program after uploading it to the target like studio 4 did
[07:17:01] <Tom_itx> we had that issue early on with studio 4 iirc
[07:17:19] <Tom_itx> ISP is ok..
[07:17:24] <abcminiuser> Even with latest trunk?
[07:17:32] <abcminiuser> I thought I fixed that in the latest release
[07:17:38] <Tom_itx> just downloaded it
[07:18:05] <Tom_itx> studio 4 is fine
[07:18:08] <Tom_itx> but not 5
[07:19:33] <Tom_itx> PDI is ok as well
[07:20:04] <abcminiuser> One sec
[07:20:30] <abcminiuser> Try this replacement routine in TINYNVM.c:
http://pastebin.com/TZpzJFqA
[07:20:42] <Tom_itx> TPI requires power cycle before it executes
[07:22:17] <abcminiuser> That should fix it
[07:22:29] <Tom_itx> where should i put that?
[07:22:30] <abcminiuser> The above patch
[07:22:36] <abcminiuser> TINYNVM.c
[07:22:43] <abcminiuser> Replace the existing routine with the same name
[07:23:09] <Tom_L> that's not in the latest trunk?
[07:23:24] <abcminiuser> No, just did it then
[07:23:32] <abcminiuser> That's the same style of fix I used for PDI to fix the same issue
[07:25:14] <RikusW> abcminiuser: descriptors is about the same now, still io error --
http://pastebin.com/64An3rfQ
[07:27:16] <Tom_itx> ok
[07:36:04] <abcminiuser> Explosion?
[07:36:38] <Tom_itx> that fixed it
[07:37:01] <RikusW> abcminiuser: USBtoSerial seems to work
[07:37:58] <abcminiuser> Tom_itx, woah, really?
[07:37:58] <abcminiuser> Well cool then
[07:38:06] <abcminiuser> RikusW, but not the bootloader?
[07:38:16] <RikusW> no
[07:38:19] <Tom_itx> haha... you had doubts???
[07:40:11] <abcminiuser> Tom_itx, things never work the way I expect
[07:40:16] <abcminiuser> That's called engineering :P
[07:43:06] <abcminiuser> RikusW, so what works then?
[07:44:22] <RikusW> int16_t ReceivedByte = CDC_Device_ReceiveByte(&VirtualSerial_CDC_Interface);
[07:44:23] <RikusW> if(ReceivedByte > 0) {
[07:44:23] <RikusW> CDC_Device_SendByte(&VirtualSerial_CDC_Interface,ReceivedByte);
[07:44:23] <RikusW> }
[07:44:26] <RikusW> now it echo's nicely :)
[07:44:37] <RikusW> for USB2Serial
[07:45:20] <RikusW> connected TX->RX didn't seem to work... on m16u2
[07:46:15] <jacekowski> Strange
[07:47:52] <RikusW> at least avr8-gnu-toolchain-linux_x86 seems to work quite nicely :)
[07:47:58] <RikusW> no rebooting to XP anymore
[07:48:35] <jacekowski> Something else must be wrong
[07:49:52] <RikusW> so CDC Call Management seems not to be required after all
[07:50:14] <RikusW> can the absense of iSerial cause trouble ?
[07:52:21] <RikusW> might be ---line coding and serial state----
[07:54:27] <RikusW> I'd say cdc task...
[08:05:13] <RikusW> hi scuzzy
[08:06:34] <scuzzy> hey Rickta59
[08:06:37] <scuzzy> SFlselfknsef
[08:06:39] <scuzzy> hey RikusW
[08:06:47] <scuzzy> autocomplete fail
[08:07:10] <RikusW> ;)
[08:07:18] <RikusW> tried the cdc bootloader yet ?
[08:07:32] <RikusW> I can't seem to get the fw working on linux :(
[08:07:41] <inflex> fw?
[08:07:58] <RikusW> LUFA firmware for LUFACDC
[08:10:12] <inflex> oh ok
[08:10:27] <RikusW> USBtoSerial does work... don't know why
[08:10:36] <RikusW> seems its highlevel...
[08:10:43] <RikusW> bootloader lowlevel
[08:11:00] <RikusW> so its not the descriptor....
[08:11:57] <RikusW> maybe I should try upgrading my kernel...
[08:14:40] <RikusW> USB debugging :(
[08:18:02] <DanFrederiksen> does the xmega have DA?
[08:20:32] <DanFrederiksen> doesn't look like it
[08:21:21] <DanFrederiksen> I'd think that would be a pretty easy function to support. but maybe not
[08:23:58] <DanFrederiksen> xmega is a faster, more powerful chip yet it's the cheapest chip they have. 2.27$@25 on digikey
[08:26:40] <inflex> what are you actually trying to do? In terms of what's the project?
[08:26:49] <inflex> could perhaps something like the MSP430's work ?
[08:27:09] <DanFrederiksen> ah strike that. the atmega48 costs 1.55$@25
[08:27:55] <DanFrederiksen> it's a motor controller. and I need to react to a current sensor. and stuff happens in the microsecond range so I'm having to be predictive
[08:27:58] <DanFrederiksen> which can work
[08:34:12] <DanFrederiksen> inflex, msp430 seems comparable to an atmega8 both in price and function
[08:34:51] <DanFrederiksen> the xmega seems stronger. 2MS/s and a second 1MS/s ADC
[08:34:54] <DanFrederiksen> 5 timers
[08:35:33] <DanFrederiksen> but I'll try to make it work with my current mega8 based design
[08:35:40] <karlp> NXP sells cortex M0s for $1.60 in singles...
[08:35:48] <untitled_> maybe there is some good book/tutorial for beginners to start coding in C for arduino/atmega328 chips?
[08:36:05] <DanFrederiksen> karlp, how fast ADC does it have?
[08:36:10] <DanFrederiksen> and how many
[08:37:05] <DanFrederiksen> untitled_, I didn't find any. I just pieced it together painfully with teh long winded documentation and various examples programs on google. and asking specifics here
[08:37:33] <DanFrederiksen> although maybe for arduino
[08:37:48] <DanFrederiksen> that's sort of a separate thing afaik because they have their own compilers..
[08:37:58] <untitled_> DanFrederiksen: ok, I thought so
[08:38:02] <DanFrederiksen> I prefer the real thing, even if a steeper learning curve
[08:38:09] <untitled_> me too
[08:38:17] <untitled_> I don't want to use aduino-java-style-c
[08:38:23] <untitled_> but gcc
[08:38:27] <untitled_> or gcc-avr
[08:38:33] <DanFrederiksen> I want the c code though. no asm for me
[08:38:43] <DanFrederiksen> I use avr studio
[08:38:48] <DanFrederiksen> windows IDE
[08:39:49] <DanFrederiksen> I'd recommend using version 4. version 5 is an adaptation of microsoft studio and it's bloaty and doesn't support atmega8 simulation
[08:40:52] * inflex really can't blame them for not having mega8 simuation
[08:40:55] <inflex> do they have mega88 ?
[08:41:00] <DanFrederiksen> it generates a .hex file that it then uploaded to the chip using avrdude and a physical programmer
[08:41:11] <untitled_> I think I'll stay with linux :)
[08:41:15] <DanFrederiksen> inflex, I think so
[08:41:27] <inflex> Then that'll be why.
[08:41:33] <DanFrederiksen> and I can blame them. their most defining chip and it's not supported. no excuse
[08:42:00] <inflex> the mega88 is the mega8 + power sipping enhancements
[08:42:04] <DanFrederiksen> if they want to discontinue it, state so in the docs
[08:42:20] <DanFrederiksen> inflex, then it should be easy to support simulation..
[08:42:41] <inflex> they have, it's called the mega88.
[08:43:06] <inflex> would you feel better if they called it the 8PA or some other suffix??
[08:43:09] <DanFrederiksen> except the code is different..
[08:43:30] <inflex> which code?
[08:43:49] <inflex> the ASM will be ultimately identical barring one instruction.
[08:43:59] <DanFrederiksen> inflex, the c code
[08:44:06] <inflex> yeah, that's not Atmel doing that
[08:44:07] <DanFrederiksen> it's possible the hex file is compatible
[08:44:15] <inflex> That's avr-gcc libc doing that
[08:44:25] <inflex> Can't blame Atmel for it.
[08:44:28] <grummund> C++ is better
[08:44:30] <DanFrederiksen> well atmel made the IDE
[08:44:45] <DanFrederiksen> and atmel named the registers
[08:44:55] <karlp> no-one cares about the atmega8 man :)
[08:45:09] <karlp> they'd rather use the 88
[08:45:14] <karlp> they still sell the 8 for you :)
[08:45:33] <theBear> it's just that noone can workout what to do with all those pins and that little memory without feeling like they wasted a fancy mcu (unless i've got my models mixed up)
[08:45:42] <inflex> The change between the 8 and 88 in C code is purely aesthetic / syntactical-sugar
[08:45:55] <Tom_itx> more features, same package, cheaper price
[08:45:56] <theBear> mmmm... syntactical sugar donuts
[08:46:06] <DanFrederiksen> inflex, you'll vouch for the hex format being identical?
[08:46:27] <DanFrederiksen> and not a source for sudden problems
[08:46:30] <inflex> No, I won't.
[08:46:35] * theBear sees a legal battle in the future
[08:46:41] <theBear> oh, i was gonna offer to be virtual notary
[08:46:46] <DanFrederiksen> and even if that was true, they should have just supported the 8
[08:46:47] <inflex> but I don't know why you care about the mega8 so much to be honest when the mega88 is the chip to use now?
[08:46:51] <DanFrederiksen> obviously
[08:47:01] * inflex gives you
[08:47:02] <inflex> up
[08:47:11] <theBear> i actually found a couple cases here recently where having notaries woulda been very handy (they don't exist here, i think closest you can get is witnessed by a QC)
[08:47:17] <DanFrederiksen> because I already bought the chip, write the code and made the hardware
[08:47:21] <theBear> and there aren't a lot of them
[08:47:23] <theBear> but i digress
[08:47:28] <inflex> DanFrederiksen: hell, I'll send you some mega88's
[08:47:29] <DanFrederiksen> wrote
[08:47:33] <Tom_itx> so?
[08:47:50] <DanFrederiksen> and they still produe them
[08:47:51] <Tom_itx> you are unable to mod the code?
[08:47:51] <inflex> and the software is a search-replace fix
[08:48:03] <DanFrederiksen> sigh
[08:48:10] <Tom_itx> exactly
[08:48:15] <DanFrederiksen> exactly??
[08:48:19] <inflex> sure, if all you have is the hex code, fine... I can appreciate that, a bit like people stuck with using other legacy chips.
[08:48:20] <DanFrederiksen> I could change everything
[08:48:21] <karlp> we're very sorry that they stopped offering simulation support for your old chip
[08:48:27] <DanFrederiksen> but I should't fucking have to
[08:48:30] <DanFrederiksen> shouldn't
[08:48:38] <DanFrederiksen> obviously
[08:48:48] * inflex gives DanFrederiksen a box of 6502s
[08:48:48] <Tom_itx> well use the old software with the old chips and be happy
[08:49:43] <DanFrederiksen> why is it so important to you people to defend the indefensible?
[08:49:59] <Tom_itx> why is it so important you argue with us?
[08:50:05] <DanFrederiksen> don't answer. just think
[08:50:52] <inflex> Because people screaming and shouting about things that won't be changed are annoying.
[08:50:55] <karlp> you were suggesting to someone to use the old avr studio, with the main reason being that v5 didn't support atmega8
[08:51:07] <Tom_itx> i don't think we're trying to defend anything. we simply told you to move on
[08:51:08] <karlp> our point was that no-one cares abotu atmega8 simulation support
[08:51:22] <karlp> and that's a bad reason for choosing one version of a tool over another
[08:51:32] <karlp> especially for someone looking at _starting_
[08:51:53] <Tom_itx> you design something on a part that will become obsolete isn't thinking very clearly
[08:52:36] <DanFrederiksen> who says it will be obsolete?
[08:52:37] <Tom_itx> at least the 88 will have a longer life span
[08:52:47] <Tom_itx> because it has been superseeded by the 88
[08:52:54] <DanFrederiksen> says who?
[08:52:55] <Tom_itx> drop in pin compatible
[08:53:03] <inflex> It's an old chip DanFrederiksen - it's bound to be officially obsceleted soon - best to invest the small time now to migrate to the 88 (which will be simple) than to fight a battle that will only be a loss, to stay with the mega8.
[08:53:26] * Tom_itx hands inflex another crazy_pete
[08:53:37] <DanFrederiksen> inflex, this isn't about fighting for the 8 to survive
[08:53:38] <inflex> Tom_itx: awww :(
[08:53:57] <inflex> DanFrederiksen: I know, it's a fight for it to stay relevant in the tools - but it won't.
[08:53:58] <karlp> do you deny you're complaining that atmega8 simulation support was dropped?
[08:54:15] <DanFrederiksen> inflex, not it either
[08:54:20] <Tom_itx> DanFrederiksen, some of the register names have changed due to the chip functionality expansion
[08:54:51] <Tom_itx> you may have to rename a few things however the code should still work
[08:55:05] <DanFrederiksen> the issue is that they are promoting and selling a chip that they don't support in the IDE.
[08:55:13] <inflex> thing is DanFrederiksen, that's the reality of it - the support isn't there for precisely what you want - we can't change it, we actually don't care; the mega88 was the replacement and it's a good one.
[08:55:15] <karlp> promoting?!
[08:55:27] <DanFrederiksen> if their datasheets said the chip has been replaced and should not be used for new designs that would be fine
[08:55:30] <DanFrederiksen> but they do not
[08:55:36] <Tom_itx> DanFrederiksen, they supporte it in the ide that was current at the time
[08:55:46] <karlp> they support last year's model and this years model
[08:55:53] <karlp> they don't support 10 years ago's model.
[08:56:02] <karlp> the mega8 is last year's model.
[08:56:09] <karlp> or 3 years ago's model
[08:56:11] <inflex> karlp: you mean last DECADE's model.
[08:56:14] <Tom_itx> further back than that
[08:56:15] <karlp> or something, in my increasinbly bad analogy
[08:56:21] <DanFrederiksen> indeed
[08:56:32] <karlp> (I didn't mean the years of the chips)
[08:56:37] <inflex> DanFrederiksen: best you can do then, given the reality on the table - demand Atmel update their datasheets.
[08:57:08] <karlp> I'd say the fact that atmega8 doens't support simulation in avrstudio 5 is pretty clear documentation itself
[08:57:12] <DanFrederiksen> inflex, the problem is not with me. it is with you, denying the issue
[08:57:31] <karlp> oh shit, what have I done. I'm arguing on the internet!
[08:57:55] <DanFrederiksen> enough said
[08:58:24] <inflex> DanFrederiksen: But I don't care *shrug* so I'm not denying any issue, it has no relevance to me.
[08:59:59] <inflex> DanFrederiksen: even if you get Atmel to pull up their pants and make things clearer on their PDFs, you'll have won on that ground but will it actually fix anything for you?
[09:00:37] <inflex> DanFrederiksen: think about it like this - what good does it do you arguing with us in here?
[09:01:02] <grummund> http://xkcd.com/386/
[09:01:52] <inflex> grummund: I already know that one by heart without even loading it :D
[09:03:22] <inflex> anyone used/made a hot-bar soldering iron?
[09:03:35] * inflex has a bunch of OLED display units coming soon and they'll need that :(
[09:04:18] <DanFrederiksen> have any of you ever worked with ARMs?
[09:04:33] <theBear> i usually use two arms while i work <grin>
[09:04:52] <theBear> i've done a little linux-experimentation on the old pocketpcs i've got a cache of, but nothing serious
[09:06:26] <inflex> I've wanted to - but the supporting gear for the ARMs at the time was too much for me. Not sure what they're like now
[09:07:15] <grummund> too much?
[09:09:01] <DanFrederiksen> ah well. 32bit atmel are likely more powerful than I'd ever need and I don't want to mess with coding large OSes
[09:09:46] <DanFrederiksen> although I suppose some sort of video processing unit might need some power
[09:10:23] <DanFrederiksen> 450MHz arm9 for 5$. not much price span in microcontrollers despite performance difference
[09:11:01] <DanFrederiksen> have any of you done projects with ram chips?
[09:11:23] <DanFrederiksen> external memory
[09:11:47] <inflex> as in SRAM/DRAM stuff?
[09:11:53] <DanFrederiksen> yes
[09:11:53] <inflex> or FLASH/EEPROM/FRAM?
[09:12:04] <DanFrederiksen> nah ram
[09:12:17] <DanFrederiksen> but also flash if you have
[09:12:29] <DanFrederiksen> things probably often need both
[09:12:45] <inflex> well, no shortage of SPI SRAM
[09:12:51] <DanFrederiksen> microcontrollers with large ram built in doesn't exist?
[09:13:27] <inflex> AVR32s have a reasonable amount
[09:13:34] <DanFrederiksen> MB range?
[09:13:36] <inflex> but you can expand on that using things like the SPI SRAM, 32KBytes etc
[09:13:40] <inflex> no, not MB range
[09:14:18] <DanFrederiksen> hmm. they should have chips with 1MB ram. and 32
[09:14:33] <DanFrederiksen> save a lot of buswork
[09:14:39] <DanFrederiksen> I presume
[09:14:51] <DanFrederiksen> ah well, no need now. laters
[09:16:27] <inflex> you can get that size in SPI FLASH, but haven't seen it in SRAM/DRAM... yet.
[09:16:47] <DanFrederiksen> built in flash?
[09:23:48] <inflex> gack... the cost of 3M 8-way SOIC clips has gone right up
[09:24:04] <inflex> used to get them for $7/pc at digi, now they're $16
[09:24:54] <DanFrederiksen> yeah certain items in electronics are quite expensive
[09:25:04] <DanFrederiksen> like current sensors
[09:25:17] <inflex> am thinking it's becoming time to make a bed-of-nails ICP hardware clip
[10:11:38] <chupas> Any idea why I wouldent beable to program EEPROM on an device via JTAG?
[10:12:23] <chupas> especial when Im having no problems programing the flash
[11:07:57] <amstan> what is __SFR_OFFSET and why is it added to all addresses like PORTA?
[11:09:05] <amstan> i'm trying to use OUT in assembly on avr, if i want to output on PORTB i would have to use the 0x0B address
[11:09:19] <ziph> GCC uses the high bits of addresses to determine what kind of memory it is.
[11:09:34] <amstan> but if i use the PORTB define from avr/io.h, it'll have that SFR_OFFSET in the address, so i can't just give the PORTB define to OUT
[11:10:49] <amstan> ziph: how how am i supposed to properly use the OUT instruction with the PORT defines?
[11:12:26] <ziph> Not sure, the last time I did substantial amounts of assembler for AVR there weren't l-value ports. :)
[11:13:09] <amstan> are you aware of any good tutorial on writing assembly only programs using avr-gcc?
[11:17:12] <ziph> Had a look on avr freaks?
[11:17:17] <karlp> avr/io.h is designed to help people using C,
[11:18:43] <amstan> karlp: hmm, so which one should i use for assembly?
[11:18:51] <Tom_itx> you can get asm defines from studio
[11:18:54] <Tom_itx> what chip is it?
[11:19:39] <amstan> 169p
[11:20:14] <Tom_itx> i have one for the 169
[11:20:34] <amstan> i would prefer to use the built in libraries though from the linux set of tools
[11:21:01] <Tom_itx> these defines are chip dependant
[11:22:39] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/studio/
[11:22:43] <Tom_itx> it's there if you want it
[11:23:41] <amstan> Tom_itx: i can't really include that with gcc
[11:23:59] <amstan> ./m169def.inc:781: Error: expected comma after "DDD2"
[11:24:02] <Tom_itx> i added ones for the pa and p
[11:24:29] <Tom_itx> i guess you can try the c header files
[11:26:56] <amstan> i did, and they have that offset in all of them
[11:27:25] <Tom_itx> haven't read the log.. just walked in
[11:59:24] <RikusW> hi scuzzy
[12:30:07] <soul-d> i hurray 16 bit logic analyzer :)
http://i.imgur.com/xHLGb.png although i see some "errors on data clock line have to see if it's because im using that line as trigger
[13:06:00] <scuzzy> hey RikusW
[13:06:03] <scuzzy> how you man?
[13:06:31] <RikusW> fine, you ?
[13:06:56] <RikusW> given up on the LUFACDC bootloader fw, won't work in linux only on XP
[13:07:10] <RikusW> strangely USBtoSerial does work in Linux
[13:07:23] <RikusW> it use the highlevel lufa stuff
[13:07:51] <RikusW> scuzzy: tried testing RavrProg with it yet ?
[13:07:57] <RikusW> or been busy ?
[13:08:16] <scuzzy> no
[13:08:19] <scuzzy> I'm gonna try it now
[13:08:23] <scuzzy> so, hang on
[13:08:27] <scuzzy> why doesn't it work?
[13:08:37] <RikusW> you've got the emailed files for CDC ?
[13:08:43] <RikusW> IO error
[13:08:45] <scuzzy> yeah
[13:08:47] <scuzzy> ok
[13:08:52] <RikusW> even cat ttyACM0 wont work
[13:09:28] <RikusW> USB drivers is quirky....
[13:09:49] <RikusW> and XP's is too forgiving ;)
[13:10:03] <RikusW> of out of spec stuff
[13:10:46] <scuzzy> I've use the CDC bootloader tho
[13:10:48] <scuzzy> with avrdude
[13:11:23] <RikusW> I've gotten kernel 2.6.18, probably the cause of it all...
[13:11:44] <RikusW> it fails to open ACM0
[13:11:54] <RikusW> it does enumerate...
[13:12:32] <RikusW> just loaded my U2S fw only a board using LUFA ISP mkII :)
[13:12:36] <RikusW> works fine
[13:12:40] <scuzzy> Bus 006 Device 005: ID 03eb:204a Atmel Corp. LUFA CDC Class Bootloader
[13:12:56] <scuzzy> Hmmm
[13:13:02] <RikusW> yeah even lsusb work here
[13:13:08] <RikusW> just can't connect to it
[13:13:10] <RikusW> at all
[13:13:15] <RikusW> not even cat it
[13:14:34] <RikusW> scuzzy: so its easy for you to compile RavrProg ?
[13:15:27] <scuzzy> I'll have a try in a sec
[13:15:33] <scuzzy> just wanna see if I can get AVRdude talking again
[13:15:35] <scuzzy> just a sec
[13:15:48] <RikusW> try -t with avrdude
[13:27:17] <karlp> RikusW: what project are you working on? a new/faster avr programmer?
[13:27:52] <RikusW> a Qt4 GUI for programming avr's
[13:27:59] <RikusW> using atmel programmers
[13:28:07] <RikusW> but others can be added
[13:28:16] <karlp> using existing programmer hardware though?
[13:28:33] <RikusW> there is a backend library for anyone wishing to implement a custom interface..
[13:28:52] <RikusW> all Atmel programmers except jtag3 and avrone
[13:30:21] <carp3> RikusW: please keep GUI simple. like avrstudio5.. do you have a screen shot from GUI ?
[13:31:13] <RikusW> carp3: its almost like AS4
[13:31:36] <RikusW> carp3: and it autodetects the avr too :)
[13:31:44] <RikusW> just click on connect
[13:31:59] <RikusW> carp3:
http://www.image-share.com/ipng-875-235.html
[13:35:44] <carp3> put some warnings when someone tries to kill avr :p like disabling ISP., and putting a tooltip for every fusebit and explaining them is good
[13:35:58] <carp3> +auto detecting programmers
[13:36:14] <carp3> wow, my english sucks!
[13:41:39] <Casper> hmmmm
[13:42:06] <Casper> why is "phase correct" pwm better than normal one? it's digital, why would there be a phase problem?
[13:42:45] <theBear> maybe it's a balance thing, like manchester ?
[13:43:03] <Casper> it count from bottom to top to bottom
[13:43:18] <theBear> ehh, you mean its just backwards timer mode?
[13:43:36] <Casper> since it's digital, I don't see the difference between that and bottom-top...
[13:43:38] <theBear> is it complimentary ?
[13:43:44] <Casper> phase correct is basically ping pong
[13:43:50] <theBear> hmmm...
[13:44:06] <theBear> so instead of normal pwm the freq changes with duty cycle ?
[13:44:17] <Casper> no
[13:44:34] <Casper> normal pwm go bottom top overflow
[13:44:52] <theBear> yeah, so the freq stays same with duty cycle
[13:45:10] <Casper> while phase correct go min-max-min... ex 0 1 2 3 4 .... 254 255 254 253 252 ... 2 1 0 1 2 3 .....
[13:45:27] <Casper> while normal do 0 1 2 3 4 5 6 ... 254 255 0 1 2 3...
[13:45:50] <theBear> erm... i think it's one too many drink in for me to get this, ... wait but, hmmm k... i can see it
[13:45:51] <vectory> who said it was better
[13:45:54] <vectory> its just different
[13:45:55] <RikusW> carp3: will add fuse warnings later
[13:45:59] <theBear> mostly sales guys from what i've seen
[13:45:59] <vectory> :D
[13:46:03] <Casper> I see the result the same as normal at half the speed and resolution...
[13:46:15] <Casper> vectory: atmel said it's better for motor
[13:46:40] <theBear> should be same speed and resolution, but each pair of cycles does the pwm pulse back to back
[13:47:25] <theBear> like using a triangle and a comparator instead of a saw and a comparator
[13:48:18] <theBear> i don't like it
[13:49:35] <Casper> I'm trying to convert an avr into a smps controller for several reasons (mainly due to the lack of proper IC on hand...)
[13:50:00] <Casper> but I'm a bit puzzled by how to make it correctly
[13:50:02] <theBear> anyone worked with tiny13 or similar 8pin much ? been looking at a few schems, seems usually you don't need to isolate the miso/mosi and err, the other one, but what about cases where they are some kinda un-controllable input ? you just put bypass jumpers on the board for reprogramming ?
[13:50:22] <Casper> mosi miso sck reset
[13:50:36] <theBear> on a semi-dev/for me board this is, one that will always have a programming socket, that will probably not get much use after the thing is working to satisfaction
[13:51:07] <Casper> mosi is an output in normal mode, but input for programming
[13:51:12] <theBear> yeah, well reset is easy, just a pullup
[13:51:20] <Casper> if your other devices can take the noise, no need to isolate
[13:51:29] <Casper> else you may need to
[13:51:49] <theBear> hmm... i didn't even look, surely on a chip that small mosi can double as an input if i need it to ?
[13:51:55] <theBear> i've got the datasheet in the background
[13:51:56] * theBear looks
[13:52:04] <soul-d> doc2521
[13:52:11] <soul-d> is what you want Casper
[13:52:21] <soul-d> or theBear
[13:52:39] <theBear> lol, pb0/mosi/ain0/oc0a/pcint0 pin :)
[13:52:57] <theBear> it can do just about anything that pin can
[13:53:34] <theBear> hmmm... do i still get 2 timers i wonder ? (don't worry, i'm answering my own questions, i might be outta practice, but i'm no monkey)
[13:53:40] <Casper> arrrg the adc is too slow :(
[13:53:53] <theBear> hehe, it IS tiny
[13:55:18] <theBear> i'm thinking of knocking up a little vero/devboard to take to mums this week (i live there a lot at the moment, far away in the country) to experiment with some stuff, i2c input and maybe temp sensing r-c style, or maybe adc, but probly r-c is less components (can't just hang a temp sensor on a voltage divider) ... and maybe some multiple pwm experiments
[13:55:45] * theBear squints at the block diagram
[13:55:59] <theBear> but but, i don't even get a uart ?
[13:56:25] <karlp> nope,
[13:56:27] <karlp> you get a USI :)
[13:56:33] <theBear> can something that small receive i2c AND do ANY maths in a given second ?
[13:56:47] <karlp> it runs at 8Mhz or so, the same as anythign else,
[13:56:53] <karlp> at least the attiny25
[13:56:57] <theBear> oooh, please tell me avr-gcc can help me
[13:57:00] <karlp> pin muxing is the hard one.
[13:57:18] <karlp> the tiny13, is that the one with no ram? just registers?
[13:57:22] <theBear> indeed, just choosing which of which functions to use on any pin is tough
[13:57:28] <theBear> 64bytes sram ?
[13:57:31] <theBear> that's normal ram isn't it
[13:57:40] <karlp> o ok,
[13:57:43] <karlp> yeah, that's fine
[13:58:16] <Casper> does anyone know of a good linux calculator?
[13:58:17] <karlp> I have a tiny85 doing tx only software uart, measuring two temp sensors and still allowing ISP
[13:58:21] <theBear> i bought them ages ago when i could still order thru work, just for a couple TINY projects that 2313 seemed a waste on... i guess i DID do my research and get the bigger ones
[13:58:30] <Casper> my calculator is in the other room...
[13:58:36] <theBear> karlp, mmmm, that gives me hope
[13:58:39] <karlp> Casper: let me know when you find one, most of them suck.
[13:58:46] <Jagged> Casper: python?
[13:58:50] <karlp> or, I'm still to conditioned to the way windows calculator works.
[13:58:58] <Casper> karlp: thinking to get a ti85 emu and wine it or something
[13:59:00] <soul-d> if you can do i2c adda gpio
[13:59:00] <karlp> gnome-calc isn't terrible.
[13:59:49] <theBear> i like calcoo at the moment
[14:00:03] <theBear> but i think it's a K thing, lotta people don't like K things for some reason
[14:01:39] <Casper> new plan needed :/ look like the avr adc is too slow to get familliar with smps... unless I go dumber mode... and assume things...
[14:01:57] <karlp> theBear:
http://false.ekta.is/wp-content/uploads/2010/03/tinytemp-3v3.png
[14:02:19] <karlp> I think I later added the second sensor on PB2
[14:03:51] <theBear> mmmm... very nice
[14:04:02] <theBear> while we're at it, anyone got a schem/pinout for rif's programmer ?
[14:04:21] <theBear> rue_shop, oi, you alive ?
[15:03:10] <LoRez> Where's Dean?
[15:03:28] <LoRez> http://www.adafruit.com/blog/2011/11/29/dean-camera-joins-atmel-as-avr-applications-engineer/
[15:06:32] <karlp> with a solitary, youtube style comment
[15:12:38] <alabd> Good day all , will be so thankfull if you guide at
http://electronics.stackexchange.com/questions/22951/communication-between-avr-and-crous-ptz-device
[15:17:43] <charolastra> hi, im using bascom and noticed that code which ran fine with version 1.9.x compiles to a different programm with the newer 2.x version (stuff like UART works fine but the PWM pins are now at 5V when they should be 0); did anything change between the versions?
[15:19:04] <Essobi> charolastra: look at some ASM debugs?
[15:19:39] <charolastra> easier said than done ;)
[15:20:08] <Essobi> Oh.. yea, you're using bascom...
[15:20:26] <Essobi> yea, I'm not sure how that works...
[16:29:15] <RikusW> Casper: kcalc ?
[17:12:44] <pc_magas> bb
[19:15:29] <devcoder> hey everyone
[19:16:00] <devcoder> anyone ever used the usart and a timer at the same time
[19:44:24] <abcminiuser> devcoder, sure
[19:45:43] <devcoder> abcminiuser, have you any idea why when I have them both enabled on a atmega644p or any other chip it seems to just randomly stop working?
[19:45:59] <devcoder> using external crystal at 9.216mhz
[19:46:04] <Tom_itx> what stops working?
[19:46:10] <devcoder> receiving data at 57600
[19:46:28] <Tom_itx> interrupt driven?
[19:46:30] <devcoder> have internal int0 tripping at 120hz
[19:46:31] <devcoder> yes
[19:46:46] <devcoder> three interrupts total
[19:47:11] <devcoder> the other two seem to work fine together, even if i disable the int0 interrupt it still stops
[19:47:57] <devcoder> quits randomly from anywhere between a few seconds to a few minutes. closer to a few seconds
[19:48:02] <Tom_itx> have you tried it at a slower baudrate?
[19:48:09] <abcminiuser> What's in the timer ISR?
[19:48:30] <Tom_itx> the isr could be too busy
[19:48:57] <devcoder> yes tried a slower baud still the same
[19:48:59] <devcoder> ISR(TIMER1_COMPA_vect){ //This is our interrupt service routine
[19:49:00] <devcoder> PORTD ^= (1<<PD3);
[19:49:00] <devcoder> clockCount++;
[19:49:00] <devcoder> intTriggered = 1;
[19:49:00] <devcoder> }
[19:49:19] <devcoder> the portD is there just to show me its tripping otherwise it wouldn't be there
[19:49:36] <Tom_itx> that's not much
[19:49:55] <devcoder> nope all stuff is done in main, all it does it check to see if it should turn on some outputs
[19:49:56] <Tom_itx> what about wdt
[19:50:04] <devcoder> fuse disabled
[19:51:11] <abcminiuser> What frequency is the timer ISR running at?
[19:51:20] <abcminiuser> Could be you're just stealing all the CPU time from the USART rx
[19:51:47] <devcoder> the us art is running at 57600bps and sending a 10byte stream to it 10 times a second
[19:51:47] <Tom_itx> 120hz he said
[19:52:00] <devcoder> yes the int0 is
[19:52:38] <devcoder> I set the timer to trip as slow as 120 sec also but that didn't help
[19:52:58] <devcoder> when said and done I do what it at about 120 *30 if possible
[19:53:21] <devcoder> lots of interrupts yes but I think at 9mhz it should be able to handle it
[19:53:31] <devcoder> i will be upping the clock to 18.432 later on
[19:59:02] <Tom_itx> abcminiuser, any thoughts on the win7 64 thing?
[19:59:27] <Tom_itx> have you had any problems with jungo and studio 5 on it?
[20:05:09] <devcoder> no other ideas?
[20:05:35] <Tom_itx> you might post the code and maybe someone would
[20:06:11] <Tom_itx> it should work
[20:08:20] <devcoder> yeah i can do that
[20:09:25] <Tom_itx> could just be some simple oversight or something
[20:11:15] <abcminiuser> Back
[20:11:21] <abcminiuser> devcoder, post your code to pastebin
[20:11:30] <abcminiuser> Tom_itx, no luck with AS5 your end?
[20:11:39] <abcminiuser> I'll load in the latest firmware and try it again here
[20:11:43] <I440r> people are actually using that abortion as5?
[20:11:58] <devcoder> abcminiuser, doing it right now, thanks
[20:15:50] <devcoder> http://pastebin.com/4T1ArZFh
[20:16:08] <abcminiuser> Tom_itx, works here
[20:16:17] <abcminiuser> Latest trunk, latest AS5, Win7 x64
[20:16:38] <abcminiuser> Jungo version 10.1.1.0
[20:17:30] <I440r> are people switching over to as5 in favor of as4?
[20:17:57] <I440r> i was seriouslu hoping enough people would bitch at avr and make them STOP using crappy microscum IDE's
[20:18:32] <abcminiuser> devcoder, holy crap
[20:19:14] <abcminiuser> Loop and mask, don't copy-paste
[20:19:28] <devcoder> abcminiuser, yeah not pretty
[20:20:28] <abcminiuser> Don't loop in the USART ISR
[20:20:40] <abcminiuser> Since the ISR has fired, you already know a byte was received
[20:21:27] <abcminiuser> Also, calling uartPutChar() in the ISR will probably destroy the timing, since the entire reg set has to be pushed/popped
[20:21:34] <abcminiuser> Plus you then spinloop in there waiting for TX to be ready
[20:23:24] <abcminiuser> I440r, I use both
[20:23:36] <abcminiuser> AS5 for ASF examples to help people, AS4 for actual use
[20:25:34] <I440r> right now the only thing i use as4 for is to do debug sessions on my boot loader. once thats completed ill have no reason to ever use it again. my boot loader will facilitate debugging of the application
[20:25:34] <RikusW> Hi I440r
[20:25:41] <I440r> rikus!
[20:25:45] <I440r> i was looking for you the other day lol
[20:26:17] <I440r> i still didnt get the CDC written but i was going over yours some. i think i can trim it by quite a bit lol
[20:26:25] <I440r> do you have a more recent version of it?
[20:26:36] <RikusW> no
[20:26:38] <I440r> i was going to split it all apart into individual modules
[20:26:40] <RikusW> still using that
[20:26:44] <RikusW> it works...
[20:26:49] <I440r> ya
[20:26:56] <abcminiuser> RikusW, any luck from last night?
[20:26:58] <I440r> so did you RE the dragon yet or what :P
[20:27:00] <RikusW> I440r: My RavrProg sw is nearly complete :) works with dragon in linux with qt4
[20:27:07] <RikusW> abcminiuser: given up
[20:27:12] <I440r> ewwwwwww qt4 lol
[20:27:24] <RikusW> abcminiuser: USBtoSerial works...
[20:27:33] <RikusW> just not the CDC bootloader
[20:27:46] <Tom_itx> abcminiuser did you see LoRez's post?
[20:27:48] <Tom_itx> <LoRez>
http://www.adafruit.com/blog/2011/11/29/dean-camera-joins-atmel-as-avr-applications-engineer/
[20:28:05] <RikusW> I440r: dragon use same protocol as jtagice mkii which is documented
[20:28:40] <Tom_itx> abcminiuser, i sent the latest hex to the guy and apparently it still doesn't work
[20:28:46] <RikusW> I440r: interested in a GUI in linux for the dragon ?
[20:29:00] <abcminiuser> Tom_itx, yeah, I got a photo from Atmel Apps showing the countdown running on the office build monitor display...
[20:29:04] <I440r> yea but would love to see the firmware for the dragon reverse engineered :)
[20:29:09] <abcminiuser> RikusW: Hrm, that's odd
[20:29:10] <Tom_L> Win7 didn't say "found new hardware".
[20:29:10] <Tom_L> AS5 failed as before: "Unable to connect to tool AVRISP mkII (0000A00128255)"
[20:29:10] <Tom_L> and "details: ...Failed to set-up tool (no context id returned)."
[20:29:18] <I440r> RikusW, linux IS my primary OS u know :P~
[20:29:34] <abcminiuser> Tom_L, that sounds like AS5 is horked
[20:29:49] <abcminiuser> That's the debug server breaking, that communicates between AS5 IDE and the backend
[20:29:54] <RikusW> abcminiuser: USBtoSerial use the highlevel api...
[20:29:55] <Tom_itx> he's got xp on a laptop but he'd prefer using his desktop
[20:30:48] <RikusW> I440r: should I mail it over ?
[20:30:53] <I440r> yea!
[20:31:22] <I440r> trying to get the $)$^Y$* rid of gnome on this laptop atm tho, proving to be pretty much impossible
[20:31:31] <abcminiuser> RikusW, indeed, but the end result should be the same, minus a few bells and whistles
[20:31:45] <abcminiuser> Tom_itx, ask him to reinstall AS5
[20:32:21] <Tom_L> i just did
[20:33:56] <Tom_L> did you push that code patch you gave me this morning?
[20:34:00] <Tom_L> for TPI
[20:35:34] <devcoder> abcminiuser, thanks, that seemed to work good to know about the loops, even though seems like every example i have ever seen had them in there
[20:36:09] <abcminiuser> Yes, pushed
[20:36:17] <Tom_L> ok
[21:21:57] <UnderSampled> which one's faster, a binary or a boolean not?
[21:22:22] <RikusW> should be about the same
[21:22:37] <RikusW> both will take 1 byte on avr
[21:22:52] <RikusW> unless you bitpack it
[22:55:06] <alabd> Good day all , will be so thankfull if you guide at
http://electronics.stackexchange.com/questions/22951/communication-between-avr-and-crous-ptz-device
