Back
[06:11:49] <_abc_> I have an atmega328p datecode 1426 whose USART refuses to work with parity on, either even or odd. Has anyone seen such a problem recently? Datecode suggests week 26 year 2014. I tested this exhaustively, there is a very low probability that my usart usb adapter on the pc side does this, but there is no mention of a problem on that side, and my scope says it's a atmega. Also the usart adapter is known to work well.
[06:12:38] <_abc_> Also, the problem is on the receive side only, pc->atmega. atmega sends E or O or N parity usart data as programmed to the pc, there is no question about it.
[06:13:31] <_abc_> I.e. atmega usart receiver in atmega is suspect of wrong parity generation. Some characters pass okay, others do not. Example with parity programmed Even in the atmega, it receives 'g' okay but not 'G'.
[06:25:56] <LeoNerd> aandrew: AVR061
[06:31:00] <_abc_> So, no takers? Bad parity gen inside 328P usart receiver? No takers?
[06:39:39] <_abc_> ...
[07:13:14] <vsync> don't use parity \o/
[07:13:43] <LeoNerd> Yah.. I tend to run with no parity, and put a higher-level stronger integrity check on
[07:13:58] <LeoNerd> E.g. STK500 uses little packets which contain an 8-bit checksum
[07:14:34] <vsync> datecode 1426, do you also have a tektronix or agilent 15GHz scope you are going to tear down, and just mention it's $200k price?
[07:15:18] <twnqx> those designs are a marvel in my eyes :X
[07:15:30] <twnqx> just looking at those PCB designed filter etc
[07:15:47] <vsync> beauty
[07:16:10] <twnqx> and here i am, scared that usb 2.0 might not work
[07:16:26] <twnqx> (it did. on first try.)
[07:19:29] <vsync> you also need a myriad of multimeters
[07:19:46] <twnqx> i have two
[07:19:50] <twnqx> never needed more
[07:21:34] <vsync> do you have all the flukes?
[07:21:49] <vsync> if you don't you better get more. Do you have disturbingly high-pitched voice?
[07:22:21] <vsync> Are you excited whenever you see a "classic 74HC?"
[07:34:13] <twnqx> i'm also not australian
[07:35:01] <vsync> maybe austrian, then
[08:10:34] <LeoNerd> vsync: What's a "classic"?
[08:13:31] <vsync> you should ask him
[08:13:47] <vsync> send him a few 74hc series chips and ask him which one's the classic and what's so classic about it
[08:14:07] <LeoNerd> Hrmmm
[08:39:03] <jaggzt> Here's the output of avrdude, if it helps anyone help me..
http://www.pasteall.org/56684
[08:39:33] <jaggzt> can't get my leonardo micro boards to "respond" (although their LEDs respond)
[08:39:42] * jaggzt sighs..
[08:39:56] <LeoNerd> Not much to go on there
[08:40:09] <LeoNerd> "programmer is not responding" just means "yeah, so I tried talking to it but I didn't see it talk back"
[08:40:16] <LeoNerd> Could be anything. What is it? how's it connected?
[08:40:21] <LeoNerd> Can you attach logic probes to it to see if it talks?
[08:41:18] <jaggzt> I decided to install arduino's files and use their config in case it helped.. didn't seem to affect anything: avrdude -v -v -C/usr/share/arduino/hardware/tools/avrdude.conf -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -V -Uflash:w:"$heximg":i
[08:41:41] <jaggzt> hmm.. logic probes.. I have an oscope and some multimeters
[08:42:10] <jaggzt> it's connected with usb.. got the micro thinking it would be convenient ..
[08:42:16] <vsync> you need to high voltage flash it
[08:42:23] <vsync> what you need is a triac
[08:42:58] <jaggzt> ?
[08:43:05] <vsync> you pulse mains 110v to 240v ac pref 50hz
[08:43:08] <vsync> to the board
[08:43:17] <vsync> while you program it and use yourself as a conductor
[08:43:59] <jaggzt> okay.. I have some alligator clips on a normal ac cord.. which pins do I hook it up to?
[08:44:21] <vsync> to your nipples preferably
[08:44:39] <jaggzt> okay.. I put it on a dimmer, I hope that's ok
[08:44:49] <vsync> :-(
[08:45:08] <jaggzt> seriously.. I'm completely new to mcu's and trying to get a project done for someone with a disability..
[08:46:03] <jaggzt> the 32u4's were ideal, but I didn't think I'd fare well trying to solder their tiny pins and didn't see other packages available.. so the leonardo's seemed convenient (minimal extras on the board, basically just giving me pinouts and usb support)
[08:46:31] <jaggzt> supposedly you need to switch them to 1200 baud to get the "bootloader to kick in"
[08:47:20] <jaggzt> LeoNerd, what pin(s) would you test with the probes by the way?
[08:47:22] <vsync> forget avr, get pic, solved
[08:47:31] <jaggzt> maybe I should invest in a logic probe
[08:47:36] <LeoNerd> Oh.. USB. That's a little harder to test
[08:47:48] <vsync> pics with usb (probably 10x less painless implementation than avr) come in DIP too
[08:49:49] <jaggzt> I was aiming for the teeny size because it'll go in a set of mouse buttons
[08:50:07] <jaggzt> it's custom made since she's been having problems using the computer
[08:50:36] <jaggzt> a dip would probably fit fine though..
[08:50:48] <Casper> jaggzt: which programmer?
[08:51:26] <LeoNerd> There's a wonderful variant of the PL2303 which is a SOIC8 package, that does Vbus/D+/D-/GND on one side (i.e. direct wire onto the USB port), and Vout at 3.3V, Tx, Rx on the other (i.e. perfect for UART)
[08:51:43] <Casper> if it's tom's one, then it's he wrong type, and if it's a bootloader then chance it's wrong too
[08:51:46] <LeoNerd> Very useful for putting USB serial ports onto USBless AVRs with a UART.. i.e. almost all of them
[08:51:55] <Casper> and 57600 look weird
[08:52:08] * Casper is gone
[08:52:14] <jaggzt> casper, I got tom's programmer, but these are on a board with usb already
[08:52:31] <Casper> oh and usb-serial do not work with bit bang programmer
[08:52:34] <LeoNerd> Oh.. just because it has USB doesn't mean it has the Arduino-style bootloader burned into the chip
[08:52:43] <LeoNerd> A plain 32U4 doesn't have that
[08:52:46] <jaggzt> ahh
[08:53:10] <jaggzt> ok.. but this IS the way people program the leonardo's.. maybe i got the wrong boards .. ebay
[08:53:11] <LeoNerd> A straight-from-Atmel's-factory AVR chip will only respond to ISP or HV{S,P}P; nothing else.
[08:53:26] <LeoNerd> If you want a bootloader in that's accessible via USB-CDC, say, you'll have to burn that in first
[08:53:26] <jaggzt> maybe someone sent me a "sparkfun" board
[09:00:52] <jaggzt> http://www.ebay.com/itm/141548309003
[09:55:52] <aandrew> LeoNerd: wow that's too easy
[09:56:21] <LeoNerd> aandrew: Yah. It's not terribly hard
[09:56:35] <LeoNerd> My minimal implementation uses a little over 2Ki of the 8Ki flash on a tiny841
[11:58:58] <vsync> finally getting drunk enough to start playing with the atmel arm again
[11:59:16] <vsync> the whole ASF seems like a load of bullshit
[11:59:19] <vsync> to be honest
[12:07:35] <benbergman> in case anyone was interested in the problem I posted last night, the issue was that I managed to corrupt my EEPROM
[12:07:45] <vsync> good for you
[12:07:53] <benbergman> I read the EEPROM out of my good board and flashed it to the bad one, now all is working again :D
[12:08:30] <vsync> are you related to ingmar bergman
[12:08:53] <benbergman> I have a lot of cousins, but not that I'm aware of
[12:09:04] <vsync> he was a pretty famous dude, i must say
[12:24:07] <Kieran> So, I'm trying to program an ATtiny2313A through HVPP on an STK500, but it doesn't read the correct signature. I'm fairly certain the cables/jumpers/etc. are connected correctly.
[12:24:19] <Kieran> It gets some of the signature bytes right some of the time
[12:39:12] <N1njan33r> Try reducing the inteface speed.
[12:40:48] <Kieran> it says "This interface has no settings"
[12:40:54] <Kieran> Assuming that's what you were referring to
[12:52:53] <tpw_rules> what is the inverse of objdump? i'm assembling with avra but i want to make an elf to load into simavr
[12:58:01] <N1njan33r> No idea. I have never used HVPP. Why are you not just using the ISP interface?
[12:58:16] <N1njan33r> HVPP is generally for last-ditch recovery.
[12:59:14] <tpw_rules> blah, avr-as doesn't support long local labels
[13:09:01] <Kieran> N1njan33r, because I dun goofed
[13:09:19] <Kieran> I have no reason to believe the chip is fried, though, since it still runs its last program fine
[13:11:37] <N1njan33r> Mmm
[13:13:53] <Kieran> Hm
[13:14:31] <Kieran> I fixed it by using avrdude and ignoring the signature while writing a new high fuse byte
[13:14:51] <Kieran> it still reads wrong with HVPP, but at least ISP works now
[13:16:38] <Kieran> N1njaneer, I got it fixed.
[13:17:10] <N1njaneer> Great!
[13:17:41] <Kieran> I used avrdude to ignore the signature and flash a new high fuse byte
[13:17:57] <Kieran> it still read it back wrong through HVPP, but ISP works now
[13:21:01] <Kieran> Though while this is all fine and dandy, it doesn't solve the problem I was having before I started messing with the fuse bits
[13:21:40] <Kieran> Namely that I can't seem to be able to output anything on PA0 and PA1
[13:22:02] <Kieran> It's set to use the internal oscillator at 8 MHz
[13:30:15] <N1njaneer> What part?
[13:30:59] <N1njaneer> Oh, 2313 right?
[13:31:53] <Kieran> Yes
[13:31:55] <N1njaneer> If it's on internal oscillator PA0/PA1 should be avaliable for GPIO
[13:32:01] <Kieran> Well, 2313A, if it makes a difference
[13:32:06] <Kieran> Yes, they should
[13:32:18] <Kieran> But they don't seem to be
[13:32:29] <N1njaneer> You have set their DDRA to 1's?
[13:32:37] <Kieran> Yes
[13:33:02] <Kieran> I wanted to test PA2 also, which lead to the whole HVPP fiasco
[13:33:10] <Kieran> I did get to test it, but it didn't work
[13:35:40] <N1njaneer> And you've minimized the code testing down to literally JUST a main function that sets DDRA = 0x03; and then PORTA = something and you are not seeing anything coming out of PA0/PA1?
[13:35:45] <N1njaneer> Are they stuck high or low?
[13:36:25] <Kieran> High, it seems
[13:36:37] <Kieran> I believe the test LEDs on the STK500 are active low
[13:38:05] <Kieran> http://pastebin.com/CbXWCEp1
[13:38:12] <Kieran> it literally can't get any simpler than this
[13:38:15] <N1njaneer> I would suggest disconnecting everything external and probing the chip pin directly to ensure you don't have any external interference.
[13:38:16] <Kieran> Port B works fine
[13:38:22] <Kieran> port A is silent
[13:38:48] <N1njaneer> Seems reasonable, yes :)
[13:43:44] <Kieran> hmmmm
[13:43:54] <Kieran> maybe my stk500 is weird
[13:44:20] <Kieran> the port A pins don
[13:44:27] <Kieran> don't seem to be connected to the headers
[13:46:23] <N1njaneer> May not be since they're often used for clocks, and you don't want those traces going off longer than they absolutely need to be.
[13:46:49] <vsync> rofl
[13:46:50] <Kieran> well
[13:47:01] <Kieran> they seem available on the XT1 and XT2 headers
[13:47:05] <Kieran> so i'll just use those
[13:47:08] <vsync> even this xplained board that i have, running an arm at 32MHz has the clock somewhat far away
[13:47:12] <vsync> clock, crystal i mean
[13:47:24] <vsync> though i assume it's the 32kHz crystal
[13:47:27] <vsync> in either cas e--
[13:47:59] <Kieran> Well, thanks :P
[13:48:36] <N1njaneer> vsync: The 32Khz clock is going to be less of a problem than, say, a 16Mhz TTL :)
[13:48:48] <vsync> i know
[13:48:53] <N1njaneer> Kieran: Hope that helps!
[14:09:09] <tpw_rules> is there a way to use avr-as wihtout getting crtc?
[14:10:13] <tpw_rules> i want to use it exactly like avra, but with the ability to output an elf with debug symbols
[14:39:01] <_abc__> I ran into an atmega328p whose usart rx has consistent parity errors when set for even or odd parity. Datecode 1426. Anyone knows something? The tx works ok.
[14:44:25] <tpw_rules> so if you loop them you still get parity errors?
[14:45:22] <vsync> _abc__: wasn't this answered already
[14:46:17] <vsync> can you replicate this error with similar datecode (1426) chips using 15GHz agilent oscilloscopes, with the aid of 74HC-family series logic chips while maintaining a high-pitched voice, like those 12 year-old choir boys?
[14:46:56] <vsync> and even then, can you determine the result being beauty or bobby dazzler?
[14:47:30] <tpw_rules> i seem to be missing a reference
[14:47:49] * Tom_itx want's to be bobby dazzler
[14:48:23] <vsync> oh you inbred rednecks. you don't throw a ' into "wants"
[14:48:57] <vsync> tpw_rules: it's okay
[14:49:04] <Tom_itx> i am neither of those
[14:49:19] <vsync> that's another one for the books, it's actually a redundancy
[14:49:25] <vsync> a redneck couldn't tell the difference
[14:49:36] <tpw_rules> i thought you had to say it bobby dazzlah
[14:49:39] <_abc__> Are you high or low? I may have missed the answer. I tested with 2 usb to serial adapters, different chipsets, and scope. Tx is fine with selected pe or po or np, rx works only with np. With pe or po only some chars pass without a PE error, depending on bit count.
[14:49:41] <Tom_itx> you seem to have a chip on your shoulder
[14:50:20] <vsync> bobby shizzle
[14:51:03] <vsync> the datecode is highly relevant
[14:51:14] <vsync> you should ask dave for his input on the matter
[14:51:24] <tpw_rules> i know dave, did i miss an episode?
[14:51:34] <_abc__> I am allergic to eedave. Won't
[14:51:54] <vsync> he has an episode concerning this i believe
[14:51:59] <vsync> with avrs, similar datecode
[14:52:25] <_abc__> Hm. I'll wait for the sillycon errata
[14:52:30] <tpw_rules> oh really? huh. which one?
[14:52:55] <vsync> in the same episode he also tells you how you need a $100k agilent for debugging this
[14:53:23] <vsync> and a couple of few $k fluke multimeters
[14:53:24] <tpw_rules> google isn't helping me.
[14:54:12] <vsync> hm?
[14:54:14] <vsync> it's right there
[14:54:28] <vsync> electronic-fucking-around-blog episde 666
[14:54:58] <vsync> or agilent-fluke-rigol-plug-blog episode 667
[14:55:49] <vsync> the i-used-to-do-meaningful-work-but-now-i'm-degraded-to-wanking-with-scopes-blog
[14:56:00] * tpw_rules rolls eyes and returns to his work
[14:56:15] <vsync> work. software?
[14:56:22] <vsync> $5 bucks on it
[14:56:39] <tpw_rules> have you heard of mikeselectricstuff?
[14:56:52] <tpw_rules> well work as in current project. it's 40% hardware
[14:57:02] <tpw_rules> but right now is the software portion, mr. sarcastic
[14:57:12] <vsync> sarcasm hit home then
[14:57:24] <vsync> tpw_rules: yeah. he's borderline alright I guess
[14:57:36] <vsync> he mostly tinkers around with LEDs, i'm not sure of his occupation really
[14:57:41] <vsync> or opto stuff in any case
[14:57:44] <tpw_rules> he's freelance
[14:57:49] <tpw_rules> he's done a lot of stuff for various uk people
[14:57:52] <vsync> sure, but mostly opto
[14:57:59] <tpw_rules> right now he somehow got ahold of a medical blood analyzer and he's going through it
[14:58:17] <vsync> sure
[14:58:35] <vsync> the inspections don't really interest me. unless they have actual circuit diagrams
[14:58:51] <tpw_rules> the interesting part is all the fluidics
[14:59:39] <vsync> his bullet time camera setup is actually something you could do
[15:00:05] <vsync> i get it was just a back of the envelope type of thing, i still think he had a bit of a bad approach
[15:00:37] <vsync> think you could do a lot more buffering than he suggests
[15:01:05] <vsync> it would cost more though, but no-one expects to build a 100 cam bullet time setup with peanuts
[17:15:33] <jaggzt> great. arduino compiles and uploads to my leonardo micro fine, but avrdude when run by hand, with the same options, fails
[17:15:48] <Tom_itx> odd
[17:15:48] <jaggzt> (using avr code instead of arduino libs)
[17:16:00] <jaggzt> Tom_itx, it's not related to your programmer, by the way
[17:16:54] <jaggzt> the micro is on a breakout board already, and is programmed via usb to the board. they set the baud to 1200 to reset it, then call avrdude
[17:17:29] <jaggzt> but no methods of setting 1200 baud, nor sleep() delays I can find that get it to work
[17:19:06] <jaggzt> Forcing reset using 1200bps open/close on port /dev/ttyACM0
[17:19:41] <jaggzt> but strace -f didn't show anything coming from that call.. I guess I could try ltrace
[17:22:03] <jaggzt> there we go.. wasn't getting all the output (did 2>&1 > foo instead of &>foo or >foo 2>&1)
[17:34:21] <jaggzt> re LeoNerd
[17:34:31] <LeoNerd> Mmm.. tasty tasty RAM
[17:35:14] <jaggzt> anyone know how to prevent strace -f from splitting its calls (I guess it displays a line for the initial call, then one when it returns). This interleaves calls when it's -f (following)
[17:35:29] <jaggzt> pid 16730] ioctl(38, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS <unfinished ...>
[17:35:29] <jaggzt> [pid 16725] recvmsg(18, <unfinished ...>
[17:35:29] <jaggzt> [pid 16730] <... ioctl resumed> , 0x7f1cbb8da2a0) = -1 EIO (Input/output error)
[17:35:29] <jaggzt> [pid 16725] <... recvmsg resumed> 0x7f1cbbde9b40, 0) = -1 EAGAIN (Resource temporarily unavailable)
[17:35:47] <jaggzt> for example, that. I hope that's not too long of a paste for channel wishes.
[17:36:35] <jaggzt> actually that's just two pid's, neither of those calls would call the other as far as I know
[17:36:49] <jaggzt> plus it's interleaved wrong for that to make sense anyway
[18:23:08] <jaggzt> arduino's ide never fails in its avrdude call
[19:02:53] <balrog-k1n> has someone played much with the onchip temperature sensor (or perhaps NTCs in general) and know whether, in practice, averaging over enough measurements will give me a pretty accurate result, or are there error components that persist over some time and no matter how many measurements I take in that period there'll be some significat random factor?
[19:30:59] <tpw_rules> that depends on the factory calibration. there will be some jitter that you can average out, but the long-term drift will depend on the sensor yo uchoose
[19:36:09] <Casper> balrog-k1n: on chip sensor mesure the chip, which warm up with use
[19:36:16] <Casper> and voltage, and what you are doing
[19:36:30] <Casper> so it's good only for a rought estimation of the temperature
[19:36:52] <Casper> NTC require a resistor to make a divider, which may not be too precise
[19:36:58] <Casper> the Aref may also be off
[19:37:11] <Casper> and your NTC beta could vary, specially from brand to brand
[19:37:29] <Casper> the beta define the "resistance vs temperature" curve
[19:37:55] <Casper> only a few ADC samples would be enought to basically eliminate the noise
[19:38:09] <Casper> but then... how do you convert the ADC value to temperature?
[19:38:35] <Casper> the curve is non-linear, you could use "heavy" math, or use a lookup table, or aproximate it over a temperature range
[19:42:05] <malinus> there is some alghorithm, that is in between
[19:42:11] <malinus> iirc
[19:42:22] <malinus> but requires some pretty heavy math, yeah
[19:43:48] <balrog-k1n> Casper: I don't care for absolute precision that much here, but I wonder how far it makes sense to average if I want to see temperature differences on the order 0.1C in the graph, and differences between days or weeks
[19:44:44] <balrog-k1n> so factors like Aref and the divider don't matter much unless they also change properties with time
[19:49:36] <balrog-k1n> and I'm using the onchip NTC, just thought that other than the chip's temperature variation with use, people's experiences with an external NTC should be similar
[20:48:56] <jaggz> Casper: I can use the arduino ide to program my leonardo micro fine, but avrdude directly, with this 1200baud reset thing, doesn't work..
[20:49:27] <jaggz> can't find a way to use it directly.. so I can't, yet, just use avr libs and am restricted to arduino stuff
[21:13:04] * inflex ponders making a horribly crude thermal camera by creating a 8x8 matrix of SMD thermistors
[21:13:32] <inflex> just is annoying that I cannot get my hands on a decent sensor/gridEye because of US export restrictions :(
[21:50:35] <jerware> is wavelength and period synonymous?
[21:57:40] <Casper> jaggz: latest avrdude?
[22:23:13] <jaggzt> Casper, yeah.. but people are calling a python script before avrdude that sets the port to 1200 baud
[22:24:00] <jaggzt> https://github.com/sudar/Arduino-Makefile/blob/master/bin/ard-reset-arduino
[22:24:10] <jaggzt> so they call that followed by avrdude
[22:24:38] <jaggzt> inflex, I've wanted one of those.. to look for temp leaks in my house
[22:25:02] <tpw_rules> what could inhibit the int0 from firing? the bit in GIMSK, the correct mode, pin being an input, and anything else?
[22:26:17] <tpw_rules> I bit in sreg
[22:26:54] <Casper> jaggzt: I personally don't use arduino, I write the code directly with tom's programmer
[22:27:39] <tpw_rules> because my interrupt isn't executing all the time and i cannot figure out why
[22:27:47] <jaggzt> what triggers it?
[22:27:58] <jaggzt> Casper, yeah.. thought this would be convenient...
[22:28:03] <jaggzt> oops
[22:28:10] <tpw_rules> rising edge on an external pin. right now i'm debugging with simavr because the hardware doesn't work
[22:29:45] <Casper> jaggzt: maybe flash a better bootloader? one that do not require wizzardy?
[22:30:09] <Casper> they probably do that to "fix" the issue where the bootloader only run at powerup/reset time
[22:30:28] <jaggzt> there's no reset button.. how else would you trigger reset over usb?
[22:30:29] <Casper> so made a kind of low pass filter on the serial in, that cause a reset
[22:30:55] <Casper> that's why they did that...
[22:31:09] <Casper> might want to add the reset button and put a real bootloader?
[22:31:15] <Casper> or use the ISP port?
[22:33:11] <jaggzt> https://www.foxytronics.com/products/images/257/leonardo-pro-micro-856.jpg
[22:33:26] <jaggzt> or figure out this timing thing..
[22:33:33] <jaggzt> this baud rate and timing thing maybe
[22:34:39] <jaggzt> haven't yet messed with bootloaders nor isp ports ..
[22:34:49] <jaggzt> think the low pass is how they sense the 1200 baud? that's interesting
[22:34:53] <jaggzt> I was wondering what they did
[22:35:25] <Casper> hmmm
[22:35:29] <Casper> not sure actually
[22:35:50] <Casper> I had forgotten that it was usb...
[22:36:28] <Casper> forget the lowpass
[22:38:13] <jaggzt> Casper, sometimes there are differences..
[22:38:19] <jaggzt> here's when they first connect:
http://www.pasteall.org/56695
[22:38:30] <jaggzt> (opening /dev/ttyACM0)
[22:41:11] * Casper wonders
[22:41:28] <Casper> if the avr actually have 2 usb device thingy
[22:41:41] <jaggzt> http://www.pasteall.org/56696
[22:41:51] <jaggzt> that has the 1200 baud switching too
[22:41:53] <jaggzt> sigh
[22:42:36] <jaggzt> hmm.. two? so maybe the reset disables one, connects the other (which comes in at ttyACM0 also)..
[22:43:38] <Casper> I never used those U parts...
[22:43:45] <Casper> so can'T say...
[22:49:02] <jaggzt> :)
