Back
[04:51:35] <LeoNerd> I don't suppose I could interest anyone in 10 SOIC8-sized MAX481C chips could I? I bought them cheap on eBay and then changed my circuit design, so I'm not sure I need them.. :/
[04:51:58] <LeoNerd> I usually like to buy components in advance, because they take ages to ship... but this time it bit me
[04:55:11] <_ami_> one q, EXT INTs do wake up MCU from sleep mode POWER SAVE/DOWN modes? i just wonder why only IDLE sleep mode works for me. :/
[04:55:35] <LeoNerd> They're usually capable of waking it up from all modes.. that being mostly the point
[04:55:39] <_ami_> https://github.com/amitesh-singh/amiduino/blob/master/avr/avr_programmming/parkingsensor-powersave/parkingsensor.c --> wake up from IDLE sleep mode only works.
[04:55:45] <_ami_> LeoNerd: yes,
[04:55:49] <_ami_> but it did not work me.
[04:55:51] <LeoNerd> There's usually a table near the beginning of the data sheet for the chip, explaining what events can wake up the CPU from what modes
[04:56:31] <_ami_> LeoNerd: i check the atmega16a DS, it does say that EXT INT can wake up mcu from all sleep modes.
[04:56:51] <_ami_> oh, shit.. my timer gets killed :P
[04:57:02] <_ami_> that is why no buzzer sound!
[04:57:18] <_ami_> umm..
[04:57:47] <_ami_> is it the reason? oh.. no.. mcu should wake up and then play sound
[04:59:31] <_ami_> LeoNerd: In my case, PD2 is INT0 and IR proximity sensor is connected to this port. Since i hv used UA741IC op-amp in my IR module, LOW = 1.5 V and HIGH = 4.15
[05:01:55] <LeoNerd> Hrm.. is 1.5V low enough to count as a low state?
[05:02:10] <LeoNerd> Also beware of minimum slew rates for digital edge-detect signals like that
[05:02:21] <LeoNerd> I've had INT lines fail to recognise transitions simply because they were too slow
[05:02:53] <LeoNerd> If you're wanting to interrupt on the edge transition of an analog signal you might want to use the anacomp instead
[05:03:04] <_ami_> LeoNerd: hmm, but it works in case of IDLE sleep mode and in normal case.
[05:03:33] <LeoNerd> OK?
[05:03:56] <LeoNerd> If (and I'm saying if) the slew rate is outside the range that the datasheet guarantees will work, there's a chance it works anyway but only sometimes...
[05:07:26] <_ami_> LeoNerd: where to check V minimum at digital port's state to be LOW in DS?
[05:07:47] <_ami_> generally LOW if V_port < 1/3 Vcc?
[05:07:50] <LeoNerd> In the Electrical Characteristics
[05:09:21] <LeoNerd> I don't have the mega16A sheet to hand, but the sheet for a 328P says maximum value for "low" logic state (V[IL]) is 0.3Vcc, if Vcc is above 2.4V
[05:09:54] <LeoNerd> So at Vcc of 5V that comes out as 1.5V. So you're on the borderline there.
[05:30:42] <_ami_> LeoNerd: i shall experiment with V and -V supply to IR proximity sensor. it was bad idea to use UA741C op-amp though. :/
[05:31:17] <LeoNerd> It's always a bad idea to use s 741
[05:31:37] <LeoNerd> Anyway, it sounds like you're doing analog stuff, so again Istand by my suggestion of using the anacomp
[06:05:18] <tavish> hi, anyone repair an avr-dragon by replacing the two analog switches?
[06:05:58] <tavish> can I just permanently short them? I can't buy replacements for it, and digikey has moq of 3000
[06:06:08] <tavish> (switch=nlas2066)
[06:17:57] <LeoNerd> Any equiv?
[06:27:27] <tavish> LeoNerd: found out about ADG721
[06:28:35] <tavish> going to order this, but it's gonna take a week :( i had ordered a jtagice mkI last week and it got delivered today, turns out avarice(other things also?) cannot use it with atmega1280
[06:42:34] <LeoNerd> Eh, a week. I often order ebay stuff that takes a month or so to arrive
[06:42:44] <LeoNerd> The price of convenience :)
[06:54:16] <tavish> yeah well, i have to answer to someone for any delays
[09:43:04] <lowin> Is it okay to not connect avcc if I'm not planning to use PortA at all? using atmega8
[09:46:45] <LeoNerd> You probably still want it connected up
[09:47:00] <LeoNerd> Just less need for the LC filter in that case
[16:27:05] <Lambda_Aurigae> lowin, always connect VCC, AVCC, and both GND points next to them. Also always put bypass caps on both the AVCC/GND and VCC/GND pairs.
[16:27:32] <Lambda_Aurigae> lowin, AVCC is used not only for powering the ADC but some other circuitry surrounding it which is used for the digital side as well.
[16:27:54] <Lambda_Aurigae> if you don't power AVCC then some things could just not work or not work as expected.
[16:34:22] <LeoNerd> I have a vague recollection that the AVCC line is general power for whichever port module has the ADC port on
[16:34:28] <LeoNerd> E.g. PCn on the 328P
[16:35:50] <aandrew> lowin: are you using the ADC circuitry for anything on this project? they usually give you a separate supply pin so you can help "isolate" it from the digital circuitry (not in the sense that they're not connected, but in the sense that the analog supply can be more electrically "quiet" and help you achive better accuracy/repeatability in analog measurements
[16:36:19] <aandrew> and as Lambda_Aurigae said, AVCC can also end up supplying any internal circuitry which may not exactly be analog but which benefits from a quieter supply rail than the digital I/O
[16:36:34] <aandrew> so always hook up all power and ground pins or you could be in for some REALLY weird bugs
[16:40:53] <Posterdati> hi
[16:41:08] <Posterdati> is anyone using the pca9505 gpio expander?
[16:54:29] <Lambda_Aurigae> aandrew, and, it says so right in the DATASHEET!
[16:54:37] <Lambda_Aurigae> Posterdati, never heard of it.
[16:55:08] <Lambda_Aurigae> looks like a nifty toy though.
[17:46:13] <aandrew> Lambda_Aurigae: datasheet? who reads those things. too complicated. just want to apply 5v and go
[17:46:27] <aandrew> Posterdati: I've used I2C GPIO expanders in the same family as that
[17:47:22] <Posterdati> aandrew: I have a strange issue on a linux based box i2c with this gpio
[17:54:29] <Lambda_Aurigae> too bad we don't have the ability to read your mind to determine what a "strange issue" actually is.
[17:55:11] <Posterdati> the port 0 value is set to the chip address configuration
[17:58:09] <aandrew> Lambda_Aurigae: speak for yourself
[17:58:17] * aandrew holds fingers to forehead
[17:58:19] <aandrew> I think ...
[17:58:37] <aandrew> I think he's having an issue where the port 0 value is the same as the chip address config
[18:03:58] <Posterdati> aandrew: and?
[18:04:18] <aandrew> Posterdati: it really sounds like you're fucking up the I2C read
[18:04:30] <aandrew> how are you performing the I2C access?
[18:04:34] <Posterdati> other registers works ok
[18:05:11] <Posterdati> the gpio is connected to a linux box i2c port
[18:09:23] <Posterdati> it is very strange
[18:10:55] <aandrew> hm
[18:11:00] <aandrew> do you have a logic analyzer handy?
[18:11:23] <Posterdati> yes I saw the waveforms
[18:11:28] <Posterdati> they are correct
[18:11:53] <Posterdati> the linux box sends the correct i2c string
[18:59:23] <aandrew> Posterdati: and the PCA9505 is sending back the incorrect data??
[18:59:31] <aandrew> I'd love to see the caps
[19:09:41] <evil_dan2wik> How do I code around a patch of bad flash?
[19:10:02] <Lambda_Aurigae> pad with nop
[19:10:09] <evil_dan2wik> ok
[19:10:18] <evil_dan2wik> There is a small 17 byte long bit of flash that won't zero out when I flash it
[19:10:26] <Lambda_Aurigae> but your verify will likely fail.
[19:10:41] <Lambda_Aurigae> does it reset to 0xFF?
[19:10:48] <Lambda_Aurigae> on an erase?
[19:10:52] <evil_dan2wik> no
[19:11:19] <Lambda_Aurigae> figure out where in your code it falls and pad with nop
[19:11:27] <Lambda_Aurigae> or pad with useless non-called code.
[19:11:35] <Lambda_Aurigae> but, either way, it won't verify properly.
[19:11:47] <evil_dan2wik> It is 182 bytes into the flash
[19:13:44] <evil_dan2wik> The flash always returns as 56 db b7 9b d5 dd 18 6c 20 a6 31 d3 a8 95 0d ff 35
[19:14:14] <Lambda_Aurigae> the chips are so expensive though.
[19:14:19] <Lambda_Aurigae> I would just replace it myself.
[19:14:35] <evil_dan2wik> I already ordered one, I have time constraints though
[19:15:42] <evil_dan2wik> This is a newish chip, It only recently started failing to verify
[19:19:02] <Lambda_Aurigae> again, pad out with nop
[19:28:57] <cehteh> evil_dan2wik: maybe you have bug writing way more frequently to the flash than you intend to do, wearing the flash out?
[19:29:43] <Lambda_Aurigae> cehteh, I've seen one other avr do that in the last 12 years without running a flashkiller on it.
[19:29:56] <evil_dan2wik> Its been used on 2 projects, probably written 20 times to it
[19:29:58] <cehteh> should be pretty rare
[19:30:15] <cehteh> its flash not eeprom?
[19:30:24] <Lambda_Aurigae> I have heard of this happening on cheap chinese avr clones.
[19:30:29] <evil_dan2wik> I haven't used the eeprom
[19:30:42] <cehteh> there are avr clones?
[19:30:49] <Lambda_Aurigae> yes.
[19:31:10] <cehteh> heh ok
[19:31:17] <Lambda_Aurigae> well, not clones exactly, but, counterfeits.
[19:32:02] <Lambda_Aurigae> https://www.sparkfun.com/news/364
[19:32:04] <cehteh> anyway .. for flash there isnt much you can do except to handle the bad places. which really becomes ugly
[19:32:26] <cehteh> jump around, linker script, badblocks list .. whatever
[19:32:48] <cehteh> tossing that chip away and get a new one would be much much easier
[19:32:59] <Lambda_Aurigae> https://www.sparkfun.com/news/395
[19:34:07] <Lambda_Aurigae> and lots of other sites talk about them.
[19:35:08] <evil_dan2wik> This one is a sample from atmel
[19:35:08] <cehteh> how can you make profits by that?
[19:35:16] <evil_dan2wik> so It is doubtful that it is fake
[19:35:25] <Lambda_Aurigae> evil_dan2wik, and,,,parts fail on occasion..nothing you can do about it.
[19:35:40] <Lambda_Aurigae> some devices are actually designed to fail after a certain amount of use.
[19:35:43] <evil_dan2wik> yeah, I get that, I'm just saying, it isn't fake
[19:35:44] <Lambda_Aurigae> in fact, many devices are.
[19:37:15] <cehteh> for eeprom i always add a delay(1000) or so before writing in development code, that a) prevents accidental killing by calling it in a loop, b) reminds me that writing to eeprom should never happen in a timing critical path
[19:38:09] <cehteh> but on avrs with broken flash, its really hard to work around the problems
[19:38:29] <Lambda_Aurigae> and I suspect that once you get one failed page it will spread.
[19:38:48] <cehteh> (also dont always write to the same address .. do some cycling or so)
[19:39:07] <Lambda_Aurigae> that's not easy to do with reprogramming an avr though.
[19:39:24] <Lambda_Aurigae> however, this is exactly why I started playing with pic32...I can execute code from sram.
[19:39:47] <Lambda_Aurigae> which, the xmega can do it too I suppose.
[19:40:27] <evil_dan2wik> How long would it take to write 8 bytes to eeprom?
[19:43:48] <Lambda_Aurigae> datasheet has the specs for that.
[19:43:58] <evil_dan2wik> ok
[19:45:13] <evil_dan2wik> I'm trying to make a power monitor and I want it to write when it lost power. I can detect power loss and I need to size capacitors big enough to pull it through writing.
[19:46:27] <Lambda_Aurigae> that's one hell of a cap.
[19:46:35] <Lambda_Aurigae> I would go with a battery backup instead.
[19:46:49] <Lambda_Aurigae> couple of 3.3V coin cells maybe.
[19:46:58] <evil_dan2wik> a 5v 1F super cap would do better wouldn't it?
[19:47:07] <Lambda_Aurigae> yeah.
[19:47:14] <Lambda_Aurigae> but a 3.3v coin cell would be cheaper I bet.
[19:47:55] <Lambda_Aurigae> hmm..maybe not.
[19:47:56] <Lambda_Aurigae> but,
[19:49:20] <evil_dan2wik> I can get a 5.5v 1F super cap for $1.20
[19:49:29] <evil_dan2wik> and it would last long than a 3.3v coin cell
[19:49:31] <Lambda_Aurigae> yeah...was just looking at the prices.
[19:49:51] <Lambda_Aurigae> I might have to get a couple to play with.
[19:49:58] <Lambda_Aurigae> see what kind of life I can get out of them.
[19:50:26] <cehteh> http://public.pipapo.org/20160108_002.jpg
[19:50:57] <Lambda_Aurigae> homemade cap?
[19:51:16] <cehteh> no standard polyester foil cap
[19:51:27] <evil_dan2wik> pretty big
[19:52:01] <cehteh> the biggiest one i could get
[19:52:10] <Lambda_Aurigae> bah.
[19:52:24] <evil_dan2wik> microwave ones are bigger
[19:52:37] <Lambda_Aurigae> used to make bigger caps from giant pickle jars and aluminum paint.
[19:52:37] <cehteh> yes
[19:52:44] <cehteh> i know biggier caps
[23:30:52] <TheMadDrizzle> Wondering if anyone knows of a native linux arduino / external sensor simulator?
[23:35:06] <cehteh> huh?
[23:35:50] <cehteh> what sensor? just write one ad-hoc, replaying logged data, or calculate something you expect from a real sensor
[23:35:55] <TheMadDrizzle> I'm looking for a simulator that is non-windows based.
[23:36:26] <cehteh> the is simavr and some others
[23:37:49] <TheMadDrizzle> Thanks, I wasn't able to turn that up within my searches.
[23:38:00] <TheMadDrizzle> I'll give it a shot - see if it's what I'm looking for.
[23:38:30] <cehteh> well iirc it has no sensors, maybe a few in examples, usually you have to simulate that somehow else
[23:38:48] <cehteh> i wonder if one could integrate simavr into a spice model or such
[23:39:12] <cehteh> but i really dont use it, just testing on real hardware is easy enough
[23:39:50] <TheMadDrizzle> I dont have access to any of my stuff -it's on its way across the US right now.
[23:40:29] <TheMadDrizzle> I'm looking at building a few LED controllers for my son's room and a thermometer based mash tun for brewing beer.
[23:41:18] <TheMadDrizzle> Both of which I realize are probably dead simple to code for, but I'm not to well versed in this kinda stuff so I'd like to have a shot before my stuff gets here.
[23:41:31] <Casper> simulator sucks, specially once you need to add external parts
[23:41:36] <cehteh> for simple code testing i always have a arduino nano around
[23:42:01] <cehteh> rigging a simulator is somewhat complicated, not so much fun
[23:42:30] <TheMadDrizzle> I'm fairly impatient. I've got a computer and no arduino. lol
[23:44:44] <cehteh> ordering an arduino and wait for it to arrive is possibly faster than setting up a simulator with external components
