Back
[02:06:28] <rue_bed> Tom_itx, yes I know, but there is hardware linking between character transmission and the cts rts signals
[03:26:22] <theBear> rue_bed, not for the last 10 or 15 years there isn't
[03:41:58] <rue_bed> nobody seems to know, if you drop cts in the middle of a byte, how many other bytes come thru till the data stops
[03:42:16] <rue_bed> it really scerwed me over on the plotter I was making for rifraf
[03:42:42] <rue_bed> the computer wouldn't stop sending even when I held cts,
[03:42:53] <rue_bed> the software WAS in hardware handshake mode
[03:43:04] <rue_bed> and it didn't matter what state I held it
[03:43:33] <rue_bed> hpgl plotters need a working cts line
[03:52:03] <theBear> hmmm.. i'd have to read the spec, i'm tempted to say that cts is checked at the start of each byte
[03:52:44] <theBear> you gotta think back to why they made the 'protocol' like that, and the hardware that was talking it at the time... all 'dumb' ttl stuff, no processing time available etc etc..
[06:15:29] <tlvb> ah, the joy of learning the utility of backups...
[06:26:16] <Lt_Lemming> had a drive die?
[06:38:31] <rhumbot> hi all. could someone suggest a beginners guide to uart? i am looking for somthing that explains exactly what kind of programs i need etc. preferably based on linux ...
[06:41:55] <theBear> erm, uarts are kinda an abstract thing from inside an os
[06:42:24] <theBear> for example in linux you can just setserial for the rate/various options at the uart level, then simply send/read characters from /dev/ttyS?
[06:49:54] <specing> rhumbot: datasheet
[06:50:12] <specing> rhumbot: man termios
[06:54:46] <tlvb> Lt_Lemming: no, borked my last git commits --hard
[06:54:58] <Lt_Lemming> heh
[06:54:59] <Lt_Lemming> well done
[06:55:41] <tlvb> git bork --hard --no-mercy HEAD~1
[07:03:57] <rhumbot> specing what do you mean?
[07:05:24] <sabesto> rhumbot: screen `ls /dev/{ttySx,name}` 115200
[07:05:31] <sabesto> for instance
[07:06:18] <rhumbot> sorry guys i dont understand a word you are talking about. i am really looking for a beginners guide ...
[07:06:41] <sabesto> rhumbot: you want to open a serial port on unix?
[07:07:29] <sabesto> the guide is 1 line long
[07:08:21] <specing> rhumbot: man termios
[07:08:21] <rhumbot> no. i want a beginners guide to uart
[07:09:35] <sabesto> on unix of avr?
[07:10:24] <rhumbot> if possible based on unix... and for avr ...
[07:10:35] <specing> rhumbot: man termios
[07:11:02] <rhumbot> i read that before but i still dont know what you mean
[07:11:30] <theBear> uart is a concept/thing, you learn about them the same regardless of what you are planning to utilise them for in the future
[07:12:21] <rhumbot> i agree ... so?
[07:12:56] <sabesto> google uart wiki and read that at least
[07:13:12] <theBear> so lookup uart in wiki or somewhere.... stop mentioning things like os's and micro families
[07:13:56] <theBear> maybe lookup serial too, that's more what you are doing from a programming point of view
[07:14:55] <sabesto> i learned about uart reading datasheets for microcontrollers
[07:15:43] <sabesto> there is probably a guide, but i guess you can google as well as me. no particular one comes to mind
[07:15:47] <theBear> mmm, once you got a dictionary definition of uart, a micro datasheet (ie. avr) should fill in the practical details
[07:16:44] <theBear> even lookup a 16450/550 datasheet, those were pretty much used by every pc between somewhere in the mid 80's and when multi-io-all-in-one controllers got popular around the turn of the century
[07:17:02] <rhumbot> well once you realize how things work its always easy ...
[07:17:21] <theBear> you looked at wikipedia yet ?
[07:18:27] <rhumbot> the concept is not the problem. but i still dont realize how to use it
[07:19:05] <theBear> conceptually, you tell a uart the specs you want the serial link to operate at, then just feed/read data to/from it
[07:19:09] <theBear> simple as that
[07:19:57] <sabesto> well, "how to use it" depends on the platform, hence the question "avr/unix or what"
[07:20:31] <sabesto> you cant do UDR1 = 0xFF in bash and hope to send data
[07:22:31] <theBear> in a pc they land at a 'memory address' and have an irq they can tickle and from memory have 3 bytes or so exposed, read byte, write byte and control
[07:22:49] <theBear> of course in a modern pc you got no chance of talking to a memory address from within an os directly
[07:23:26] <specing> rhumbot: manpages, use them
[08:38:53] <Kevin`> rhumbot: have your avr send human-readable text. then you can just do 'screen /dev/ttyUSB0' or similar and not have to write a host-side application
[08:51:51] <tlvb> the UDRE interrupt fires until UDR is written or the interrupt is disabled in UCSRB, right?
[08:54:24] <tlvb> or is the UDRE flag automatically reset when entering the ISR/
[09:47:00] <sabesto> so, i havent touched scripting/programming on a computer before, but i need to format some text files (3kB bitmaps from array to 2d array) what would be the best way to do that?
[09:47:18] <OndraSter> C#
[09:47:21] <OndraSter> :)
[09:47:26] <OndraSter> easiest
[09:48:03] <sabesto> i was thinking some unix scripties. would be handy to learn for other stuff like log file parsing
[09:48:22] <sabesto> if C# i might aswell send it to an avr and process it there :P
[09:48:44] <OndraSter> cluster of AVRs!
[09:48:44] <OndraSter> lol
[09:49:44] <sabesto> bah, i'll just do it on an avr :P
[09:50:02] <sabesto> i can fit all the data in progmem, then just spew it out using uart
[09:52:44] <OndraSter> how can Linux work on Cortex-M0 or M3 when it is harvard and doesn't support executing from RAM?
[09:56:21] <tlvb> sabesto: python would probably be the easiest
[09:58:40] <tlvb> sabesto: to stress test my usart I generated 33MB of data, transfering it to the computer and then used python + python imaging library to make a png of it
[09:58:55] <sabesto> hehe
[09:59:19] <sabesto> well, one thing is certain, i'm tired of editing these txt files by hand
[09:59:40] <sabesto> fine in the start for testing, but now i got 20 x 3kB
[09:59:45] <tlvb> if it is /text/ text then perl may be a good option too
[10:00:16] <tlvb> even so, python may be easier if you don't know perl
[10:00:23] <tlvb> (or python)
[10:00:32] <Kevin`> OndraSter: since when is cortex-m0/m3 harvard? I thought it was a fairly normal arm core. I also thought it was lacking in features useful for linux (although uclinux tends to work on stuff like that)
[10:00:36] <sabesto> its just "static uint8_t bat1[34][9] PROGMEM = {
[10:00:37] <sabesto> {0x80, 0x00, 0x00, 0x00"
[10:00:41] <sabesto> and so on
[10:01:10] <OndraSter> Kevin`, hmm I must have misread it somewhere
[10:01:14] <OndraSter> it was drilling my head as well
[10:01:19] <OndraSter> since they have one address space
[10:02:23] <tlvb> sabesto: perl should handle that fine
[10:02:38] <tlvb> sabesto: is it a single line?
[10:04:28] <sabesto> no, CR / LF
[10:04:39] <sabesto> aswell
[10:28:08] <tlvb> sabesto: try piping your "static ... };" into
http://pastebin.com/hFPfGU3w
[10:31:27] <karlp> isn't there a format option for xd or something that generates C header files for you?
[10:31:49] <tlvb> xd?
[10:31:55] <karlp> xxd -i
[10:32:15] <karlp> turns a .bin into a .h...
[10:33:56] <tlvb> maybe there is, I thought he wanted foo[2][2] = {1, 2, 3, 4} to turn into foo[2][2] = {{1,2},{3,4}}
[10:38:35] <karlp> oh, yeah, that's different sorry
[13:32:25] <TitanMKD> hi
[13:32:26] <tobbor> hi TitanMKD.
[13:32:44] <TitanMKD> which one want to test NFC streaming with MP3 ?
[13:32:54] <TitanMKD> could be fun
[13:33:45] <specing> ?
[13:33:46] <TitanMKD> anyway i really doubt an AVR MCU will be enough fast for such stuff (especially to encode the stream in realtime @848KHz or even 424KHz)
[13:34:20] <TitanMKD> specing it is about music streaming over NFC
[13:34:27] <specing> you are wrong
[13:34:48] <specing> they are not even NEAR doing that
[13:35:00] <TitanMKD> ?
[13:35:04] <Steffanx> abcminiuser TitanMKD .. not here atm
[13:35:09] <TitanMKD> ok
[14:00:29] <Casper> TitanMKD: actually, an avr is plently fast enought if you have the proper hardware around it
[14:01:35] <Casper> TitanMKD: basically, all you have to do is use the right mp3 codec, and some even have build in SD card reader and filesystem decoder and all
[14:02:27] <Casper> so all the avr do to make a mp3 player is: take care of the display and controls... some IC even have the output to the DAC...
[14:02:33] <TitanMKD> Casper I prefer to have faster MCU but i have not the same need as you
[14:03:08] <TitanMKD> Casper for example on NFC stuff RAW data you need lot of power to sniff and decode data in realtime and especially at 848kbps
[14:04:12] <Casper> it all depend on the hardware and all
[14:04:38] <Casper> I've seen NTSC generation with avr... color at that... in real time
[14:06:52] <TitanMKD> Casper anyway for my needs ARM M3/M4 is required with fast speed and DMA
[14:07:30] <Casper> possible
[14:07:39] <Casper> your needs or the way you want to do it
[14:12:04] <OndraSter> I checked prices today
[14:12:15] <OndraSter> LPC1111 is cheaper than xmega16d4
[14:12:32] <OndraSter> the LPC1111 is cortex m0 with 8kB flash, 2kB RAM, 50MHz
[14:12:34] <OndraSter> 32bit
[14:12:41] <OndraSter> and it is cheaper!
[14:12:54] <TitanMKD> OndraSter yes ARM MCU are cheaper and really faster
[14:12:59] <OndraSter> in the "cheap" part there has cortex huge advantage over AVR
[14:13:11] <OndraSter> then there is point where xmegas are better (unless you need raw speed)
[14:13:21] <OndraSter> and then it goes back to M3/M4/ARM9
[14:13:40] <TitanMKD> OndraSter I really doubt any AVR MCU is better than an ARM M4 MCU especially with Thumb2
[14:13:51] <OndraSter> yes, there is not :)
[14:14:03] <OndraSter> but, as I said many times,
[14:14:09] <OndraSter> xmega256a3u for 3.9€
[14:14:15] <OndraSter> about $4.98
[14:14:19] <OndraSter> at 1 pcs
[14:14:23] <OndraSter> piece*
[14:14:35] <OndraSter> USB, 256kB/16kB, thousand peripherals
[14:14:47] <OndraSter> dual ADC 2MSPS each, single 2channel DAC 1MSPS
[14:15:36] <TitanMKD> OndraSter STM32F4 Discovery ADC 6MSPS ;)
[14:15:45] <OndraSter> dual 12bit?
[14:15:50] <TitanMKD> OndraSter now 8bits
[14:16:00] <OndraSter> oversampling won't give you much
[14:16:18] <OndraSter> I'd much prefer the dual 12bit 2MSPS than single 8bit 6MSPS honestly
[14:16:23] <TitanMKD> but anyway i do not use it for ADC ;) but for fast IO with GPIO up to 84MHz
[14:16:31] <OndraSter> yes, that is cool
[14:17:02] <TitanMKD> but LPC43xx is even better ;)
[14:17:14] <OndraSter> and even more expensive :P
[14:17:16] <TitanMKD> with SGPIO @ 102MHz on up to 16GPIO
[14:17:31] <TitanMKD> OndraSter but it is dual core ;)
[14:17:36] <OndraSter> I know
[14:17:38] <OndraSter> m3 + m0
[14:17:49] <OndraSter> or m4 + m0?
[14:17:52] <OndraSter> well, something like that
[14:17:54] <TitanMKD> M4 + M0
[14:18:05] <TitanMKD> M4F in fact with floating point
[14:18:11] <TitanMKD> but 32bits only ;)
[14:18:20] <OndraSter> still 32bits more than AVR
[14:18:24] <TitanMKD> and pratically all instructions are single cycles
[14:18:43] <OndraSter> as long as the flash has 0wait state..
[14:18:44] <TitanMKD> OndraSter I have done some benchmark on LPC4330 and it is amazing ;)
[14:19:14] <TitanMKD> OndraSter yes it requires to be loaded in SRAM else the performance are crappy like 5MIPS instead of 203MIPS
[14:19:23] <TitanMKD> OndraSter tested with SPIFI ;)
[14:19:23] <OndraSter> as in execute from RAM?
[14:19:29] <TitanMKD> yes in worst case
[14:19:49] <TitanMKD> because there's a hidden peripheral cache of 256bytes
[14:19:53] <OndraSter> what is the maximum master clock of that baby?
[14:19:58] <TitanMKD> 204MHz
[14:20:01] <OndraSter> hmm
[14:20:06] <TitanMKD> for both cores ;)
[14:20:16] <TitanMKD> also tested the 2 cores in // ;)
[14:20:17] <OndraSter> would it beat TI AM1705 + external CPLD as display driver?
[14:20:26] <TitanMKD> with SGPIO yes
[14:20:30] <OndraSter> it would have much better advantage because it could share RAM
[14:20:38] <OndraSter> I need about 24MHz (IIRC) for that
[14:20:39] <Corwin> it really looks this channel is not about AVRs anymore :)
[14:20:45] <OndraSter> Corwin, AVRs got competition
[14:20:52] <TitanMKD> SGPIO is like advanced CPLD you can do LCD display with 0 cpu overhead
[14:21:15] <OndraSter> SGPIO is some serial line?
[14:21:21] <OndraSter> or wait
[14:21:24] <OndraSter> is that different SGPIO? :D
[14:21:29] <TitanMKD> OndraSter yes but very customizable with some slice
[14:21:36] <OndraSter> I need parallel
[14:21:39] <OndraSter> about 30 lines
[14:21:40] <TitanMKD> you can do SPI with 8 data lines
[14:21:51] <TitanMKD> it does serial to parallel or the reverse
[14:22:07] <TitanMKD> it is limited to 16 SGPIO not 30 ;)
[14:22:13] <OndraSter> 24bit colors (okay, 16 would be enough as well) + dotclk + vsync + hsync
[14:22:30] <TitanMKD> OndraSter but there's also LCD port for that which support even HDMI ;)
[14:22:38] <OndraSter> I don't need HDMI
[14:22:44] <OndraSter> I need 5" screen on the front ;D
[14:22:47] <OndraSter> need = want
[14:22:49] <TitanMKD> it is supported ;)
[14:23:01] <TitanMKD> all types of LCD from 8bits to 24bits
[14:23:07] <OndraSter> hmm
[14:23:09] <OndraSter> but
[14:23:11] <OndraSter> the one with LCD
[14:23:13] <OndraSter> = BGA
[14:23:14] <OndraSter> I BET!
[14:23:17] <OndraSter> it is ALWAYS!
[14:23:19] <TitanMKD> no ;)
[14:23:23] <TitanMKD> LQFP 208
[14:23:37] <OndraSter> OOOOO
[14:23:51] <OndraSter> but, will be 200MHz enough for x86 emu?
[14:23:54] <TitanMKD> with also external bus 32bits ;)
[14:23:55] <OndraSter> 486 or Pentium I
[14:24:20] <TitanMKD> I doubt it will be a good x86 emulator 204Mhz is too little for such task ;)
[14:24:32] <OndraSter> that's why I wanted the TI AM1705
[14:24:33] <TitanMKD> or maybe 486@50MHz
[14:24:35] <OndraSter> @ 450MHz
[14:24:52] <OndraSter> BUT no LCD interface (only AM1707 but that is BGA crap)
[14:24:58] <OndraSter> 16bit SDRAM interface
[14:25:25] <TitanMKD> OndraSter you can do it with a little CPLD too
[14:25:32] <TitanMKD> using External Bus
[14:25:38] <OndraSter> do what?
[14:25:44] <TitanMKD> the LCD interface
[14:25:48] <OndraSter> yes
[14:26:05] <TitanMKD> LCD is not so complex IIRC
[14:26:11] <OndraSter> yes it is not
[14:26:18] <OndraSter> just keep sending data with dotclk
[14:26:22] <OndraSter> & sometimes hsync/vsync signals
[14:26:34] <TitanMKD> but ARM9 is quite old
[14:26:52] <TitanMKD> even at 456MHz maybe LPC43xx @ 204Mhz is better ;)
[14:26:59] <TitanMKD> especially LPC43xx as dual core
[14:27:03] <OndraSter> I thought that ARM9 was more highend
[14:27:15] <TitanMKD> yes less optimized for embedded stuff
[14:27:52] <TitanMKD> interrupt latency is bigger and have less pipeline and also lot of instructions take more than 1 cycle ;)
[14:28:02] <OndraSter> hmm
[14:28:03] <OndraSter> sucks!
[14:28:34] <TitanMKD> maybe you need something like an OMAP processor like Ti Pandboard
[14:28:39] <TitanMKD> but it's BGA
[14:29:07] <OndraSter> :/
[14:29:12] <OndraSter> I don't want BGA for one simple reason
[14:29:21] <OndraSter> to route out all the pins one needs more than 2 layers
[14:29:39] <TitanMKD> yes but for LQFP 208 it also requires more than 2 layers
[14:29:44] <TitanMKD> at least 4 layers
[14:30:03] <TitanMKD> for BGA it is even maybe 6 or 8 layers
[14:30:16] <OndraSter> 4 layers is still acceptable
[14:30:24] <OndraSter> oh well
[14:30:34] <OndraSter> I think I will keep this project as a bachelor work
[14:30:45] <OndraSter> or even magister (engineer) project
[14:30:52] <OndraSter> that's 3 or 5 years till now
[14:30:57] <OndraSter> maybe even more :D
[14:31:03] <TitanMKD> hehe yes ;)
[14:31:43] <TitanMKD> OndraSter you can start with a PandaBoard there's lot of power to Emulate even a Pentium pro @ 200Mhz I think
[14:31:58] <OndraSter> but pandoraboard is like $200
[14:32:42] <TitanMKD> yes but not so expensive for the power behind
[14:33:15] <TitanMKD> OndraSter the only missing stuff on it is SATA port because SDcard slow down all :(
[14:33:23] <OndraSter> heh
[14:33:28] <OndraSter> SATA SSD? :D
[14:33:31] <TitanMKD> yes ;)
[14:33:45] <OndraSter> I have got IDE SSD in my tablet!
[14:33:49] <OndraSter> easier to emulate :D
[14:33:58] <OndraSter> doesn't need fast data streams
[14:34:01] <TitanMKD> this SDCard slot as main HDD is an epic fail ;)
[14:35:53] <OndraSter> "America Inching Towards the Metric System"
[15:09:48] <cehteh> you forgot that the Pi purpose is low cost, not performance
[15:09:59] <cehteh> ARM + Sata is expensive still
[15:10:43] <cehteh> and with recent kernels and tuning SD card is fast enough, you get performance comparable to low end laptop HDD's without the latency, so overall its even quit better
[15:11:12] <TitanMKD> cehteh until now it is really not the case with my PandaBoard
[15:11:59] <TitanMKD> cehteh because mainly accelerated driver for 2D is not enabled and all is slow like a very old computer
[15:12:16] <cehteh> yes .. and?
[15:12:37] <TitanMKD> it is just not usable even too look a movie at 10fps
[15:12:42] <cehteh> no one saied you get a number crunching monster for $35
[15:12:56] <TitanMKD> cehteh i was speaking about Pandaboard at 200US$ ;)
[15:13:03] <cehteh> even there
[15:13:39] <TitanMKD> cehteh it is not really hw problem but sw problem but i think Linaro one day will have all in one to have decent speed
[15:13:50] * cehteh waits for a affordable ARM based server platform .. 4 or more SATA's, 1GB ram minimum and 2x1Ghz smp or likewise
[15:13:54] <cehteh> better 4GB ram :)
[15:14:15] <cehteh> affordable is the point :)
[15:14:20] <TitanMKD> cehteh yes the next step for ARM Cortex A15 seems ready for server purpose
[15:14:39] <cehteh> could cost $200 but shouldnt be much more than a comparable atom platform
[15:14:59] <cehteh> (little more is ok when you account for saving power)
[15:15:14] <TitanMKD> of course even now with Cortex A9 it is more powerfull than any atom ;)
[15:15:46] <cehteh> and decent networking please
[15:16:14] <cehteh> yes but the platforms suck as there is no really fast dma bus which can handle gbit network or fast ssd's
[15:16:26] <cehteh> cpu alone doesnt make a server
[15:16:35] <TitanMKD> yes but for Cortex A15 it should be able to do that
[15:16:40] <cehteh> also its really hard and expensive to get a lot ram for them
[15:16:52] * cehteh wants it now :)
[15:17:51] <TitanMKD> cehteh look the specification:
http://www.arm.com/products/processors/cortex-a/cortex-a15.php
[15:17:58] <TitanMKD> cehteh it is clearly for server ;)
[15:18:09] <TitanMKD> and fanless
[15:18:34] <cehteh> has that this new 64 bit arm arch?
[15:18:35] <TitanMKD> i doubt Intel has any one server fanless with their old x86 cisc outdated technology ;)
[15:18:41] <cehteh> (would be cool too)
[15:18:46] <TitanMKD> cehteh yes 64bits
[15:18:54] <cehteh> yes there are fanless atom's
[15:19:20] <cehteh> mhm cant rememmber if my server here is fanless (atom)
[15:19:36] <cehteh> its just a tiny office server, nothing spetacular
[15:19:37] <TitanMKD> but atom power consumption is two time more than ARM ;)
[15:20:03] <cehteh> yes
[15:20:16] <cehteh> but in face of 3 HDD's as raid it doesnt matter much :P
[15:20:17] <TitanMKD> anyway it seems intel have done big progress for power consumption but only because they use less than 28nm ;)
[15:20:26] <cehteh> CPU FAN Speed: 0 RPM (min = 600 RPM)
[15:20:26] <cehteh> CHASSIS FAN Speed:1566 RPM (min = 600 RPM)
[15:20:39] <cehteh> .. guess i made it fanless ,, cant really remember
[15:21:02] <cehteh> i build it, made a burn in check last year, we moved and i deployed it on the new office,
[15:21:08] <TitanMKD> with new SSD it could be totally fanless ;)
[15:21:12] <cehteh> # uptime
[15:21:12] <cehteh> 22:10:15 up 225 days, 1:53, 1 user, load average: 0.02, 0.04, 0.05
[15:21:18] <cehteh> .. and its running since then :)
[15:21:55] <cehteh> i cant complain about its stability :)
[15:22:21] <cehteh> actually i hope i remmember the hdd's password :P
[15:22:32] <TitanMKD> hehe
[15:23:00] <TitanMKD> cehteh the funny stuff is now even freescale does ARM MCU ;)
[16:23:35] <sabesto> tlvb: i smacked together a quick php script that worked perfectly
[16:24:28] <asteve> bananas then?
[16:53:35] <Jordan_U> I'm using Atmel Studio 6, and I'm wondering if it's possible to use printf for debugging and have it show up somewhere in the Atmel Studio interface. I've made a simple hello world, but I don't know where I'm supposed to be able to view this output while debugging.
[16:55:27] <OndraSter> through what? jtag?
[16:57:33] <Jordan_U> Yes.
[17:00:42] <Jordan_U> If it matters, I'm using a JTAG ICE3 to connect to an AVR XMEGA A1 XPlained board (using JTAG rather than PDI). I can sucessfully watch variables and step through the program, so I think everything is configured correctly for debugging.
[17:08:28] <Jordan_U> Where does the printf output stream go by default?
[17:09:24] <OndraSter> check avr-libc documentation
[17:09:28] <OndraSter> I hoenstly don't know
[17:09:33] <OndraSter> I always grab some serial to USB adapter
[17:09:41] <OndraSter> and hook it up to some serial port on the (x)mega
[17:09:44] <OndraSter> and send the debug there
[17:09:49] <OndraSter> send the text*
[17:13:55] <specing> Jordan_U: nowhere
[17:13:58] <Jordan_U> "...these streams are not already pre-initialized at application startup"
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html So I guess that answers that.
[17:14:35] <specing> printf is also rather heavy
[17:14:44] <specing> use puts and itoa
[17:14:58] <specing> and print numbers in hex if you can
[17:17:49] <Jordan_U> I don't plan to use printf (or any character streams) in my final product, I just wanted something for simple debugging purposes. If it's not simple to get puts to output to somwhere where I can easily see it while debugging then I'll just not try to print anything as I don't really need it. If it's fairly simple to do though I'd like to know how.
[23:08:16] <Xark> Jordan_U: It is not too difficult, you just need to supply a "putchar" (or getchar) function and wrap it in a FDEV_SETUP_STREAM etc. See the examples here
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html
[23:08:50] <Jordan_U> Xark: Thanks.