Back
[01:57:56] <gorroth> finally, i've got reliable comms going between my RPi and AVR chip using UART
[01:58:02] <gorroth> damn that was rough
[01:58:13] <gorroth> i had my baud rate set too high for the CPU frequency of the avr
[01:58:28] <gorroth> so it was like "working" but not really working; it was really unreliable
[01:58:41] <gorroth> and i was a confused dude
[02:16:52] <A124> gorroth What freq You have atm?
[02:17:10] <A124> The max stable is 1M, to my experience.
[02:17:14] <A124> At 16Mhz.
[02:18:39] <gorroth> i have F_CPU, fuse bits, and voltage set such that it should be running at 8 MHz
[02:18:54] <gorroth> i'm using UART though and not USART; so, it won't reach that really high speed you can get with XCK
[02:19:30] <A124> Yeah, I am aware of that, so then half that speed.
[02:19:34] <gorroth> but lowering back down to 9600 on my baud rate resolved everything. even util/setbaud.h was telling me my baud rate was too high for my F_CPU
[02:20:20] <A124> Humm. Well 1M is not problematic, but sometimes it may detect dome bit differently at 16Mhz. 115200 Should have no problem in your case.
[02:20:41] <A124> Unless running on internal oscillator that is really offset from the nominal.
[02:20:45] <gorroth> sorry, what does "1M" mean in this case?
[02:20:51] <A124> 1Mbaud
[02:20:54] <gorroth> ah
[02:21:09] <gorroth> i am running on the internal oscillator; sorry, i didn't explain that
[02:21:29] <A124> So the 115200 is decent alternative of speed, compatibility, consistency and eliability on most systems.
[02:21:53] <gorroth> yeah, but i can't even do 57600 reliably right now
[02:21:57] <A124> Then you might want to do calibration of the oscilator, could help. I never though done communication with RPi only USB to TTL chips.
[02:22:28] <gorroth> oh, you can calibrate it? i wasn't aware of that. i just set the fuse bits and F_CPU and just went from there
[02:22:29] <A124> Also length of wire matters, parallel capacitance, inducatance, etc.
[02:22:36] <gorroth> hmm
[02:22:57] <A124> Yeah, you have to have some kind of code to do the calibration and some reference to calibrate to.
[02:23:19] <gorroth> i do have an STK500 laying around that i could use
[02:23:28] <A124> For example Digispark, and today also Adafruit Trinket, etc... do use that to be able to do USB reliably on internal.
[02:24:25] <A124> That code runs on the micro, compares outside and inner frequency and selects by trial and error or binary search the OSCCAL value.
[02:24:34] <gorroth> ah
[02:24:42] <gorroth> so i just upload the code, and the mcu does its thing?
[02:25:03] <gorroth> http://www.atmel.com/Images/doc2555.pdf
[02:25:05] <gorroth> that's what i'm reading now
[02:25:12] <A124> The value should be preset by factory, depending on the part no. But still that is +-2%. While IRL you can get +-1 or even +-0.5%
[02:25:35] <A124> Well as I said.. you need external reference to calibrate against.
[02:25:53] <gorroth> okay. like something sending exact clock signals into one of the pins?
[02:26:04] <A124> But if you have the correct code adn the reference then you just upload the code and it does it.
[02:26:11] <gorroth> yeah
[02:26:15] <A124> Something like that, yes.
[02:26:37] <gorroth> right now, the avr is just hooked into the RPi, which cannot pulse in realtime (the actual meaning of realtime)
[02:26:44] <gorroth> i'll have to get something for it sometime
[02:26:51] <gorroth> s/it/the avr/
[02:26:55] <gorroth> for now, i'll just lower my baud rate
[02:27:19] <A124> In case of attiny or such, not having crystal for consumer products used most likely aroun 25C operating temperature, that saves some parts, PCB space and other costs. Also two pins, so thats where this is used the most.
[02:27:48] <A124> Well, the simplest dumb thing would be another AVR with crystal xD
[02:27:59] <gorroth> oh
[02:28:02] <gorroth> i do have one of those
[02:28:12] <gorroth> i have a few arduinos with 16 mhz crystals
[02:28:25] <A124> Then you use assembler or timer to output exact frequency.
[02:28:34] <gorroth> okay
[02:28:36] <A124> Usually I think they use 100kHz (not sure)
[02:28:45] <gorroth> okay
[02:28:49] <A124> Another thing is oscope with generator. :)
[02:28:54] <gorroth> that doc will outline the procedure then?
[02:28:57] <gorroth> oh, i have no oscope
[02:29:11] <gorroth> (i'm pretty new and amateur to electronic design)
[02:29:32] <A124> About the AVR mkisp. They may have the reference clock integrated.
[02:29:51] <A124> As its after all proffesional tool. So that might be as simple as uploading a sketch and connecting what needed.
[02:30:25] <gorroth> yeah. i just have the stk500 and the dragon in terms of legit programmers
[02:30:36] <gorroth> for this particular avr, however, i've been using the rpi to program it directly
[02:30:44] <A124> Well, I have none either, but its one of the things that help a lot. I have one in development (testing phase currently) for me by someone. PC based GUI.
[02:31:01] <gorroth> sweet
[02:31:03] * Xark doesn't have any AVR programmer with clock source AFAIK (including official Atmel ones...)
[02:31:06] <A124> There are also relatively cheap DSOs. For me its both about the price and the size.
[02:31:15] <gorroth> yeah
[02:31:22] <gorroth> for this, 38400 baud will be enough for now
[02:31:24] <A124> Good regular digital oscope does cost 350+USD
[02:31:51] <gorroth> yes
[02:31:52] <A124> While cheapo DSOs on ebay start on 25.
[02:31:58] <gorroth> and i'm not going to spend anything like that right now
[02:32:20] * Xark has seen simple AVR R/C calibrate code that uses UART bit-rate as reference...
[02:32:25] <A124> Cost of mine PC GUI one would be around 75-100USD
[02:32:35] <A124> But size minimal.
[02:33:31] <A124> Good point, Xark, I think I seen that too. Not needing additional stuff just smart code and PC app is not bad.
[02:36:25] * Xark links code http://www.atmel.com/Images/AVR054.zip and PDF white paper http://www.atmel.com/images/doc2563.pdf for UART calibration of RC osc
[02:38:37] <A124> Xark, that zip does not download.
[02:38:59] <A124> Opens up general microcontroller product page.
[02:39:10] <Xark> http://www.atmel.com/Images/AVR291.zip
[02:39:16] <Xark> Oops...no
[02:39:22] <Xark> http://www.atmel.com/Images/AVR054.zip
[02:39:35] <Xark> Works for me...
[02:39:44] <gorroth> not for me
[02:39:52] <gorroth> goes back to a default page
[02:40:15] <gorroth> i'm using that pdf, however
[02:40:17] <gorroth> i mean i will be
[02:40:25] <Xark> Go to Atmel and search for "RC+oscillator+calibration" you should see link to AVR054 PDF and below that, like "Download Software" (I get a zip file).
[02:40:47] <Xark> link*
[02:41:20] <gorroth> http://www.atmel.com/Images/AVR054.zip
[02:41:35] <gorroth> wow
[02:41:40] <gorroth> even if i click that straight from their website
[02:41:41] <Xark> You have javascript disabled or something>
[02:41:42] <Xark> ?
[02:41:45] <gorroth> it takes me to a "default" page
[02:41:46] <gorroth> no
[02:41:53] <Xark> Try a diff browser
[02:41:59] <gorroth> chrome is the browser
[02:42:03] <gorroth> if atmel can't handle it, meh
[02:42:15] <Xark> Hmm, Chrome on Wn7 has no trouble for me
[02:42:19] <Xark> Win7\
[02:42:30] <gorroth> chrome on the leenux here :)
[02:42:33] <A124> Cannot copy paste.. idk why..
[02:42:44] <Xark> Try wget :)
[02:43:34] <A124> Wget works.
[02:43:39] <gorroth> wget fails
[02:43:46] <A124> Also... search for alternative mirrors works too.
[02:43:50] <gorroth> i'm not going to do this right now anyway
[02:44:31] <A124> gorroth search: atmel appnotes paul cs4723 site:cs.mun.ca
[02:45:23] <gorroth> got it :)
[02:45:25] <gorroth> thank you
[02:45:39] <gorroth> http://www.cs.mun.ca/~paul/cs4723/material/atmel/appnotes/AVR054.zip
[02:45:43] <gorroth> in case anyone here wonders
[02:46:05] <gorroth> i do have to sleep now
[02:46:09] <gorroth> i'm shit at getting to bed
[02:46:12] <gorroth> goodnight all
[02:47:52] <A124> Night.
[06:17:32] <Lambda_Aurigae> gorroth, running the USART with the internal RC oscillator is going to be problematic at best....variations in temperature of the chip can cause the frequency of the internal RC oscillator to drift which will throw off USART comms.
[06:18:18] <LeoNerd> Yah - don' use internal RC with UART. You really want an XTAL or some other external clock source
[06:18:21] <Lambda_Aurigae> gorroth, also, have you looked at wormfood's avrbaud calc...it gives you the % deviation and such for various USART speeds at various processor speeds.
[06:19:40] <Lambda_Aurigae> using the internal RC oscillator at usart comms speeds down around 300 to 1200 bits per second is somewhat less problematical but the pulse widths are much wider and all that.
[06:20:09] <Lambda_Aurigae> but running 1Mb/s on the internal oscillator,,,would be surprised if it worked at all actually.
[07:46:04] <Jartza> Lambda_Aurigae:
http://gerblook.org/pcb/zN9Z5cokaMeUTTZLdjNXV6
[07:46:06] <Jartza> :)
[07:46:26] <Jartza> 17x32 mm board... world's smallest vga-controller? :)
[10:02:09] <gorroth> Lambda_Aurigae: well, i don't have an XTAL device; so, i don't use one. i'll look into getting one sometime.
[10:02:52] <gorroth> Lambda_Aurigae: i didn't do USART, just UART. but 57.6k was problematic
[12:48:22] <Lambda_Aurigae> gorroth, usart/uart...same thing....same physical hardware on the chip...it's called a USART on AVR because it can do Sync as well as Async.
[12:48:31] <Lambda_Aurigae> Jartza, not quite smallest but not bad at all.
[12:48:50] <Lambda_Aurigae> Jartza, all single sided?
[12:49:03] <Lambda_Aurigae> hmmm..no..I see vias.
[12:49:19] <Lambda_Aurigae> there we go...backside.
[12:49:34] <Lambda_Aurigae> almost room to put the other two tinys on the back...almost.
[12:50:20] <Lambda_Aurigae> oh..OH...OHHH...stack them then bend out non-similar pins and air wire them where they go!
[12:50:31] <theBear> you mean on late-series avrs :)
[12:51:08] <Lambda_Aurigae> theBear, it wasn't a USART on the at90s series?
[12:51:30] <theBear> nup
[12:51:44] <theBear> which i pretty sure includes the early megas too
[12:51:53] <Lambda_Aurigae> it was on the atmega32
[12:52:01] <theBear> maybe 2 series of em, oh, one then
[12:52:14] <Lambda_Aurigae> that was my first AVR.
[12:52:20] <theBear> mega5345 or something like that was basically mega of 90s series
[12:52:55] <theBear> pretty sure the migrating from 90s2313 to tiny2313 doc details the differences
[12:53:40] <Lambda_Aurigae> wasn't that going to the USI though?
[12:53:50] <Lambda_Aurigae> or does the tiny2313 have a real USART?
[12:54:00] <theBear> pretty sure it does
[12:54:13] <theBear> it was the first middle-sized one of the newer gen
[12:54:31] <theBear> oh wait, wait, what ?
[12:54:44] <Lambda_Aurigae> yup...full duples usart on the attiny2313
[12:54:57] <Lambda_Aurigae> duplex
[12:55:05] <LeoNerd> Always struck me as odd, that
[12:55:24] <LeoNerd> Seems a bit out of place on such a chip, but then the 'tiny2313 has almost nothing *else* onboard
[12:55:37] <theBear> it's got lots of stuff
[12:55:46] <theBear> it's superawesome
[12:55:57] <Lambda_Aurigae> at90s2313 had a full duples UART
[12:56:06] <Lambda_Aurigae> just grabbed datasheets...
[12:56:25] <theBear> yeah, thus what i said about the migration doc mentioning what changed including u(+s) art
[12:56:38] <Lambda_Aurigae> attiny2313 also has a usi for doing twi and spi.
[12:57:14] <Lambda_Aurigae> at90s2313 seems to only have spi serial interface but it's only for ISP.
[12:57:35] <LeoNerd> I thought the tiny2313 also has a USI though?
[12:57:51] <Lambda_Aurigae> it does.
[12:57:56] <Lambda_Aurigae> the at90s2313 doesn't
[12:58:15] <theBear> doesn't it have some a-d ? either way it's got 2 or 3 timers, a decent ram/rom combo
[12:58:22] <theBear> lots of pins, dirt cheap
[12:58:40] <LeoNerd> tiny2313 has no analog
[12:58:49] <theBear> is it just me or are people agreeing over and over but acting like they arguing ?
[12:58:54] <Lambda_Aurigae> no analog on either 2313.
[12:59:02] <LeoNerd> I'm using mine as a little keyboard matrix scanner. Seems handy - lots of digital IO pins, I2C interface; no need for analog
[12:59:03] <Lambda_Aurigae> dunno.
[12:59:10] <Lambda_Aurigae> I'm just reading off the datasheets..hehe
[13:01:53] <theBear> i still use 90s2313's for stuff, got a tube of them waaaaay back
[13:02:00] <theBear> like, when they were newish
[13:02:19] <theBear> and noone uses sync serial this century
[13:02:31] <theBear> and noone needs it when they got a oversampley fancy hw uart
[13:02:45] <LeoNerd> If anyone wanted synchronous serial communications they'd be using I²C or SPI
[13:03:51] <theBear> that's the spirit, and with that i will leave you
[13:04:51] <Lambda_Aurigae> hehe.
[13:05:00] <Lambda_Aurigae> I still use Synchronous RS232 sometimes.
[13:05:21] <Lambda_Aurigae> or, rather, Synchronous comms on USARTs...
[13:05:32] <Lambda_Aurigae> along with 9bit addressing mode.
[13:19:13] <gorroth> Lambda_Aurigae: yeah, i know. however, since i'm not using the XCK, i thought they just called it UART
[13:19:22] <gorroth> even if it's the same physical hardware underneath
[13:24:16] <gorroth> but i do like that sweet feeling that it's got USART ability
[13:24:30] <gorroth> is USART something the standard linux termios can handle?
[13:24:57] <LeoNerd> I don't think that question makes sense
[13:25:13] <LeoNerd> termios talks to TTY devices. RS-232 ports are often represented as TTY devices. USARTs can usually talk RS-232
[13:25:19] <LeoNerd> so... yes; in a very roundabout way
[13:25:35] <gorroth> does linux's termios support the ability to send clock signals through the tty devices
[13:25:38] <gorroth> that's what i mean
[13:25:47] <LeoNerd> Umm tht's about 5 layers away
[13:25:50] <LeoNerd> termios doesn't care
[13:25:54] <gorroth> oh i see
[13:25:55] <LeoNerd> TTY devices don't care
[13:25:59] <LeoNerd> Hardware drivers might care.
[13:26:11] <gorroth> so how would i setup the device to speak using USART instead of UART?
[13:26:12] <LeoNerd> E.g. I could imagine setserial(8) might have a way to prod the sync clock mode
[13:26:18] <gorroth> ah, thanks
[13:26:33] <LeoNerd> But then you would definitely need a 25pin serial port, because the 9pin RS232 variant lacks a clock pin
[13:26:45] <LeoNerd> In either case, "USART" generally refers to an IO port system that can do async *or* sync
[13:26:51] <LeoNerd> Hence the 'A' there ;)
[13:27:01] <LeoNerd> If it was only synchronous, it would be called a USRT surely
[13:27:01] <Lambda_Aurigae> I do usart between chips rather than between chip and pc.
[13:27:11] <gorroth> ah, based on the 'apt-cache shot setserial', i'm guessing setserial helps you setup new tty devices
[13:27:21] <gorroth> and then when you use them, the device will just do the clocking for you
[13:28:07] <gorroth> Lambda_Aurigae: okay. so between pc and chip, you just stick to uart?
[13:28:11] <Lambda_Aurigae> yup.
[13:28:30] <gorroth> interesting. what if you want to do higher speed comms between the pc and chip?
[13:28:35] <Lambda_Aurigae> I don't do a whole lot of pc to chip through serial these days though.
[13:28:46] <Lambda_Aurigae> when going to pc these days I go usb or ethernet.
[13:29:00] <gorroth> oh, you use the FTDI chip that switches the signals for you?
[13:29:04] <Lambda_Aurigae> nope.
[13:29:20] <Lambda_Aurigae> I use pic32 chips that have USB hardware built in.
[13:29:24] <gorroth> ooooh
[13:29:26] <gorroth> that makes sense
[13:29:30] <gorroth> so you use better hardware then :)
[13:29:33] <Lambda_Aurigae> or use enc28j60 for ethernet.
[13:29:41] <gorroth> and then you use the pic32 to do usart to any avr slaves you want
[13:29:42] <Lambda_Aurigae> you could use avr with built in usb.
[13:29:44] <gorroth> i'm guessing
[13:29:53] <gorroth> yeah
[13:30:17] <Lambda_Aurigae> or, if you are a glutton for punishment you can use vusb but that's low speed usb only and a pain in the arse.
[13:30:41] <gorroth> no, i'll just stick with uart for now
[13:30:46] <gorroth> i was just curious in general
[13:31:10] <Lambda_Aurigae> most of my chip to chip stuff is robot communications these days....little bots that talk over the USARTs to each other optically was the last version.
[13:31:36] <Emil_> Is there some example code for setting up atmega32u4 usb to serial emulator?
[13:31:53] <Lambda_Aurigae> Emil_, I'm sure the LUFA software has an example code...
[13:32:01] <Lambda_Aurigae> it's called USB-CDC most likely.
[13:32:42] <Emil_> Lambda_Aurigae: thanks
[13:32:51] <Lambda_Aurigae> http://www.fourwalledcubicle.com/LUFA.php
[13:33:05] <Emil_> Yeah I know the project
[13:33:07] <Lambda_Aurigae> virtual serial device, host, etc.
[13:33:25] <Emil_> Oh, it was that simple
[13:33:25] <Emil_> :D
[13:33:26] <Emil_> Thanks
[13:33:33] <Lambda_Aurigae> google is your friend.
[13:33:34] <Lambda_Aurigae> welcome.
[13:33:57] <Arch-TK> That's really cool, I just connected this attiny85 and had two LEDs connected through resistors to ground from PB0 and PB1. I forgot to connect the ground pin of the attiny to ground but the thing powered on :P
[13:34:12] <Lambda_Aurigae> Arch-TK, hehe..yeah, things like that happen.
[13:34:15] <LeoNerd> Mmm.. gotta love virtual grounding via clamp diodes :)
[13:34:20] <gorroth> Lambda_Aurigae: yeah, that's what i'm going to be doing with chip-to-chip. although, i'll probably be using xbee's, which i think connect to the USART anyway
[13:34:20] <LeoNerd> Just take care not to cook it
[13:34:47] <Emil_> Arch-TK: you can also supply power through other pins than the vcc by using the internal protection diodes but :D
[13:35:04] <gorroth> Lambda_Aurigae: however, i still need some smarter PC to control my bots, and i'll just use UART for now... at least until i get an xbee, and then it'll be whatever interface they have between the xbee and the pc
[13:35:07] <Arch-TK> I disconnected the power and looked at the circuit and spent a few minutes looking for the hookup wire I used for ground, only to realise I never put it in.
[13:35:11] <Arch-TK> I thought it fell out :P
[13:35:50] <Lambda_Aurigae> gorroth, use a bigger AVR! make them self contained...
[13:36:00] <Lambda_Aurigae> build intelligent bots, not remote controlled devices..
[13:36:04] <Lambda_Aurigae> :}
[13:36:31] <gorroth> no, i want them remote controlled
[13:36:41] <gorroth> especially since a human will be using their joystick to control the bot
[13:37:02] <Lambda_Aurigae> I don't consider those bots...those are RC waldos.
[13:37:05] <gorroth> if was a purely automated bot, i would upgrade to ARMs or maybe even bigger
[13:37:11] <gorroth> they're bots :)
[13:52:20] <Lambda_Aurigae> http://spectrum.ieee.org/semiconductors/materials/how-a-microscopic-supercapacitor-will-supercharge-mobile-electronics
[14:13:56] <gorroth> that sounds good
[14:14:04] <gorroth> i'm hoping for some graphene CPUs soon enough
[14:25:30] <Jartza> Minähän en ole saanut lomarahaa vuosikausiin. Eilen vielä oltiin säätämässä lomarahaa kaikille lakisääteideksi jotta sitä voidaan leikata niiltä jotka sitä on aina saaneet. Eli sen mukaan liksani nousisi jotta toisilta voidaan leikata. Tänäänkö tuo nyt ollaankin perumassa, kun ehdin jo tilailla kaikkea kivaa lomarahalla?
[14:25:48] <Jartza> oops
[14:26:47] <Jartza> evening ;)
[14:28:10] <inkjetunito> .nikennis atoothE
[14:30:43] <Jartza> :)
[14:30:54] <Jartza> paste error, yeah
[15:43:08] <Steffanx> You need more ä's Jartza ( or Järtzä )
[18:49:39] <FrankD> anyone here familiar with the ATTiny1634? Trying to figure out which pins to route to MISO/MOSI on the ICSP
[18:50:25] <FrankD> theyre only labelled DI/SDA/RXD1 and DO/TXD1
[18:50:28] <Lambda_Aurigae> can look in the datasheet and see.
[18:51:42] <FrankD> i wanted to be sure my interpretation was correct
[18:52:22] <Lambda_Aurigae> page 224, table 23-7
[18:52:29] <Lambda_Aurigae> of the datasheet.
[18:52:34] <Lambda_Aurigae> mosi pb1
[18:52:36] <Lambda_Aurigae> miso pb2
[18:52:40] <Lambda_Aurigae> sck pc1
[18:53:06] <FrankD> i see that
[18:53:25] <FrankD> but the device is a slave during programming right? so MOSI is really the MISO pin?
[18:53:38] <FrankD> in normal operation?
[18:53:50] <Lambda_Aurigae> master out serial in
[18:53:53] <Lambda_Aurigae> err
[18:53:56] <Lambda_Aurigae> master out slave in
[18:54:00] <Lambda_Aurigae> master in slave out
[18:54:03] <FrankD> again, aware
[18:54:34] <FrankD> i wasnt looking for a what miso and mosi were
[18:55:08] <FrankD> PB1 would be MISO if it was operating as a master to an SPI device, right?
[18:55:27] <FrankD> but its connected to the MOSI ICSP header pin?
[18:56:25] <Emil_> FrankD: wat
[18:56:50] <Lambda_Aurigae> master out slave in....output from the programmer to the input of the chip.
[18:57:45] <Lambda_Aurigae> it's labeled the same at both ends.
[18:58:00] <Lambda_Aurigae> mosi is output at the master and input at the slave....