Back
[01:20:50] <ptrkOP> You guys have any recomendations for an AVR line that will have good linux support? It will be hosting a web server and basically just talking a few different protocols to other devices
[01:21:15] <Valen> something big ;->
[01:21:24] <Valen> probably cheaper these days to stuff a pi into it
[01:21:49] <ptrkOP> This is something that will eventually be a product. From what I understand the MCU on the PI is quite old
[01:22:18] <Valen> dunno about "old"
[01:22:32] <ptrkOP> hmm maybe I am mistaken.
[01:22:40] <Valen> not that great perhaps
[01:23:11] <ptrkOP> Have any suggestions. I am finding their are lots of options and I just wanted to see what some of the pros thought here
[01:23:40] <Valen> how many are you looking at making?
[01:24:08] <ptrkOP> psh.. that depends on how I can sell it. Lets say ~100 a year
[01:24:59] <Valen> rolling your own board thats able to run linux would be challenging
[01:25:03] <cyanide> home automation?
[01:25:22] <ptrkOP> Nah. Oilfield automation
[01:25:30] <cyanide> close
[01:25:32] <cyanide> lol
[01:25:37] <ptrkOP> Yea. just as simple really lol
[01:25:55] <Valen> I'd suggest an interface by serial to a micro, then use a pi or whatever replaces it
[01:25:55] <ptrkOP> Why do you say it will be challenging valen?
[01:26:06] <Valen> lots of bits and pieces
[01:26:36] <Valen> you're going to need some big IC's most of them are BGA
[01:27:01] <ptrkOP> I can reflow BGA can't I? I have a home reflow and stencil setup
[01:27:05] <Valen> put it this way, the rpi is one of the simplest "linux computers" I know of
[01:27:13] <theBear> pretty sure you can still pull it off non-bga, but the pin pitch is gonna be WAY smaller than bga :)
[01:27:27] <Valen> from what I hear you should xray them after reflow
[01:27:31] <theBear> and if yer willing to lose a bunch of 'standard' stuff you can cut it down too
[01:27:44] <Valen> do you need linux or just want tcp/ip?
[01:27:46] <ptrkOP> theBear: Could you elaborate on that
[01:27:59] <ptrkOP> Uhm.. I think I need linux. It will have a hosted web interface
[01:28:04] <Valen> because you can get webservers that sit in the phy for an ethernet and you can talk to them over serial
[01:28:21] <ptrkOP> Hmm
[01:28:34] <theBear> minimum you need is 32bit proc, mmu and ram, and something to store the kernel(/bootloader maybe)
[01:28:45] <ptrkOP> Right!
[01:29:28] <Valen> you can skip the mmu with some of the dedicated embedded linuxes i believe
[01:29:36] <theBear> but anything beyond serial is gonna add lots of complexity and a big chip or 3, you'd wanna find a proc that had a built in ethernet and phy too, otherwise you end up making a network card on there too
[01:29:45] <ptrkOP> I will be using the RT patch for the kernel
[01:29:53] <theBear> oh, uclinux i think runs without a mmu
[01:29:59] <theBear> why would you use rt for a webserver ?
[01:30:08] <Valen> but really it feels like you are making a rod for your back
[01:30:19] <ptrkOP> it is an alarm system
[01:30:22] <Valen> include a blank area to mount up the linux MCU of the week
[01:30:31] <ptrkOP> rod for my back?
[01:30:42] <Valen> making your life overly hard for the sake of it
[01:30:45] <theBear> rt is about sub-ms latencies, not the difference between seconds and minutes
[01:31:01] <Valen> do all your interface stuff with a micro, if you have any RT stuff do that there
[01:31:17] <Valen> then just have a nice big blank spot in your housing to put the low cost mcu of the week into
[01:31:29] <Valen> low cost linux board of the week rather
[01:31:43] <Valen> that or use one of the dedicated webserver modules
[01:31:50] <theBear> and more specifically relatively guaranteed latencies.. almost noone needs it
[01:32:01] <ptrkOP> theBear, I wouldn't lose anything by using RT would I?
[01:32:10] <theBear> i'd go with a dedicated webserver, but if it was an alarm i'd probably just go with some kind of very basic modem interface
[01:32:22] <Valen> why use it if you have nothing latency dependant?
[01:32:27] <Valen> you gain nothing at all
[01:32:49] <ptrkOP> True. Alarms in the oilfield don't really require sub-ms accuracy
[01:32:52] <theBear> ptrkOP, if you program suitably it shouldn't be an issue, but as soon as you add one thing that uses rt priorities you gotta consider that makes everything else "interruptable", if you will
[01:33:08] <ptrkOP> Ah, I see where you guys are going.
[01:33:50] <Valen> I want rtlinux on the Pi so that i can run a triac off it directly and have it control the power in my oven
[01:34:02] <theBear> apart from anything else, an os and a webserver add a lot of complexity and possibility for bugs
[01:34:03] <ptrkOP> So really all this device needs to do, is talk a few industrial protocols (which I have written or found libraries for all of them in linux) and have cellular connection to push data. The web interface is for configuration and logging
[01:34:05] <Valen> so I need to turn an I/O pin on at a set point in the 50hz mains
[01:34:44] <ptrkOP> Valen: Why do you need rt in your instance?
[01:34:54] <ptrkOP> I see now that I really don't need it, why does yours
[01:35:28] <Valen> so I need to turn an I/O pin on at a set point in the 50hz mains
[01:35:42] <jacekowski> no chance
[01:35:47] <Valen> IE i need to turn the I/O line on 23% through a 50hz cycle
[01:35:56] <jacekowski> arm and x86 is useless for realtime stuff
[01:36:04] <Valen> jacekowski: the RT linux running on my mill would beg to differ
[01:36:15] <jacekowski> then measure your jitter
[01:36:57] <jacekowski> ARM is not as bad as x86 but you still can get close to 100 cycles of jitter
[01:37:15] <Valen> at 800Mhz or so thats very little time
[01:37:26] <ptrkOP> theBear: so you think I should seperate the micro and the webserver?
[01:37:39] <Valen> if you have a micro then yes
[01:37:50] <Valen> if you can do it without a micro then no
[01:38:12] <ptrkOP> What do you mean with or without a micro? What is the alternative to that
[01:38:29] <Valen> my mill runs 4000ns jitter jacekowski
[01:40:21] <Valen> hmm it does look rather large doesn't it
[01:40:42] <Valen> i could get 5 "reliable" points in the waveform
[01:40:56] <Valen> might well be enough
[01:43:23] <jacekowski> how are you planning to sensse the waveform?
[01:43:54] <Valen> zero crossing detector
[01:43:59] <Valen> cheat horribly basically ;->
[01:44:24] <Valen> I haven't gone out of my way to design it, still just pondering it at the moment
[01:44:32] <jacekowski> zero crossing detectors don't work
[01:44:36] <Valen> I'll drop back to a serial micro control later
[01:44:50] <jacekowski> well, they do, but you have to filter the waveform a lot before using it
[01:44:51] <Valen> My plan was something along the lines of an opto running off mains with a current limit
[01:45:20] <Valen> IE when mains gets to ~3 volts it will power the opto
[01:47:27] <jacekowski> i've done something like that with PLL locked to mains frequency and running a micro from resulting clock
[01:48:03] <jacekowski> and i can only say, it didn't work as well as i was hoping for
[01:49:00] <Valen> mine is only running a food oven
[01:49:16] <Valen> i imagine a PLL would be rather more sensitive
[01:51:23] <Valen> I just liked the idea of doing everything in the pi if you will
[01:51:45] <jacekowski> that SoC was meant to be used in media centers not oven controllers
[01:51:59] <jacekowski> and well, thermostat in the oven works pretty well
[01:52:01] <Valen> wheres the fun in using things for the purpose intended
[01:52:08] <Valen> mine got eaten by mice :-<
[01:52:11] <Valen> all the wires
[01:52:30] <jacekowski> how do you plan to measure the temperature and deal with the heat?
[01:52:50] <jacekowski> bear in mind that inside of the oven can reach 400C
[01:53:02] <Valen> I'm not going to put it inside the oven?
[01:53:03] <jacekowski> probably more if things go wrong
[01:53:10] <ptrkOP> kaptop tape and automotive heat shielding?
[01:53:14] <Valen> how do you think regular oven electronics work?
[01:53:26] <Valen> they have a fan and a "cool zone" up the top on top of a shield
[01:53:41] <jacekowski> and simpler so generate a lot less heat to start with
[01:53:48] <jacekowski> RPI just idling runs at ~50C
[01:53:53] <Valen> so it needs replacing, I have a PID controller there now (that I hope will work) and I'd like to eventually replace it with a touch screen, web enabled temperature profile running everything
[01:54:29] <Valen> there is a fan there, specifically to keep the housing and electronics cool
[01:54:45] <jacekowski> what about temperature sensors?
[01:54:51] <Valen> thermocouple
[01:54:52] <ptrkOP> k type thermocouple
[01:55:00] <Valen> its whats in there now
[01:55:18] <jacekowski> well, you need some interface electronics for thermocouple
[01:55:25] <ptrkOP> Valen: Are you using max31855?
[01:55:34] <Valen> you do need a fair bit of glue I grant you
[01:55:44] <Valen> no detailed design work has been done yet
[01:56:00] <Valen> but I presume theres thermocouple to some sort of serial IC's around
[01:56:14] <ptrkOP> it is an amplifer and outputs to spi
[01:56:26] <ptrkOP> yup. It is pretty standard in reflow projects. It is what I am using
[01:56:29] <Valen> like that ;->
[01:56:46] <ptrkOP> I am using the wiz820 for ethernet.
[01:56:47] <Valen> are you the one doing the reflow oven at the moment i saw somewhere?
[01:57:06] <ptrkOP> I haven't linked it anywhere because I am still workign on it
[01:58:41] <ptrkOP> Really all it is is two SSR (
http://www.amazon.com/gp/product/B009AQNOK8/ref=oh_details_o06_s00_i00?ie=UTF8&psc=1) and an msp430 with wiz820 ethernet chip
[01:58:57] <ptrkOP> Got this cheap IR gun to verify temps
http://www.amazon.com/gp/product/B009RUPQGW/ref=oh_details_o02_s00_i00?ie=UTF8&psc=1
[01:59:37] <ptrkOP> originally I had it own a wireless router with openwrt.
[02:22:53] <ptrkOP> Is there a way to see individual pins status in the Atmel Studio simulator, and not just the registers
[02:25:50] <ptrkOP> Figured it out. IO view. Here is an awesome video if anyone else needs help
http://www.youtube.com/watch?v=9QlDSNeuAdY
[02:44:57] <Valen> btw I asked before avrdude -p t84 -c dragon_isp -n -V -F -P usb seems to fire off a reset on the chip without writing anything
[06:15:15] * twnqx looks at his hc-05 happily blinking and wonders what to do next
[06:16:08] <theBear> QUICK ! CUT THE RED WIRE BEFORE IT'S TOO LATE !
[06:16:11] <twnqx> does any of you have a source code for a serial port bridge on avr handy? (send out to one port everything that is received on the other port, bidirectional)
[06:17:27] <theBear> not handy, but it's pretty trivial
[06:17:30] <tzanger> twnqx: that's something you could write up pretty quick
[06:17:43] <twnqx> sure :P
[06:17:44] <tzanger> rx isr of port 1 writes to tx reg of port 2 and vice-versa
[06:17:44] <theBear> as in a line or two per input simple
[06:17:56] <tzanger> hell poll it if that's all it's doing, no interrupts required
[06:17:56] <twnqx> tjat would only work at identical speed
[06:18:05] <tzanger> twnqx: nonsense
[06:18:12] <twnqx> i currently have 2mbit on one, 38400 on the other
[06:18:14] <theBear> i gotta agree with tzanger here
[06:18:23] <tzanger> is it bursty or is it continuous 2mbit?
[06:18:34] <theBear> that's a big difference, you probably gonna be more worried about bufferspace than anything
[06:18:37] <twnqx> bursty, since usb-serial :p
[06:18:43] <tzanger> the UARTs all have FIFOs, and if they're not deep enough you implement tx/rx ISRs on both
[06:19:01] <twnqx> in fact it's usb-serial-avr-serial-bluetooth
[06:19:07] <twnqx> so i don't really know.
[06:19:18] <theBear> i'm a good few years behind on specs, but the fifos in most avrs aint exactly big
[06:19:26] <twnqx> and the can at 90 has two bytes fifo
[06:19:48] <twnqx> guess i'll clone my buffered uart 0 code
[06:19:49] <tzanger> and then write to your own FIFO and enable the port TSE interrupt. TSE ISR then fills the TX internal FIFO and disables itself if the sw FIFO is empty
[06:20:04] <tzanger> hang on I ahve some code
[06:20:10] <twnqx> i have some myself
[06:20:14] <twnqx> no worries
[06:20:32] <twnqx> i just have to make it ready for uart 1 & passthrough
[06:21:31] <twnqx> hm, ok, my code seems unidirectional :P
[06:21:47] <tzanger> this has FIFOs and implements everything I've talked about
[06:22:01] <twnqx> yeah, i have arbitrary sized ringbuffer for tx
[06:23:30] * twnqx makes notes of some code that needs minor refactoring
[06:23:59] <tzanger> twnqx:
http://www.mixdown.ca/dump/gateway.c and .h
[06:24:05] <tzanger> it's for PIC32 but you can adapt it easily enough
[06:24:38] <twnqx> wow
[06:24:53] <twnqx> you even chose almost the same variable names
[06:24:58] <tzanger> ignore the main loop that does anything with AT commands, it is a gateway for a cell modem that periodically injects CSQ commands to display signal strength locally
[06:25:08] <twnqx> static uint16_t txhead0 = 0;
[06:25:08] <twnqx> static volatile uint16_t txtail0 = 0;
[06:25:29] <tzanger> remove that part of the code and it gets real small, and PIC32 hw init is disgusting
[06:25:30] <twnqx> (i use a 4kB buffer)
[06:26:01] <tzanger> yeah I didn't need that big
[06:27:28] <twnqx> hah, you have to software emulate cts/rts handshake on PIC too?
[06:27:46] <twnqx> i constantly overran my ft230x before i implemented that :X
[06:28:31] <tzanger> no, I don't use CTSRTS
[06:29:04] <twnqx> i have to
[06:29:11] <twnqx> the ft230x doesn't double buffer
[06:29:29] <twnqx> so of you send it data while it transmits on usb the data is lost :X
[08:29:41] <Tom_itx> http://www.mouser.com/applications/programmable-logic/?utm_medium=email&utm_source=may2013&utm_campaign=cm-programmablelogic&utm_content=spotlightlm
[09:49:00] * RikusW did a SPI to 3 serial port interface once
[09:49:13] <RikusW> switching using #1 #2 #3 #4 commands
[09:49:40] <RikusW> #1 was modem #2 GPS #3 virtual internal terminal #4 loopback test
[09:49:57] <RikusW> used a m644
[10:22:34] <siers> helo
[10:22:39] <siers> is there any poweruser?
[10:22:50] <siers> i need help with EEPROM reading
[10:23:07] <siers> i have situation
[10:23:46] <siers> i write eeprom with avrdude and programm uses only reading instruction
[10:23:52] <twnqx> right, that was something i still wanted to look into.
[10:24:30] <siers> and after few resets eprom is changed
[10:24:59] <siers> anyone knows how can it be?
[10:25:18] <siers> programm reads eeprom very frequently
[10:25:34] <megal0maniac> RikusW: Hey
[10:25:51] <RikusW> hi
[10:25:59] <siers> who there is cleverest man?
[10:26:05] <megal0maniac> Turns out mb was faulty. Just got the new one under warranty, flashed the bios, same crap :P
[10:26:19] <RikusW> ugh
[10:26:22] <RikusW> bricked ?
[10:26:33] <megal0maniac> Well had to flash with recovery mode
[10:26:46] <RikusW> wrong bios ?
[10:26:47] <siers> hey please give me the nick of cleverest man?
[10:26:56] <megal0maniac> Definitely not
[10:27:04] <megal0maniac> siers: RikusW
[10:27:05] <RikusW> siers: you could pastebin your code
[10:27:17] <megal0maniac> ;)
[10:27:21] <siers> hmm i will try
[10:27:45] <RikusW> megal0maniac: next time you'll be the smart guy :-D
[10:28:01] <RikusW> why did you have to flash twice ?..
[10:28:24] <megal0maniac> And Telkom is doing upgrades or something on the exchanges, so ADSL sync keeps dropping :/
[10:28:29] <megal0maniac> RikusW: Because it's a new board
[10:28:32] <RikusW> mine too :S
[10:28:45] <RikusW> monday and tuesday were BAD...
[10:28:51] <megal0maniac> Good grief. So it's country-wide?
[10:29:00] <RikusW> weren't only for 5 min at a time...
[10:29:04] <megal0maniac> Are you still with your brother or back at the farm?
[10:29:05] <RikusW> seems so then...
[10:29:10] <RikusW> Bloem
[10:31:05] <megal0maniac> Also, the board comes with version 022. Latest is 133. They say you have to update to 099 then only to the latest, you can't do it in 1 step. 099 is where they introduced the mouse-controlled bios
[10:31:27] <megal0maniac> So flash from 022-099, brick it, then recover to 133 :P
[10:31:32] <RikusW> don't really like those too much
[10:31:40] <RikusW> blue screen bios worked fine
[10:32:19] <megal0maniac> Does have some extra options, but you don't need a mouse for that
[10:35:28] <siers> Hello can anyone explain how can it be that after restarting Attiny2313 few times, eeprom values changes?
[10:35:56] <tzanger> is your application writing to eeprom?
[10:36:01] <siers> code have only reading instructions
[10:36:16] <megal0maniac> LAIR
[10:36:22] <megal0maniac> liar even
[10:36:47] <siers> eeprom is readed very frequently and eeprom values is not changed when AVR is working
[10:37:04] <siers> but after some restarts some of 100 values is changed
[10:37:33] <siers> not on next restart but after some.. maybe 5, maybe 10 maybe 7
[10:37:35] <theBear> you read the eeprom rules part of the datasheet ? not got brownout/reset issues ?
[10:37:37] <twnqx> only 0>1 changes in the bits, or also 1>0?
[10:38:10] <siers> i read that voltage issues is only on writing
[10:38:40] <siers> twnqx not understand question
[10:38:48] <twnqx> you said values change
[10:38:49] <siers> all eeprom is bits
[10:39:03] <siers> sometimes values change to FF
[10:39:17] <siers> sometimes to 00
[10:39:36] <siers> maybe some between
[10:39:43] <siers> i will now read eeprom and check
[10:40:34] <RikusW> siers:
http://pastebin.com/Cabt6BD0
[10:40:44] <RikusW> code to read and write eeprom
[10:41:13] <twnqx> i guess he just used eeprom.h ...
[10:41:16] <siers> no changes only to FF
[10:41:26] <twnqx> ff is unprogrammed state
[10:41:41] <twnqx> so your eeprom "loses" the programming
[10:41:47] <tzanger> what does your power supply look like, is it glitching or otherwise acting strangely? do you enable eeprom writes even if you're reading?
[10:41:48] <siers> yap
[10:41:51] <RikusW> siers but remove eearh, only not applicable to t2313
[10:42:03] <siers> eeprom is not writing
[10:42:06] <theBear> been a long time since i read the eeprom rules part of a datasheet, but as i recall there are a few things that can cause corruption without trying to write
[10:42:06] <twnqx> broken chip, or bad voltage during programming, then
[10:42:19] <twnqx> really?
[10:42:22] <tzanger> siers: are you following the eeprom programming directions EXACTLY, including clock speed? If your clock speed is too fast you will not perform a full programming cycle
[10:42:31] <siers> i am not writing in code!
[10:42:32] <twnqx> tzanger: he only writes with avrdude
[10:42:40] <theBear> yeah, try another one, also if it's a dev chip and you programmed it a few hundred (or thousand) times it might just be worn out
[10:42:48] <siers> i write with avrdude
[10:42:52] <tzanger> if you program the chip with too fast a clock for the voltage applied you will get the same issue
[10:42:53] <siers> then read to file
[10:42:55] <siers> all is fine
[10:43:00] <siers> then run programm
[10:43:09] <tzanger> what voltage are you running at? what are your fuse bits set to?
[10:43:10] <siers> after some restarts some data is FF on eeprom
[10:43:15] <twnqx> siers: it can look fine initially if not completed
[10:43:20] <twnqx> give the data we ask, please
[10:43:23] <theBear> i forget when things changed (maybe after can/90s series) but older chips don't have many eeprom/prom writes before they start to die
[10:43:27] <tzanger> siers: here's a test: erase the flash so there is no program
[10:43:44] <tzanger> siers: then program the eeprom with avrdude and reset/read a hundred times to see if the eeprom data disappears
[10:43:47] <theBear> at least not if you debug/troubleshoot the way i do (fiddling a value maybe and then reprogramming, and repeating MANY times)
[10:44:27] <siers> what i must give?
[10:44:29] <siers> fuse bits?
[10:44:46] <twnqx> fuse bits. clock speed. voltage when programming.
[10:45:05] <siers> 5V
[10:45:08] <siers> 20MHz
[10:45:32] <twnqx> what chip?
[10:45:37] <siers> high fuse DF
[10:45:38] <tzanger> you're running an ATTINY13A at 20MHz?
[10:45:42] <twnqx> ah
[10:45:45] <theBear> 20mhz is fast
[10:45:47] <siers> low fuse FF
[10:45:52] <siers> attiny2313
[10:45:59] <tzanger> sorry 2313
[10:46:20] <siers> i have more these
[10:46:24] <siers> and all do the same
[10:46:32] <siers> erase data after few resets
[10:46:39] <tzanger> siers: run the test I asked, it will help determine what si going on
[10:46:50] <tzanger> my gut instinct is that you're running far too fast
[10:46:54] <siers> tzanger wait
[10:47:00] <siers> my english is not so fast
[10:47:22] <siers> i must erase flash and eeprom then write eeprom and reset 20 times AVR
[10:47:29] <siers> then read eeprom?
[10:48:15] <tzanger> siers: no problem. 1. avrdude -e (erase chip). 2. avrdude -U eeprom:w:whatever.hex. 3. reset 4. avrdude -U eeprom:r:whatever 5. goto 3
[10:48:28] <tzanger> basically I want to eliminiate your program on the 2313 as the culprit
[10:48:37] <theBear> hmm, 2313 is sposed to be ok at 20
[10:48:50] <RikusW> siers: try using this code instead
http://pastebin.com/Cabt6BD0
[10:48:50] <theBear> siers, hehe, yer english might not be fast, but it makes me smile
[10:49:01] <tzanger> siers: sure, but the eeprom clock must be within limits
[10:49:02] <siers> :)
[10:49:45] <siers> ok i erase chip, then write that eeprom, then restart chip 20 times then check eeprom changes
[10:51:04] <tzanger> siers: see the bottom of page 18 and OSCCAL on page 26. you must have a calibrated write time to ensure a good program cycle
[10:51:56] <theBear> surely you can't half-write an eeprom that modern ? ie. get a half-state programmed to the actual prom, hmm, do eeproms even work like eproms did ?
[10:52:05] <twnqx> tzanger: is that valid even if you use avrdude for that?
[10:52:25] <twnqx> i mean, that would program by jtag/spi...
[10:52:26] <theBear> siers, out of interest, do you know if it's just one nibble that goes wrong, or a whole byte etc etc ?
[10:53:03] <theBear> also remember, he says the data is fine the first few reads, but THEN it goes wrong
[10:53:40] <tzanger> twnqx: I suspect so; the RC oscillator must be calibrated as it is the only clock used for EEPROM access
[10:54:09] <twnqx> hm
[10:54:13] <tzanger> theBear: I wonder if he programmed, waited 10 minutes and checked (i.e. only one read) if it would be corrupt...i..e is it corrupting over time, not over accesses
[10:54:16] <theBear> tzanger, seriously ? wow, pretty sure half the avrs i'm FAMILIAR with didn't even have r-c
[10:54:17] <twnqx> but it is shipped calibrated i think
[10:54:24] <theBear> tzanger, mmm, now i also wonder that :)
[10:55:02] <tzanger> I am sure avrdude is doing something right, but I'm trying to narrow down the problem. if he erases the program memory on the chip and it still fails, then avrdude is failing him.
[10:55:10] <theBear> twnqx, nah, it's shipped at a mid-range that works o.k on MOST chips, as i recall, might be different on different chips, but either way it's r-c, chances are you aint the same temp/magnetic field/sunspots/etc as the factory calibration room
[10:55:20] <tzanger> if avrdude reads the eeprom flawlessly then it's his program, even if it never writes to eeprom
[10:55:38] <theBear> my memory wants to say 0x08 or 0x80 or so, but my memory aint what it used to be
[10:55:49] <twnqx> so, how do you calibrate that thing?
[10:56:18] <theBear> twnqx, there are a few methods, the most sensible 2 or 3 are mentioned in official appnotes
[10:56:23] <siers> tzanger
[10:56:24] <theBear> maybe even datasheets, i forget
[10:56:30] <siers> no changes in eeprom
[10:56:32] <tzanger> you write to OSCCAL. it is preloaded with a calibration value from the factory that should get you +/-10% of nominal at 23C (why 23?) but you can get it down to +/-2% if you calibrate yourself and write the new value there
[10:56:42] <tzanger> siers: ok, so it looks like it is your program
[10:56:58] <theBear> tzanger, pretty sure he means how do you do the self-calibration without a crystal
[10:57:05] <siers> but i have no write instructions
[10:57:12] <tzanger> siers: are you playiing with OSCCAL or CKDEV in your code?
[10:57:25] <siers> no
[10:57:33] <siers> <siers> ldi r30,1
[10:57:41] <twnqx> AVR053 appnote
[10:57:41] <siers> out eear,r30
[10:57:47] <siers> sbi eecr,0
[10:57:52] <siers> in r16,eedr
[10:58:02] <siers> that is my reading code
[10:58:17] <theBear> hehe, times like this it's tempting to see how many years i can stretch between actually doing ANY avr programming/datasheet reading and still be helpful in here :)
[10:58:59] <tzanger> siers: why are you not following the code on page 20 of the datasheet?
[10:59:15] <siers> i am fallowing
[10:59:20] <siers> what is different?
[10:59:47] <siers> write adress register
[10:59:54] <siers> set bit 0 to one
[11:00:02] <siers> read register..
[11:00:03] <tzanger> siers: you're not checking to make sure there is no operation in progress (which is a far shot, but follow and see)
[11:00:08] <tzanger> also do you have interrupts disabled?
[11:00:18] <theBear> page 23 ? what datasheet we talking about here ?
[11:00:18] <siers> i am not checking WRITE operations
[11:00:22] <theBear> oh, 20 <grin>
[11:00:30] <tzanger> siers: correct. I know you are not writing
[11:00:36] <siers> interrupts is not dissabled
[11:00:38] <tzanger> but make sure the hardware is in the correct state before you read
[11:01:10] <siers> i will try to disable interrupts and then write results here
[11:01:34] <tzanger> cli; loop: sbic eecr, eepe; rjmp loop; out eear, address; sbi eecr, eere; in r16, eedr
[11:01:41] <tzanger> actually
[11:02:01] <theBear> oooh, read the bit just under the code on page 20, explains (broadly) how you can corrupt the eeprom without writing by having bad power
[11:02:02] <tzanger> cli; loop: sbic eecr, eepe; rjmp loop; out eear, address; sbi eecr, eere; in r16, eedr; sti
[11:02:04] <RikusW> siers: did you inlcude the right inc file ?
[11:02:36] <tzanger> I don't like the cli and loop but I don't see a quick way to re-enable interrupts to disable in the loop. anyway.
[11:02:46] <tzanger> follow the code example, wrap it in cli/sti and see if it helps
[11:03:03] <tzanger> I think his power is fine if avrdude is working, but he didn't describe his setup
[11:03:21] <twnqx> theBear: time to work on it again, then ;)
[11:04:20] <theBear> tzanger, maybe, often programming has different/better power than non-programming tho, depending of course on how you setup your board/chip
[11:04:57] <siers> i have any load on AVR except oscilloscope
[11:05:07] <siers> have no
[11:05:31] <siers> i use 9V full battery and 7805 regulator
[11:05:47] <theBear> mmmm, that should be more than quiet enough
[11:06:29] <RikusW> and caps on the regulator ?
[11:06:33] <RikusW> 100nF ?
[11:07:46] <tzanger> that regulator is a poor choice for your battery application, it'll drain your battery without any load, but it's good for testing
[11:11:29] <theBear> tzanger, yeah, but it's "common practice" and if he got no load on the avr, it's a cheap reg and only wasting a little less than the avr is using
[11:12:14] <tzanger> oh I know
[11:12:19] <tzanger> sorry it's just my design engineer showing :-)
[11:13:01] <siers> cli, sei did not solve problem
[11:13:44] <siers> i will change the battery and tried with realy full one
[11:13:54] <siers> RikusW caps is 2.2uF
[11:14:04] <RikusW> fine too
[11:15:00] <theBear> tzanger, i'd feel different about it if i still had access to somewhere that sold fancy regs, but these days i got no accounts and no work, and the local place don't got tiny switchers :)
[11:16:29] <tzanger> siers: you should have a 0.1 and 0.01uF cap across the avr, as close to the chip as possible (directly under is best) and with as short leads as possible
[11:20:02] <siers> with full battery the same..
[11:20:16] <siers> i don't get it
[11:20:26] <siers> how can it earase eeprom with low voltage?
[11:20:51] <siers> does it means every time the battery is out my eeprom will erase?
[11:21:57] <siers> i am making some komercial thing and there will be very more times vhen battery vill be out
[11:22:03] <theBear> siers, if there is a risk of low supply you should have a brownout protection/reset circuit.. like the datasheet says, under bad power conditions the avr can't execute instructions properly, meaning that ANY instruction could randomly act like any other, or even do things that there is no instruction for
[11:22:09] <siers> how can i save my eeprom from such cases?
[11:22:21] <megal0maniac> bod!
[11:24:06] <siers> the first reading instruction is after 2secs AVR is ON
[11:24:26] <siers> that means the Power must be stable..
[11:24:47] <theBear> just now you asked about low voltage, not your current issues :)
[11:24:52] <theBear> i answered appropriately
[11:25:17] <RikusW> siers use the BOD
[11:26:04] <siers> but if voltage is OK?
[11:26:11] <siers> what can it be else?
[11:26:13] <megal0maniac> Linux people, can you do a kernel upgrade in chroot?
[11:27:10] <theBear> define kernel upgrade
[11:27:42] <megal0maniac> theBear: dpkg -i linux-image-3.6.11-kirkwood-tld_1.0_armel.deb
[11:28:29] <theBear> heh, i dunno deb well, but i'm gonna say yeah sure, just that depending on where you chroot lives and how you got things setup, you might wanna make sure /boot is mounted so the kernel lands in the 'right place'
[11:30:07] <megal0maniac> :D Well that's good, it didn't trash the host system. It's not behaving, but this is the install which wasn't booting (and still isn't) so I don't expect much
[11:31:24] <theBear> mmm, dpkg should be able to touch the host system, from long long ago when i used 'normal' distros, i'd say it just lands the kernel somewhere standard with a standard kinda name
[11:31:47] <theBear> also it can't POSSIBLY trash the host if you don't have proc and sys and maybe dev mounted
[11:34:25] <megal0maniac> theBear: Nevermind. Things are just breaking everywhere. I shall just upgrade from Squeeze. At least that boots :/
[11:45:04] <megal0maniac> You have got to be kidding me...
[11:45:15] <megal0maniac> New motherboard, same shit :(
[11:47:49] <theBear> what shit ?
[11:48:52] <theBear> also if it bricks on the 99 update, you should probly recover to 99, boot and reset bios to defaults and clear any nvram/eeprom/pci config options in there, reboot so that stuff all happens, then either update or recover to the newer on
[11:48:55] <theBear> one
[11:49:27] <theBear> and if recover to 99 doesn't work, then 99 is plain broke, or at least your copy, and the jump to the latest that needs 99 is never gonna work
[11:49:33] <theBear> what is this, intel mobo ?
[11:49:38] <theBear> oh wait, arm ?
[11:55:43] <ptrkOP> What is the standard AVR define for individual pins on a port? Or do I need to define them myself
[11:58:09] <tzanger> oh he left
[11:59:14] <tzanger> he didn't measure his supply and it was running down at 1-2V and causing sporatic operation?
[11:59:36] <megal0maniac> theBear: This is the intel mobo now
[11:59:38] <tzanger> at that voltage he would also be off the SOA for supply voltage @20MHz
[12:00:03] <theBear> megal0maniac, hehe, know how i guessed yet ? what flash util you using that fails ?
[12:00:18] <theBear> tzanger, he insists on fresh 9v batteries
[12:00:32] <megal0maniac> SSD "disappears" intermittently, usually under load. Reset the machine, enter boot menu / bios and ssd isn't there. Power cycle brings it back
[12:00:58] <megal0maniac> I've sorted out the BIOS update, but the only reason I updated at all was because it was doing the exact same thing on 022
[12:01:05] <theBear> hmm, you got a supply with WAY over 20amps of 12v and at least 3a of 5vstby ?
[12:01:23] <tzanger> today seems to be power supply issue day on #avr
[12:01:25] <theBear> intel are very touchy on those 2 voltages
[12:01:36] <megal0maniac> Works fine with a spinny disk
[12:01:41] <megal0maniac> Even with 3 spinny disks
[12:02:01] <megal0maniac> But not the SSD by itself, and the problem doesn't seem to get worse if i add drives
[12:02:25] <theBear> interesting
[12:02:41] <megal0maniac> I have two 12V rails, 14A + 15A and 2A on 5Vstb
[12:02:54] <megal0maniac> *5Vsb
[12:02:55] <theBear> tried the ssd on a similar system ? say, same chipset but different mobo
[12:03:07] <theBear> mmm, if it screws up while booted it aint a standby issue
[12:03:16] <tzanger> megal0maniac: and the issue is not the SSD? Using the same cable/port for the SSD as the spinny disk?
[12:03:32] <tzanger> is there a firmware incompatibility with the SSD and the SATA controller on the motherboard?
[12:03:33] <megal0maniac> Well I sent it back to the supplier, they said the ssd is fine but mb is faulty. Hence them giving me a new one
[12:03:45] <megal0maniac> tzanger: I've tried different cables
[12:03:49] <theBear> yeah, but suppliers aint smart, you ever met the 'techs' at a pc supplier ?
[12:03:57] <megal0maniac> theBear: These ones aren't bad
[12:04:11] <tzanger> you can't deterine that without exact firmware levels of the SSD and the exact chipset/SATA controller on the MB
[12:04:12] <megal0maniac> I'm going to try my luck making them give me a different mobo
[12:04:46] <theBear> i don't care how good a supplier they are, there's a reason those people work on swap/replace butchery tech stuff for a living, it's cos they aint smart enough to understand things like bios updates and intermittant faults at a low level
[12:05:48] <megal0maniac> theBear: True, but it suits me just fine if they'll give me a different mobo :P Both the parts are under warranty and I doubt they want me coming back every week with another "problem" mobo
[12:05:53] <megal0maniac> :D
[12:06:00] <tzanger> it's got nothing to do with that. it's cheaper to replace than try to diagnose.
[12:06:08] <megal0maniac> tzanger: I know
[12:06:19] <megal0maniac> But they still don't know how usually
[12:06:28] <tzanger> of course not
[12:06:39] <tzanger> you don't hire a doctor to shovel manure
[12:06:42] <megal0maniac> Or don't care, due to the volume of machines passing through
[12:06:48] <theBear> but yeah, demand a different board, if it comes to it, demand they show you it working with the ssd
[12:07:30] <megal0maniac> I'll report back tomorrow. Stupid Intel. You used to be clever :/
[12:07:42] <megal0maniac> I'm off. Thanks for the input
[12:08:53] <theBear> that's cool, if yer ever need intel-related flash-failure tips i'm REAL up on that this year
[12:12:23] <tzanger> haha
[13:08:37] <carp3> what communication protocol do you recommend for connecting to avr's together? (20cm length)(1kb/s max.)
[13:08:52] <Casper> spi?
[13:09:27] <carp3> may i ask why ?
[13:10:40] <RikusW> Aor uart
[13:10:42] <Casper> it's there, good for short distances
[13:10:49] <Casper> d
[13:11:11] <RikusW> uart is fairly easy to use
[13:11:21] <RikusW> 9600bps will do for you
[13:14:52] <carp3> is it ok to connect TX pin of my master mcu to 4 slaves (RX pin ) and send messages like this: M1M100X (M1M is the identifier and x means end. 100 is the number i want to send to the slave number one. )
[13:18:48] <Casper> often, what you will do is: target, packet size, data, checksum
[13:19:04] <Casper> possibly a packet start identifier
[13:20:11] <Casper> so you may do packet start magic number, byte ID, byte/word size, variable data, checksum, end of packet magic number
[13:20:26] <Casper> of course, the start and end is optional, so does the checksum
[13:20:40] <Casper> but in a bus, it's suggested that you do put it
[13:21:07] <Casper> oh I forgot the target ID... and possibly a source ID
[13:21:39] <theBear> i THINK he meant "two" avrs
[13:22:18] <theBear> oh, he said slave no 1., i was wrong
[13:24:39] <RikusW> carp3: multiple slave tx pins are a problem, unless you make it open collector with a pullup
[13:25:01] <theBear> but when he said tx/rx (==serial) his scheme looks ok, except a little inefficient.... for example if you only have <255 slaves, the identifier only needs to be a single byte, and assuming fixed length packets (ie. fixed length data field) you only need a start OR a stop (byte) added to confirm start or end of 'packet'
[13:25:23] <theBear> i think the slaves only receive
[13:25:57] <carp3> RikusW: i just want a simple/slow one way communication . with single master and 4 slaves .
[13:26:19] <RikusW> that should be ok
[13:26:28] <RikusW> tx to multiple rx
[13:27:36] <carp3> theBear: but with single byte identifier it's not possible to monitor bus using a terminal.so i just want to stay in visible bytes.
[13:28:11] <Tom_itx> is it as easy to fwrite() to the top of a file as it is to append to the bottom?
[13:28:34] <RikusW> fseek ?
[13:28:56] <Tom_itx> what about the end of file marker etc
[13:29:10] <theBear> carp3, if you only got 4 slaves you can use a single byte and a single start or stop, ie. X1100 means start-slave1-value100
[13:29:10] <carp3> Tom_itx: you mean shifting whole file ?
[13:29:13] <Tom_itx> i want to write to the top
[13:29:14] <Tom_itx> yes
[13:29:31] <Tom_itx> you typically write to the bottom
[13:30:16] <Tom_itx> what's 'rb' ? open(filename, 'rb') ?
[13:30:19] <Tom_itx> mode but what mode
[13:31:21] <RikusW> Tom_itx: do you want to modify or truncate ?
[13:31:30] <theBear> err, he wants to insert
[13:31:38] <Tom_itx> yeah insert but at the top
[13:31:44] <carp3> What networking topology do you recommend ? star ? ring ?
[13:31:51] <theBear> it's not inserting at the bottom, it's appending <grin>
[13:31:53] <Tom_itx> somebody asked if i could show my log dates newest first
[13:32:12] <theBear> carp3, for that it really shouldn't matter unless you get up to mhz speeds and longer cables
[13:32:38] <RikusW> Tom_itx: you'll have to read the entire file and put in the new line and then write it all back again...
[13:32:45] <Tom_L> def append_line(filename, line): data = open(filename, "rb").readlines()[:-len(footer)] data += [line, "\n<br/>\n", "\n".join(footer)] write_lines(filename, data)
[13:32:52] <Tom_L> that's the function
[13:33:06] <Tom_L> just need to modify it to write to the top
[13:33:21] <theBear> mmm, i guess we talking fat ?
[13:33:33] <theBear> or inside-os ?
[13:33:39] <RikusW> a
[13:33:45] <Tom_L> i think it's python
[13:34:07] <Tom_itx> anyway, i gotta run right now
[13:34:27] <theBear> :)
[13:34:47] <Tom_itx> i haven't messed with anything like that for quite a while, i'm a bit rusty
[13:36:17] <theBear> pfft, you don't know the meaning of quite a while or rusty :)
[13:59:19] <tzanger> heh
[13:59:22] <tzanger> a greybeard, are you?
[14:00:03] <theBear> only slightly, but that's stress
[14:00:17] <tzanger> mine's kids
[14:00:34] <theBear> more of a few years between business and bad stuff happening to/around me kept me away
[14:00:48] <theBear> not to mention everytime i move i got a bad habit of not setting up a workbench/area right away
[14:01:30] <theBear> my 'electronic music studio' has only been maybe 20% plugged in for the first time in MANY years recently, were 3 or 4 house moves it didn't even get put in place, letalone plugged in :)
[17:08:36] <TechIsCool> I have a question. Is this how I enable the pull up resistor for PD0? PORTD |= (1<<PD0); // Enable Pull up Resistor
[17:12:41] <ptrkOP> PORTD |= (1<<0) //enable pullup on PD0
[17:15:06] <tzanger> TechIsCool has the better code, it's exactly the same instruction wise, but his is more portable or at least will flag an error if you move to a differnet port :-)
[17:15:35] <TechIsCool> tzanger: Alright now to find out why its not working hardware side then
[17:15:36] <ptrkOP> PD0 for some reason isn't recognized in Atmel studio 6.1
[17:15:55] <ptrkOP> Or I am doing something wrong
[17:16:10] <TechIsCool> ptrkOP: it compiles in my 6.1 its just not pink
[17:16:13] <tzanger> wrong #include?
[17:17:00] <ptrkOP> Oh wow I guess I just made that up haha. Works fine
[17:17:03] <ptrkOP> derp
[17:23:04] <specing> tzanger: it wouldn't flag it
[17:25:17] <TechIsCool> So I should be reading 5v from my input pin with a dvm?
[17:25:23] <TechIsCool> on D0
[17:27:08] <specing> you should be reading Vcc on your pin
[17:27:19] <TechIsCool> is this correct DDRD &= ~(1 << PD0); //Set PD0 as input
[17:27:29] <TechIsCool> or do I have it written wrong
[17:39:06] <jadew> it's correct
[17:49:03] <Tom_itx> TechIsCool there are also macros for doing that
[17:51:40] <Tom_itx> #define bit_get(p,m) ((p) & (m))
[17:51:40] <Tom_itx> #define bit_set(p,m) ((p) |= (m))
[17:51:40] <Tom_itx> #define bit_clear(p,m) ((p) &= ~(m))
[17:51:40] <Tom_itx> #define bit_flip(p,m) ((p) ^= (m))
[20:12:44] <TechIsCool> so somehow my pull up is not being set not sure why
[20:13:00] <TechIsCool> I do this
[20:13:02] <TechIsCool> DDRD &= ~(1 << PD0); //Set PD0 as input
[20:13:04] <TechIsCool> PORTD |= (1 << PD0); // Enable Pull up Resistor
[20:14:34] <Casper> should work
[20:14:40] <Casper> you might have other errors
[20:14:45] <Tom_itx> i don't rely on internal pullups, they're weak
[20:14:54] <Casper> same for me
[20:15:01] <Casper> and imprevisible in strength
[20:15:05] <Casper> 20-60k...
[20:15:14] <Tom_itx> make sure that's not the problem
[20:15:58] <Casper> I only use the pullup for unused pins, so they don't float
[20:16:14] <Casper> I prefer that to output and shorting
[20:16:30] <TechIsCool> true
[20:22:27] <tzanger> I really like _SET/_CLEAR macros that use _BV()
[20:23:00] <TechIsCool> _BV is the same as 1<< correct
[20:27:32] <tzanger> yes
[20:54:57] <jadew> I use the internal pullups for buttons
[20:55:08] <jadew> rotary encoders too
[20:55:16] <jadew> don't think I use them for anything else tho
[20:56:01] <tzanger> I almost always add my own external pullups. I only use internal pullups when I'm space constrained
[20:56:40] <jadew> I hate drilling PCBs, so I always try to avoid additional holes if possible :P
[20:57:01] <jadew> hate etching them too, but that's another story
[21:25:30] <tzanger> yeah I haven't done a board at home in almost two decades now
[23:11:28] <R0b0t1> jadew: I would suggest moving to surface mount.
[23:12:53] <MrMobius> R0b0t1, youre only like 2 hours late to te discussion
[23:15:53] <jadew> R0b0t1, I do use surface mount whenever possible, but usually it's harder to route on a single layer
[23:17:16] <R0b0t1> Yeah...
[23:17:24] <R0b0t1> If you use 0805 you can sometimes put traces under them
[23:18:57] <jadew> I avoid doing that, since I don't get to have a solder mask, but yeah, it's possible
[23:19:09] <Valen> 805 can easily have a trace under it on an ordered board
[23:58:49] <rue_house> damn, all the avr datasheet links are obsolete
[23:59:02] <Casper> fix it
[23:59:15] <rue_house> who sent me an update that had all those damned xmegas in it