#avr | Logs for 2014-12-22

Back
[01:33:07] <inflex> lo folks
[07:47:49] <xpoqp> I'm having problem with serial communication http://ideone.com/ppxcxi - lfuse: ff hfuse: d6 efuse: 05 - connected USB to TTL-232R cable between PC and Arduino Uno R3, terminal is set with stty -F /dev/ttyUSB0 cstopb cs8 9600
[07:48:59] <xpoqp> sample output from xxd: 11111000 11111000 11111100 11111000
[07:49:49] <xpoqp> F_CPU is set to 8000000UL, my fuses should be set to use internal 8MHz clock (not divided).
[07:51:16] <xpoqp> both arduino and PC uses little endianess...
[07:53:27] <xpoqp> I have been browsing the datasheets for a while now, but I am kind of clueless now. Is there anything I have forgotten?
[08:39:28] <ecilop> 2 stop bits ?
[08:40:19] <xpoqp> from atmega328p datasheet, 0, 1 or 2 stop bits are supported in serial frames
[08:40:55] <ecilop> #define BAUD_PRESCALE (((F_CPU/(BAUD*16UL)))-1) //Is that ok?
[08:41:15] <xpoqp> and their example used 2
[08:42:03] <twnqx> 2 stop bits sounds super weird
[08:42:14] <twnqx> i'd go with 0
[08:42:16] <xpoqp> http://www.atmel.com/Images/doc8161.pdf
[08:42:22] <twnqx> so what
[08:42:25] <twnqx> normal serial is 0
[08:42:50] <xpoqp> ok, I don't know what normal is, I am unexperienced with this kind of stuff.
[08:42:58] <twnqx> "8N1"
[08:43:02] <ecilop> Look here first: http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html
[08:43:03] <twnqx> might be one stop stopbit
[08:43:23] <twnqx> but i have never seen 2 stop bits being used
[08:43:31] <twnqx> and i deal with serial ports for over 20 years :P
[08:44:00] <xpoqp> ok
[08:44:13] <ecilop> twnqx: ver-very noisy place :) 2 stopbits :D
[08:44:16] <twnqx> 8N1 (8 data, no partiy, 1 stop bit) is the quasi-standard
[08:53:40] <xpoqp> I actually staretd off looking at that document ecilop but moved on when I didn't get it to work
[08:54:43] <ecilop> You have included <util/setbaud.h>. What for?
[08:54:56] <twnqx> leftover, probably :P
[08:55:18] <xpoqp> probably yes
[08:55:19] <ecilop> copy-paster?
[08:55:21] <twnqx> btw, you shouldn't need the delay()
[08:55:35] <twnqx> no, he just wrote he tried it
[08:55:46] <twnqx> then he removed the code but not the include. does that never happen to you?
[08:55:57] <ecilop> that util works simple
[08:56:15] <ecilop> first define BAUD
[08:56:22] <ecilop> and F_CPU
[08:56:36] <ecilop> after - include that util
[08:56:41] <ecilop> thats all..
[08:57:12] <ecilop> Write this block for get result:
[08:57:15] <ecilop> UBRRH = UBRRH_VALUE;
[08:57:18] <ecilop> UBRRL = UBRRL_VALUE;
[08:57:21] <ecilop> #if USE_2X
[08:57:24] <ecilop> UCSRA |= (1 << U2X);
[08:57:27] <ecilop> #else
[08:57:30] <ecilop> UCSRA &= ~(1 << U2X);
[08:57:33] <ecilop> #endif
[08:57:45] <twnqx> bah
[08:57:52] <twnqx> that can't even change the baudrate at runtime
[08:58:01] <ecilop> yep
[08:59:11] <ecilop> You need change baud in program -> reading datasheets is the best
[08:59:33] <twnqx> that's always best
[08:59:38] <twnqx> and your code won't work for him
[08:59:39] <twnqx> :>
[08:59:46] <ecilop> why not?
[08:59:53] <twnqx> since it's UBRR0H and not UBRRH
[08:59:59] <twnqx> two USARTs.
[09:00:06] <ecilop> :D
[09:00:31] <ecilop> sleep_brain_mode();
[09:01:28] <xpoqp> I don't need to change it runtime for now
[13:18:09] <vicatcu> hey all, can someone check me on a timer configuration problem?
[15:01:12] <LeoNerd> Pogo pin adapter for ICSP header. Useful? Should I consider one?
[15:01:27] <LeoNerd> I'm thinking it might be useful to avoid having to put a full 2x3 header on the board; just expose bare pads
[15:18:19] <bitd> So, avr people. C++ or C for 8 bit mcu's?
[15:18:31] <LeoNerd> I write in straight C
[15:19:13] <bitd> Same here. I just picked up learning more about C++.
[15:19:15] <specing> bitd: try Ada
[15:20:57] <LeoNerd> I don't see much point in C++ on the size and scale of program as you can fit in 8Ki of flash and .5Ki of RAM
[15:21:17] <bitd> And in professional use?
[15:21:37] <bitd> I am guessing in the embedded design world, there are still plenty of products made with 8 bit micro's.
[15:21:55] <specing> C and C++ are really bad languages
[15:22:13] <bitd> Yeah, but most jobs require you to know them :)
[15:22:19] <specing> they give you a bazooka to shot yourself in the foot with
[15:23:11] <specing> they have unfortunatelly reached critical mass
[15:29:04] <bitd> Yeah, brushed up on the C++ concepts. For now I will use my time for embedded C design patterns.
[15:29:47] <bitd> Probably a better time investment than C++ experience.
[15:31:53] <Tom_itx> bitd no c no c++... asm all the way!
[15:35:20] <LeoNerd> RikusW: Ah, hi :) LTNS
[15:35:36] <RikusW> Hi LeoNerd
[15:36:13] <RikusW> been busy lately and going to bed early for a change.
[15:36:14] <LeoNerd> RikusW: I made a thing. https://www.tindie.com/products/leonerd/avr-hvsp-programming-bus-pirate-adapter/ and also I managed to make a prototype STK500 clone
[15:36:28] <RikusW> nice :)
[15:37:01] <LeoNerd> Gonna probably turn that into a little tiny841 board to sit on top on the 2x5 connector, with a USB socket on the back
[15:39:11] <Jartza> http://arcticstartup.com/2014/12/05/saw-it-at-slush-electronic-badge-tagsu-now-on-indiegogo
[15:39:14] <Jartza> :)
[15:39:14] <RikusW> Add TPI support :-P
[15:39:36] <RikusW> for tiny 10
[15:39:42] <RikusW> and some others
[15:40:06] <RikusW> for example code look in the lufa sources
[15:40:08] <LeoNerd> Mmm.. well, so far I haven't gone in for those. I could try it one day, but currently trying to make it quite focused and specific
[15:40:11] <RikusW> and atmel docs
[15:40:53] <RikusW> it will only be a sw change so it could be added later
[15:41:09] <RikusW> on the BP version anyways
[15:41:16] <LeoNerd> Yah.. I left the 7pin header out for a reason
[15:41:37] <RikusW> TPI is a lot like PDI on the xmega
[15:41:50] <LeoNerd> Well, so far the STK500 clone takes a mere 2.4Ki on the tiny841. I'm hoping to fit some self-contained fuse fiddling code in there too, with buttons + LEDs
[15:42:03] <LeoNerd> Aim at the sortof "fuse doctor" approach, but still full programming over serial as well
[15:42:33] <RikusW> dw and rst fuses might not allways be in the same bit positions
[15:42:49] <LeoNerd> Nope.. but there's not very many HVSP-capable tiny chips anyway
[15:43:03] <LeoNerd> I'm hoping to fit a small database of signatures + fuse layouts in the EEPROM
[15:43:07] <RikusW> you could check the signatures then
[15:43:15] <LeoNerd> I do that anyway on the software
[15:43:41] <RikusW> that data is in the atmel xml files that comes with studio
[15:46:24] <RikusW> LeoNerd: got the im ?
[15:48:53] <RikusW> so very much feasible to do sig checking in fw
[15:49:26] <LeoNerd> Oh, indeedy
[15:49:48] <LeoNerd> Easy when you start from the part info XML files
[15:49:58] <LeoNerd> https://metacpan.org/pod/Device::AVR::Info I wrote that for it ;)
[15:51:17] <RikusW> for studio 4 or 5/6 xml ?
[16:07:36] <LeoNerd> I don't know quite where the XML files come from. I presume one of the Studios
[16:08:24] <LeoNerd> Hard to get hold of them on their own currently... Atmel only bundle them with the 700MB Windows-only exe downloader thingy
[16:09:00] <LeoNerd> But I believe I have sent forward a message in their direction; maybe one day it'll come to something
[16:09:58] <RikusW> so where did you get it ?
[16:10:51] <LeoNerd> A kindly resident here in the channel sent me a zipped copy
[16:10:58] <RikusW> ah
[16:11:11] <RikusW> the devices dir sounds like 5/6
[16:11:14] <LeoNerd> It's a free download so I'm sure it's OK, but best not to name names... ;)
[16:11:31] <RikusW> guess its ok
[16:11:51] <RikusW> PartDescriptionFiles is for AS4 iirc
[16:17:23] <RikusW> I used xsltproc and some sed on the v4 files
[16:17:51] <LeoNerd> I believe the avrdude source uses them somehow too
[16:20:21] <RikusW> at least to generate avrdude.conf
[16:20:39] <LeoNerd> Yah