Back
[00:12:19] <Elec_A> Hello, Is it possible to connect several USART peripherals to AVR ?
[00:13:06] <Casper> Yes, No, Maybe :D
[00:13:33] <Casper> depending on the avr, it may have 0, 1, 2 or even more hardware usart
[00:13:45] <Elec_A> I use ATmega32
[00:14:01] <Casper> no, if you want to use hardware uart and there is no more, then can'T, unless you bump up the avr
[00:14:24] <Casper> maybe, you can always do it in software, if you have enought ressources available
[00:14:41] <Elec_A> Casper: what do you mean by saying "bump up the avr" ?
[00:14:54] <Casper> I'm actually doing something simmilar on a tiny85, all software...
[00:14:59] <Casper> Elec_A: use a bigger one
[00:15:08] <Elec_A> Casper: aha, thank you
[00:15:44] <Elec_A> Casper: I want to use Atmega32 to have wireless communication and wired communication as well
[00:16:42] <Casper> serial is easy, however it need precise timing, which can complicate things in software... interrupt screw it up... But you can make an interrupt based one if you have a free timer, or if you get creative with the coding
[00:18:21] <Elec_A> Casper: I am thinking about connecting all USART devices to the ATmega32 and use Address Decoding circuit to use one peripheral at the moment. what do you think ?
[00:19:03] <Elec_A> Decoding ENABLE Pin of each device.
[00:59:20] <Casper> aaaand another limitation found on the tiny85
[00:59:28] <Casper> I'll work around it
[01:37:53] <Casper> pff the timer1 is confusing...
[01:37:58] <Casper> tomorrow...
[06:36:08] <STS_Patrik> is it possible to connect CAN-bus between MCU's without using a transciever?
[06:36:54] <RikusW> quite possible
[06:37:05] <RikusW> might be similar to ttl uart I guess ?
[06:37:41] <RikusW> How far apart are the mcus ?
[06:38:37] <STS_Patrik> 50mm PCB trace, and there will be other devices located behind the transciever going out of the box
[06:39:54] <RikusW> I'm not that familiar with CAN but someone in here should be able to help
[06:40:07] <RikusW> 50mm shouldn't be an issue I guess
[06:41:44] <Lambda_Aurigae> can bus should run fine for a meter or more without going to real can bus voltage levels.
[06:43:14] <STS_Patrik> but if i have two MCU's "sharing" transciever to the rest of the network and still be able to talk to eachother? On MCU side it's labeled CANRX & CANTX instead of CANH&CANL so i assume they should be crossed then, but that would make one of the MCU's to have inverted connection to the transciever
[06:43:43] <Lambda_Aurigae> yes..they won't both be able to talk to the transceiver.
[06:44:04] <STS_Patrik> ye makes sense. No shortcuts then :)
[06:44:08] <Lambda_Aurigae> you either use the transceivers or you don't...mixing them is probably won't work.
[06:44:32] <Lambda_Aurigae> and my grammer is probably won't good this day's morning time.
[06:44:42] <Lambda_Aurigae> still half asleep I am.
[06:46:27] * RikusW senses a Star Wars fan.. ;)
[06:54:51] <LeoNerd> Moring RikusW :) So.. my HVSP controller board arrived...
[06:55:00] <LeoNerd> Timing seems dreadful though :( I'm getting a lot of UART failures
[06:56:31] <RikusW> Hi LeoNerd
[06:56:58] <RikusW> is the baud right ?
[06:57:36] <LeoNerd> well that's the only think I'm thinking, really. It's 115.2kBaud. Using a 14.*mumble* crystal, the proper baud rate divisor
[06:57:46] <LeoNerd> So it's a divide-12 I think.. I forget the number.
[06:57:56] <RikusW> 14.745 iirc
[06:58:09] <LeoNerd> The code worked much better on my breadboard... same chip, same rate of crystal.. but different brand
[06:58:23] <LeoNerd> My logic probe measured a 117.something kbaud rate
[06:59:24] <RikusW> try enabling ckout or output half the clock using pwm and measure the frequency ?
[07:00:08] <RikusW> which avr is on that board again ?
[07:00:20] <LeoNerd> It's *close* to right... if I just read a constant stream of, say, the letter 'A', then about 1 in 200 chars gets corrupted
[07:00:32] <LeoNerd> But it means the STK500 protocol gets upset too often, and avrdude often falls over
[07:00:39] <LeoNerd> tiny841
[07:00:49] <LeoNerd> The one with a real hardware UART
[07:01:44] <LeoNerd> Problem is Ican't easily swap the crystal with the one on my breadboard to test it
[07:02:07] <LeoNerd> How much of a difference would it make, the exact PCB layout of the crystal tracks? I could pop up an image of the layout maybe
[07:03:44] <RikusW> try measuring the clock using a timer to output pwm
[07:04:07] <LeoNerd> Hmmm... yah I could do that
[07:04:22] <LeoNerd> Or.. could I just put a probe directly on the XTAL lines? Or might that upset the oscillator?
[07:04:46] <RikusW> if the 841 uart is the same as the mega328 then ubrr should be 7 or 15 when u2x=1
[07:05:02] <RikusW> (for 14.7456MHz)
[07:05:23] <LeoNerd> Oh I'm quite sure that UBRR is right; if it was even 1 off, then the whole thing would not work at all
[07:05:31] <LeoNerd> And the same code works nicely reliably on my breadboard mockup
[07:05:45] <LeoNerd> (It's 7 without U2X)
[07:06:36] <RikusW> what caps did you put on the crystal ? 18 / 22pF ?
[07:06:58] <LeoNerd> Hrm.. 14 I think. It was what the crystal itself said to use
[07:07:04] <LeoNerd> One moment I'll get some links
[07:07:36] <RikusW> and on the breadboard ?
[07:08:02] <RikusW> remember the bb got some additional capacitance
[07:08:06] <LeoNerd> Ah.. on the breadboard it was a ready-made crystal + caps board that I got. So you connect it directly to chip + GND
[07:08:27] <RikusW> I'd try putting in 22pF caps
[07:08:31] <LeoNerd> Hrmmm...
[07:08:47] <RikusW> I've used 18pF as well on 16MHz
[07:08:53] <LeoNerd> http://uk.farnell.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=15001&langId=44&urlRequestType=Base&partNumber=1611751&storeId=10151 <== crystal on the real board (which sucks)
[07:09:03] <LeoNerd> Oh.. 18. Yeah, I used those then
[07:09:55] <RikusW> did you keep the tracks as short as possible and about the same length ?
[07:10:05] <RikusW> is it surrounded by ground ?
[07:11:31] <LeoNerd> http://home.leonerd.org.uk/local/screenie/xtal-board.png
[07:11:39] <LeoNerd> crystal + tiny chip
[07:11:50] <LeoNerd> Er.. one momen
[07:12:08] <LeoNerd> try now
[07:12:29] <LeoNerd> I wonder of that track geometry of the XTAL2 line upsets i
[07:12:30] <LeoNerd> t
[07:14:11] <Lambda_Aurigae> you want those tracks as even and symmetrical as possible I would think.
[07:14:49] <RikusW> its possible
[07:14:51] <Lambda_Aurigae> I have a box of 22pf caps just for crystals of all kinds...from 4MHz to 40MHz they all seem to work with the same 22pF caps.
[07:15:19] <LeoNerd> I do have a couple of bare boards.. I suppose I could try measuring the capacitance of the track itself
[07:15:41] <LeoNerd> The long one at least might be significant
[07:15:58] <RikusW> https://sites.google.com/site/megau2s/ there are some pictures of my pcb layout too
[07:16:17] <Lambda_Aurigae> solderless breadboards do fun things to crystals too...often don't even need caps on them due to the built in capacitance of the board itself.
[07:16:30] <LeoNerd> Annoyingly it's rather hard to fit that entire HC49 in, because it's sooooo big
[07:16:49] <Lambda_Aurigae> sometimes I just touch the surface of the board and it will cause the oscillator to start if it doesn't start on its own.
[07:17:05] <LeoNerd> Though I think if I do another version of the board, I'll put one of the chips on the other side...
[07:17:11] <LeoNerd> The front is too crowded, the back is empty
[07:17:20] <Lambda_Aurigae> yeah.
[07:17:24] <Lambda_Aurigae> the beauty of SMT
[07:17:31] <Lambda_Aurigae> populate both sides of ye olde board.
[07:17:43] <LeoNerd> doubly-so for this board, as it's a daughterboard that plugs on top of another
[07:17:50] <LeoNerd> There's plenty of spare space around the connector on the bottom
[07:18:00] <Lambda_Aurigae> saw a tqfp in the middle of a board once....x, y, and z positioning.
[07:18:25] <Lambda_Aurigae> they had cut a hole in the middle of the board and set the chip in the hole...odd pins were on top...even pins were on bottom.
[07:18:46] <LeoNerd> Hah! Wow
[07:18:56] <Lambda_Aurigae> yeah...layout must have been a royal bitch.
[07:18:56] <LeoNerd> ... waitwhat? I'm sure you can't get a machine to do that...
[07:18:58] <RikusW> also read AVR040 and AVR042
[07:19:06] <LeoNerd> Forgetting layout; that would be killer on the PnP
[07:19:08] <Lambda_Aurigae> no..it was a one off hand made.
[07:19:14] <LeoNerd> You'd surely have ot hand-assemble
[07:19:18] <LeoNerd> Ahyes.. that makes sense then
[07:19:32] <LeoNerd> I've seen people make some pretty crazy deadbugs by hand
[07:19:49] <Lambda_Aurigae> they bent the odd pins down, set it in place, soldered even pins, bent odd pins to touch and soldered them.
[07:19:58] * LeoNerd hunts down AVR040/042
[07:20:16] <RikusW> Lambda_Aurigae: how do they mount a tqfp like that ?..
[07:20:44] <RikusW> ah
[07:20:48] <Lambda_Aurigae> 100 little legs sticking out all over...bend half up, half down.
[07:21:21] <RikusW> LeoNerd: its application notes on the atmel site
[07:21:40] <LeoNerd> RikusW: yesyes.. :) I just never manage to find them directly, except if I get lucky in google
[07:21:51] <Lambda_Aurigae> google search for avr040 should work.
[07:22:05] <LeoNerd> Lambda_Aurigae: Now I'm picturing a giant TQFP100 breakout board that turns it into a huge DIP-100 layout with two strips of 50 pins
[07:22:06] <RikusW> Lambda_Aurigae: sounds like a tricky time consuming business, imagine if one pin breaks off in the process...
[07:22:07] <Lambda_Aurigae> first link in a google search for avr040
[07:22:12] <LeoNerd> That'd justabout fit on a breadboard, right? :)
[07:22:22] <Lambda_Aurigae> almost.
[07:22:38] <Lambda_Aurigae> I have a tqfp 100 breakout board in a dip-100 layout.
[07:22:50] <LeoNerd> I think if you did a 144, you'd have to make 4 rows of 36
[07:22:51] <Lambda_Aurigae> I also have some 64pin dip package microprocessors here.
[07:22:55] <RikusW> AVR042 got the crystal part
[07:23:07] <Lambda_Aurigae> 68000
[07:23:14] <Lambda_Aurigae> gotta love the old toys!
[07:24:47] <Lambda_Aurigae> trying to remember who sold the atmega128 dip adapter boards here...I think it was pepsi...
[07:25:46] <vsync_> take it to the next level
[07:26:43] <Lambda_Aurigae> going to do just that.
[07:26:47] <Lambda_Aurigae> time to go to work and install copiers.
[07:27:49] <RikusW> LeoNerd: AVR042 -> 5.4 Unbalanced external capacitors
[07:28:11] <LeoNerd> Ahyes.. I was reading 040 first. It has some useful general ideas
[07:28:59] <RikusW> you might be able to fix this by adding a few pF to the short trace
[07:29:01] <LeoNerd> It talks about "high-frequency" in general terms though... My clock is 14.7456, and then nothing else runs near that... Does that conut?
[07:31:19] <RikusW> LeoNerd: try checking the clock duty cycle if you have a scope
[07:32:11] <LeoNerd> Ah, afraid not. I could apply multimeter freq probe to it, but that's all. It doesn't do dutycycle
[07:32:35] <vsync_> what's the problem?
[07:32:37] <vsync_> too lazy to scroll
[07:32:53] <LeoNerd> vsync_: Disappointing accuracy of UART baud rate
[07:33:16] <LeoNerd> I'm getting way more byte corruption errors on my "real" production PCB, than I got on my breadboard prototype
[07:39:14] <LeoNerd> Huhh... AVR042 is quite interesting. E.g. they suggest a 330R resistor in series with any 'reset' button
[07:39:21] <LeoNerd> I've never seen anyone do that in practice
[07:42:56] <LeoNerd> Also, I'm pondering making myself a little 6pin->6pin isolator for ISP
[07:43:04] <LeoNerd> Does such a thing exist, or would I have to make it?
[07:43:41] <LeoNerd> Am thinking either opto or some of those fancy capacitor-based isolators. It's basically SPI, right? The idea being to galvanically isolate, and also disconnect the target voltage, so it doesn't get upset
[07:44:28] <RikusW> opto might be too slow, unless you use the high speed ones
[07:45:08] <LeoNerd> Analog do some nice high-speed capacitance-based ones
[07:45:14] <LeoNerd> ADu1401 comes to mind
[07:45:37] <LeoNerd> That on a little board with a 2x3 connector on either side... nicely inline in my cable
[07:45:45] <LeoNerd> ADuM1401 even
[07:46:03] <LeoNerd> Oh it's not cap, it's linked transformer... weird
[07:46:27] <LeoNerd> But anyway, they claim DC to 90MHz, so that's more than sufficient
[07:48:55] <vsync_> LeoNerd: by the way, forgot to thank for the tip. The saleae clone works perfectly, haven't got the need so far to go beyond 4MHz, but works a treat. And yeah, the clips were horrible but I've already made my own ones
[07:49:18] <LeoNerd> :) Nice to hear
[07:59:42] <LeoNerd> RikusW: Aahhh... AVR042 section 4.4 talks specifically about unbalanced caps, and how it might upset the duty cycle, which is especially bad near the max freq. I wonder if that's my problem
[08:00:52] <RikusW> its possible
[08:01:02] <LeoNerd> Also I really should find a smaller crystal package. This one is way too big :(
[08:01:22] <RikusW> since the longer track got more capacitance, though I'm not sure how much it could be
[08:01:50] <LeoNerd> Hrm.. my longer track is XTAL2 though, which is the driven side of the osc.
[08:02:06] <RikusW> HC49 seems smallat first glance, until you do some pcb layout ;)
[08:02:48] <LeoNerd> Yeah
[08:03:03] <LeoNerd> I found some fairly nice 3mm x 2mm BGA-style ones, but I don't fancy hand-soldering those
[08:03:06] <RikusW> If you find a small smd one at a comparable price I'd like to know
[08:03:19] <RikusW> so far it seems those are more expensive
[08:03:53] <RikusW> BGA or QFN ? like only 4 pads underneath ?
[08:04:00] <LeoNerd> BGA-ish.. not quite balls
[08:04:09] <LeoNerd> but no real pads overlapping outside... they seem verymuch made for paste+bake
[08:04:37] <RikusW> I've seen 4 square pads coming to the outside
[08:04:50] <RikusW> might be quite possible to hand solder those
[08:04:56] <LeoNerd> Looks quite fiddly
[08:06:36] <LeoNerd> http://uk.farnell.com/abracon/abm7-14-7456mhz-b4-t/crystal-14-7456m-18pf-cl-6x3-3mm/dp/1611817 e.g. this one
[08:06:40] <RikusW> removing HC49 smd can be difficult, requires two irons ;)
[08:07:02] <LeoNerd> Heh.. I don't usually bother removing bits... My boards come in threes
[08:07:34] <LeoNerd> http://uk.farnell.com/abracon/abm3b-14-7456mhz-10-1-u-t/crystal-14-7456mhz-10pf-5-x-3/dp/2467805RL also this
[08:07:49] <LeoNerd> I don't think that looks hand-solderable
[08:11:41] <vsync_> you can
[08:11:54] <vsync_> but at least i need some
[08:11:58] <vsync_> magnification
[08:12:32] <vsync_> if you need it to a pcb well hot air works fine
[08:15:56] <LeoNerd> Oh I have a magnifier
[08:16:07] <LeoNerd> Needed that for 0603s and SOT23-5 regs
[08:16:54] <twnqx> they are not easy, but possible
[08:17:21] <twnqx> or well
[08:17:25] <RikusW> 0603 are not that hard
[08:17:32] <twnqx> they are not as trivial as 0402 and the likes
[08:17:38] <RikusW> 0402 well...
[08:17:43] <LeoNerd> The main trouble with 0402s is that they melt through took quickly
[08:17:44] <twnqx> but they are pretty easily hand solderable even with an iron
[08:17:47] <LeoNerd> too
[08:17:49] <twnqx> what
[08:18:01] <LeoNerd> I -sometimes- manage to melt through an 0603, but not often
[08:18:02] <twnqx> tht... never happened to me, ever
[08:20:25] <twnqx> but reading you i kinda feel lucky
[08:20:49] <twnqx> i never used magnifiers except for solder bridge checking after the job
[08:32:07] <vsync_> oh cool. at least got the nrf8001 to pair now. kind of hard to debug it but at least ble is highly async so makes it a bit easier
[08:52:06] <vsync_> wow. progress. at least i can make nordic's uart over ble android app crash now
[08:52:21] <LeoNerd> That's a *kind* of progress
[08:52:31] <vsync_> yeah.
[08:52:49] <vsync_> still kind of confused with the service discovery sequence
[08:54:21] <vsync_> code basically waits for a pair to happen, then reads the pipe availability and starts bombing out data in a pipe that it seemingly open --
[08:56:04] <vsync_> the service discovery *should* be completed when the nrf chip sends out the pipe availability packet, but the bit indicating the status is set to 0. This sucks.
[08:56:19] <vsync_> service discovery is automatic, so heh. Well. Need to do some digging
[08:56:51] <vsync_> worst part of this is that pretty much the only example code for this is the nordic's arduino sdk which is a huge pain in the ass to go through
[09:49:11] <aczid> anyone here know a good howto to compile the bleeding edge avr-gcc toolchain?
[09:49:48] <aczid> instructions on the website are a bit outdated it seems
[09:55:51] <Lambda_Aurigae> I haven't compiled the toolchain in about 3 years.
[09:56:03] <Lambda_Aurigae> always just use the one from atmel or from my current linux distro.
[09:56:19] <Fleck> same here!
[09:56:21] <LeoNerd> yah; me too.. the one in debian is new enough for the tiny841 I use
[09:57:06] <LeoNerd> Though I did have to add config for avrdude
[10:03:37] <aczid> hmm, yeah... I want to actually add some device support. :(
[10:04:03] <aczid> it builds, and it compiles stuff. but the binaries are not yet 'right' somehow :S
[10:04:15] <Lambda_Aurigae> that's not a trivial job.
[10:04:19] <aczid> interrupt vector table looks okay, all of the stuff seems to be there
[10:04:23] <aczid> I know
[10:04:38] <Lambda_Aurigae> such a question would best be posted to the avr-gcc mailing list.
[10:05:00] <aczid> I guess, I was hoping for a chat though
[10:05:50] <Lambda_Aurigae> the instructions for building it shouldn't have changed much at all really.
[10:05:56] <aczid> well, writing the patch for avr-libc was fairly simple. gcc/binutils only need to know a new device name that is associated with this core
[10:06:18] <Lambda_Aurigae> I'm not at home at the moment so can't really do much with testing a build process.
[10:06:29] <aczid> well, I got the config line from the Atmel gcc build, and see they also included the bignum stuff. so I compiled that in my tree too for the second try
[10:06:34] <Lambda_Aurigae> kinda remoted into my home compy from work while I sit here and watch copiers update.
[10:06:56] <aczid> no worries, I don't need it done today
[10:07:04] <aczid> :)
[10:07:25] <Lambda_Aurigae> remind me in about 8 hours and I'll see about grabbing sources and building.
[10:07:26] <aczid> one thing missing from the instructions on the website was to include --with-newlib in the configure line
[10:08:03] <aczid> it seems also not every version of binutils is 'compatible' or 'works' with every version of gcc. which I haven't really gotten into :S
[10:08:18] <Lambda_Aurigae> yeah.
[10:08:29] <Lambda_Aurigae> you gotta keep them together...newest should work with newest generally.
[10:08:38] <aczid> yes that's what I figured :)
[10:09:03] <aczid> I'll take a look at the build scripts some other people wrote in the past
[10:09:05] <Lambda_Aurigae> back 5 or 6 years ago I had a script that would download and build the newest set automagically.
[10:09:15] <aczid> yeah there are a few of those around
[10:09:30] <aczid> but I'm afraid a script from 2010 isn't really goign to cut it
[10:09:55] <Lambda_Aurigae> can always run it and see what happens then mod the script to fit.
[10:10:01] <aczid> do you know if atmel ever released their script for linux builds?
[10:10:10] <aczid> yes, I suppose I will do that
[10:10:18] <aczid> and also examine the elf files some more
[10:10:25] <Lambda_Aurigae> no clue on atmel build script.
[10:10:43] <Lambda_Aurigae> I often just use their current build...it seems to include all modern processors.
[10:11:01] <Lambda_Aurigae> even though it is usually a version or two old overall.
[10:11:38] <aczid> well, it's built on gcc. and gcc doesn't have my chip in the trunk
[10:11:49] <aczid> so woe is me :)
[10:12:05] <aczid> err, avr-libc*
[10:12:42] <Lambda_Aurigae> one of the new attiny chips?
[10:12:51] <aczid> it has similar chips though, which is why writing a patch was fairly easy. I'm sure I can just use Atmel's toolchain with my own libc and just build for a similar chip with the same core
[10:12:59] <aczid> but I want to know what I'm doing wrong
[10:13:04] <Lambda_Aurigae> I know as you get smaller atmel doesn't really support C on them due to their limitations.
[10:13:31] <aczid> this is supported. I have a working project. it's one of their automotive products
[10:13:36] <aczid> hence fairly little support :)
[10:13:57] <aczid> they want you to pay 1500$ for the IAR compiler with this hardware. lol
[10:14:22] <aczid> it has 4k flash on an avr5 core, so C is no problem
[10:14:32] <aczid> 4k words, so 8kb
[12:01:07] <Chillance> anyone here know how I can combine a DFU bootloader with mine into one .hex file?
[12:04:59] <aczid> I think the recommended practice is to not combine the two into one hex file..
[12:05:59] <Chillance> problem is the manufacturer can't use 2..
[12:17:30] <Casper> put the main code at the begening then put the bootloader at the end of the .hex and try?
[12:22:01] <aczid> yes I think something like that is also described in that pdf about avr bootloaders
[12:22:12] <aczid> right after it says you shouldn't do that :P
[12:22:37] <aczid> this one
http://blog.schicks.net/wp-content/uploads/2009/09/bootloader_faq.pdf
[12:22:58] <aczid> search the file for srec_cat
[12:23:26] <aczid> btw I found out my custom-built avr-gcc can at least blink a led on my device :)
[12:24:13] <aczid> hmm, actually I guess he was talking more about making the bootloader and app into a single project. nm
[12:24:21] <aczid> section 13
[12:52:24] <aczid> hey, I did a bit more testing and it seems the toolchain mostly works. a few minor differences but I have a working firmware that I can check out with debugwire
[12:58:32] <aczid> everything works. just had 1 failing unit test, so PEBKAC
[13:30:27] <vsync_> aren't iar and all the rest like $x for starters and then $y yearly
[14:09:20] <aczid> I really don't know vsync_. and am not very interested in finding out
[14:11:59] <aczid> I just heard that number quoted
[17:30:30] <aczid> I'm happy to report my newly added device fully works ^^
[17:30:42] <LeoNerd> :)
[17:30:47] <LeoNerd> What device is it?
[17:31:01] <aczid> one of the automotive key fob chips
[17:31:05] <aczid> ata5790N
[17:31:22] <LeoNerd> Ah
[17:33:18] <aczid> they are quite cool
[17:33:50] <aczid> need to write the avarice patch still
[17:34:00] <aczid> but it works(!)
[17:34:18] <aczid> so for all you who fear the avr toolchain build process: it is totally possible :)
[17:35:10] <aczid> I'm happy to share my script/steps if anyone is interested
[17:56:44] <Lambda_Aurigae> aczid, post it somewhere.
[18:01:35] <aczid> sure, give me a sec
[18:03:45] <aczid> https://gist.github.com/aczid/22a34af18a5693f98bf9
[18:04:03] <aczid> simulavr trunk didn't want to build out-of-tree
[18:04:16] <aczid> it'll probably build fine in-tree
[18:04:33] <aczid> i patched it a bit but I don't see an immediate need to send it upstream
[18:04:39] <Lambda_Aurigae> I don't use simulavr.
[18:07:48] <aczid> so a key thing is --with-newlib
[18:07:54] <Lambda_Aurigae> seems so.
[18:08:12] <aczid> a few other things are probably best disabled, like shared memory
[18:08:28] <Lambda_Aurigae> yeah..you have a lot of extras in there I never used before.
[18:08:32] <aczid> the docs should probably mention those
[18:08:52] <aczid> I got those flags from running gcc -v from atmel's build
[18:09:12] <aczid> well, a bunch of them at least
[18:09:33] <Lambda_Aurigae> it has changed a lot since last time I built it.
[18:09:56] <aczid> it would be cool if the docs on the website could be updated
[18:10:01] <aczid> I'm not sure who to contact about that
[18:10:19] <aczid> they are otherwise correct
[22:50:05] <rak[1]> wahoo! blinkenlights! success in getting avr toolchain working in gentoo and using microscheme!
[23:04:44] <mark4> ok so i cant remember... does a call opeocde push lo or hi byte of ip first?
[23:22:14] <Casper> I think I figured out part of the timer1 on the tiny85...
[23:23:32] <Jartza> morning
[23:25:27] <Casper> j/
[23:25:29] <Casper> o/
[23:41:53] <mark4> the xch opcode on avr's xch z, rx <-- is that an 8 bit or 16 bit operation (does it work on register pairs i mean)
[23:43:04] <mark4> if so im not getting the atmega32u4 instruction set doc because it says that the operand is 0 < Rd < 31 <--- r0 through r8 cant be register pairs i thought
[23:43:53] <mark4> the ONLY thing the document i have says about xch is (z) -< rd, rd <- (S(z)
[23:44:05] <mark4> er typed that blind lol sorry
[23:44:25] <mark4> erm (z) a memory address? this is swapping with memory? not between registers?
[23:44:26] <mark4> blargh
[23:44:44] <Casper> that's why I don't do asm :D
[23:45:28] <mark4> no register swap... sucks lol
[23:49:42] <mark4> ive not touched avr in about 4 years, been doing horrible arduino crap for work, i HATE object obfuscated c++
[23:50:08] <mark4> i think C is mutually exclusive with embedded dev, c++ is orders of magnitude worse
[23:50:45] <mark4> i just implemented an xbee mesh network for xbee. the xbee arduino library doesnt support mesh
[23:50:50] <Jartza> mark4:
http://www.avrfreaks.net/forum/help-understanding-xyz-registers
[23:50:51] <Jartza> :)
[23:51:33] <mark4> so i write it from scratch in C and ive used up 60% of my code and 80% of my ram
[23:52:06] <mark4> Jartza, i kind of understnd x/y/z, i implemented my own avr assembler in forth 4 years ago, i just didnt understand the xch opcode
[23:52:19] <mark4> didnt realise that (z) means (the byte pointed to by z)
[23:52:36] <mark4> tho i need a refresher course in avr so im reimplementing my forth lol
[23:52:51] <mark4> from scratch. nothing wrong with old one, but i think i can do it better
[23:52:56] <Jartza> xch seems to be quite new command
[23:53:07] <Jartza> the avr instruction set manual doesn't say much about it
[23:53:35] <Jartza> mmkay, the atmel website has a bit longer story
[23:53:36] <Jartza> http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_XCH.html
[23:53:38] <mark4> ya. cuz it takes a huge effort to write a 1 paragraph explanation for this snazzy new opcode
[23:54:26] <mark4> yea. they wasted opcode space on that one
[23:54:41] <mark4> should have implemented a register to register exchange instead
[23:54:41] <Jartza> umm
[23:54:51] <Jartza> the PDF I have (AVR instruction set) says (Z) ← Rd, Rd ← (Z)
[23:54:57] <mark4> yes
[23:55:07] <Jartza> and the web documentation says (Z) ← Rd,(Z) ← Rd
[23:55:08] <mark4> thats what im looking at too. i didnt realise the () meant memory address
[23:55:17] <Jartza> wtf
[23:55:22] <mark4> web seems wrong
[23:55:26] <Jartza> indeed
[23:55:27] <mark4> pdf i think is right
[23:55:33] <Jartza> the latter would not make sense :)
[23:55:38] <mark4> correct
[23:55:47] <mark4> unless they need to do the operation twice to make sure it happens :)
[23:56:49] <Jartza> hehe
[23:57:06] <Jartza> las, lat, lac and xch are quite new instructions
[23:57:33] <mark4> yes my assembler doesnt implement them
[23:57:37] <mark4> they are new as of 4 years ago
[23:57:43] <mark4> and they are STILL not documented?
[23:58:08] <mark4> guess atmel is too busy sucking up to microchip and putting support for microchips devices in the dragon
[23:58:13] <mark4> DUMBEST fucking thing ever
[23:58:48] <mark4> maybe 3 years ago
[23:59:23] <Jartza> to me those commands look like they are meant only for devices with USB
