Back
[03:08:13] <ferdna> funny
[03:08:16] <ferdna> http://makezine.com/2015/11/05/cnn-shows-adafruit-part-bombing-segment/
[03:11:28] <cehteh> welcome to our new propaganda overlords
[07:23:36] <sabesto> is there any development on avr-libc at all? have to copy the library from atmel studio to work with xmega e devices
[07:24:35] <Lambda_Aurigae> yes.
[07:24:46] <Lambda_Aurigae> as for xmega, dunno.
[07:25:01] <Lambda_Aurigae> xmega is kind of dying from what I see.
[07:26:18] <cehteh> with that saied, i got 2 gcc/toolchain bugs in a row past days
[07:26:37] <Lambda_Aurigae> looks like last release was 1.8.1 back over a year ago....
[07:26:49] <Lambda_Aurigae> aahh..it's avr-gcc that's being actively developed.
[07:26:57] <Lambda_Aurigae> avr-libc seems to be relatively stable.
[07:27:14] <sabesto> but is lacking support for many devices
[07:27:31] <cehteh> there are commits at least
[07:27:35] <Lambda_Aurigae> sabesto, maybe they don't consider xmega to be relevant.
[07:27:45] <Lambda_Aurigae> might be patches out there too.
[07:27:57] <sabesto> all xmegas except the lastest 3 devices are supported
[07:28:10] <sabesto> *latest
[07:28:36] <cehteh> it shouldnt be too hard to add support for newer devices, as long they dont add some esoteric new hardware
[07:29:09] <sabesto> there is already support in the atmel studio version
[07:29:27] <sabesto> i just copied the directory from windows to linux
[09:54:20] <rue_house> congradulations
[09:54:28] <LeoNerd> s/d/t/
[15:45:45] <rekahsoft> Hi all, I'm having an issue with cascading multiple 74HC595 shift registers using an attiny85..I am using 4 shift registers each one driving a seven segment display. The issue seems related to SHCP being received by the chips at different times. Here
https://imgur.com/dDBuODf?desktop=1 is a gif showing bytes being shifted in one at a time. You can see that the display driven by the left most shift register never exp
[15:45:45] <rekahsoft> eriences issues..however the other three occasionally do. Any ideas on how I can fix this? I currently don't own a logic analyzer or oscilloscope so debugging this is quiet challenging. Any help appreciated :)
[16:03:25] <rekahsoft> any ideas?
[16:48:50] <Santh> Maybe a timing issue, try to slow down your data output
[17:15:02] <apo_> rekahsoft: Get one of those 8$ saleae clones
[17:20:05] <rekahsoft> I do think its a timing issue..I tried delays in my code but with no success..I switched out the 10k resistor on PB1 which solved the problem..seems the resistor was causing a clock skew..though without a oscilloscope its hard to know for sure (+ I lack experience in these matters)
[17:20:17] <rekahsoft> thanks for the responses apo_ and Santh
[17:53:31] <sabesto> rekahsoft: use decoupling on every chip
[17:53:44] <sabesto> as far as i can see there is none
[17:54:30] <LeoNerd> I'm using a dirtcheap Saleae clone right now :)
[17:54:48] * LeoNerd is about to talk I2C to a temp/pressure sensor
[17:55:32] <rekahsoft> sabesto: I have it working without the decoupling caps but yes I should use .1uF caps between VCC and GND on each chip, correct?
[17:56:04] <sabesto> probably
[17:56:55] <rekahsoft> sabesto: right now the attiny85 is clocked at 1Mhz so there may not be much noise
[17:57:35] <sabesto> it does not have to have anything to do with the speed of the attiny
[17:57:44] <sabesto> its the speed of the shift registers
[17:58:07] <sabesto> that is what HC stands for
[21:07:10] <SM0TVI> rekahsoft: Also, if you read the data sheet for the '595, I think it has some minimum gap between two of its control signals.
[21:07:57] <SM0TVI> rekahsoft: And yeah, decouple, decouple, decouple. I recommend investing in a baggie of 100nF ceramics.
[21:08:22] <tats> hi everyone
[21:08:58] <tats> can someone tell me if the eeprom_write_block(...) is safe? what happens if the power is shut down in the middle of a write: will my data be corrupted?
[21:09:13] <tats> also what's the difference between eeprom_write_block() and eeprom_update_block()?
[21:11:33] <aandrew> tats: there is absolutely no way to guarantee that a write will successfully complete during a power outage
[21:12:06] <aandrew> the best you can do is include a checksum or CRC over teh EEPROM data and your startup code checks to see if the EEPROM contents are "clean" and reinitialize to defaults if not
[21:12:14] <aandrew> well no that's untrue
[21:12:33] <aandrew> you could put a bunch of capacitance on the VCC line and monitor the unprotected rail
[21:12:56] <aandrew> if you detect a failure you know your worst-case write operation will survive
[21:13:29] <aandrew> but that's work. better to just detect corrupted EEPROM and reinit with known-good values. that takes care of the case of a bad write as well as a "brand new" power on as well as random corruption.
[21:14:49] <tats> aandrew, ok. i was thinking about a process with data redundancy, basically keeping two copies of the data so that if there's an outage I can reinitialize with the last copy
[21:15:14] <tats> just wanted to make sure it was necessary (seems it is)
[21:15:53] <aandrew> you could do that too. which is "best" depends on your specific needs and data set
[21:16:07] <aandrew> basic parameter storage is usually fine being initialized to sane defaults in the case of a corrupted parameter store
[22:49:29] <Casper> tats: eeprom write work by block, if the power fail then normally only that block will be corrupt. However, a power issue can cause the µC to malfunction and issue the wrong command, so you may want to enable the brownout detector, which should avoid that malfunction
[22:50:14] <Casper> there is way however to help against that, like sensing the supply and use a big capacitor
[22:50:43] <Casper> the big cap should be able to power the µC while it do the write...
[22:54:17] <tats> Casper, thanks for the details, I'll see what's the best option for me
[22:55:23] <Casper> as for updateblock... I'ld say that it will accept a partial block data instead of a full, what it will do is read, store to ram, update with your provided data, write back the modified data
[22:55:41] <Casper> a block can not be partially written, it can only be written completly...
[23:09:29] <gorroth> okay, phew, finally got my (currently untested) interrupt-driven uart code written
[23:09:40] <gorroth> along with updated code for handling u2x
[23:09:59] <gorroth> i hope this all makes my comms smoother