Back
[00:52:06] <_abc_> https://sourceforge.net/projects/avr-ada/ ...
[01:07:37] <Mr_Sheesh> ada on avrs? >.>
[01:20:32] <_abc_> avrdude i giving me a hard time: usbasp writing fuse 0xFD to a 328p succeeds but reads back 05 and flags a makefile error. Writing 05 removes the error but THEN the code does not work!
[01:21:27] <_abc_> So efuses on atmega are ---- -BBB where BBB are brownout voltage select bits. What scret fuses did atmel add to efuses since it no longer works when the '-'s are written 0's ...
[01:33:35] <antto> oh craps, usbasp
[01:41:34] <_abc_> What?
[01:45:00] <antto> i've had only bad luck with those
[01:45:45] <_abc_> It's because of dodgy electronic design and zener diodes with high capacitance.
[01:45:51] <antto> it writes one thing, then it doesn't verify it, but if you go and actually read it - it turns out that it *has* written it
[01:46:06] <_abc_> The updated version seems okay
[01:46:22] <antto> i don't trust it anymore
[01:46:30] <antto> i have a non-working one here
[01:46:47] <antto> the atmega inside works, i even updated the FW
[01:47:13] <_abc_> Check the 'non working' one for latest software then get rid of the 2 zeners and put in the highest quality zeners you can find.
[01:47:14] <antto> but when i connect it to the computer - it dissapears from the USB during flashing a chip
[01:47:36] <_abc_> Also add a 10nF cap at Reset of the mega to gnd.
[01:47:51] <antto> ugh, that thing is on a black board with SMD components
[01:48:10] <_abc_> Just do what I said, the zener business on usbasp is evil
[01:48:34] <_abc_> usb bus capacitance allowed is 10pF at each end the zeners add 150, each
[01:48:55] <_abc_> and set the boden etc fuses on the usbasp right. The newest fw does this
[01:50:44] <antto> wellz, i see two SMD diodes
[01:51:06] <antto> they are orange and have a blue stripe
[01:51:50] <_abc_> orange=3 blue=6 3.6
[01:52:16] <_abc_> ebay etc? remove. You need the smallest sot23 or sod80 ones you can find, preferrably from nxp or so
[01:52:59] <antto> thanks but.. i made myself an STK200 thing
[01:53:10] <antto> that's what i use at home
[01:53:26] <_abc_> I also have a STK200 but parallel ports are rare. I verified it works nicely on linux with a pci multi io card fyi
[01:54:13] <antto> i have a Dell optiplex small-form-factor machine with quad core cpu running linux, it has a parallel port >:)
[01:54:29] <antto> parallel port ftw!
[02:12:26] <antto> i wish it could do PDI too
[02:12:44] <antto> but it's still more reliable than the usbasp
[04:03:52] <antto> http://i.imgur.com/EMZzUdq.jpg huehue
[04:37:07] <_abc_> Has anyone got the elm fat for avr going without mods? It does not seem to want to work here. Card detection error.
[04:39:37] <carabia> I don't know, the code is so fucked up I felt like it was really a pain to debug it
[04:39:55] <carabia> I only need read capabilities so I wrote my own fat driver for reading
[04:44:18] <_abc_> ouch
[04:44:38] <_abc_> The code is pretty good quality but it has the usual "universal" attributes aka #defines over defines
[04:45:11] <_abc_> Problem is I took one of his working example projects and even that does not do what is needed, with small hw changes.
[04:46:00] <_abc_> It took me 2-3 days to interface a spi serial flash to an avr from scratch, invent some custom logging fs and make it work. Only bottleneck was serial download speed over uart.
[04:46:21] <_abc_> Now I need to debug someone else's code and it's not even an arduino. Doh.
[04:46:24] <_abc_> laters
[06:34:03] <antto> i tried zeroing a bunch of registers (for timers, UARTs, SPI, etc) before doing "goto *(0x1F000);" but i still can't quite get it to properly run the bootloader
[06:34:23] <antto> i guess it's not gonna happen with a jump like that
[06:56:55] <_abc_> Oh the fun. The code worked exactly once confirming it might work, and never again.
[06:56:57] <_abc_> grr
[06:57:27] <_abc_> antto: are you trying to jump into the bootloader?
[06:58:04] <antto> yup
[06:58:44] <_abc_> Tried with interrupts off?
[06:58:53] <antto> of course
[06:59:23] <antto> i even tried to turn off timers/uarts/spi which the firmware uses
[07:01:45] <daey> doesnt the bootloader section start with the interrupt table again
[07:20:08] <carabia> _abc_: fatfs?
[07:21:10] <carabia> I think it _might_ work, if you just implemented your own spi (or sdio) read/write-routines, and just let fatfs handle the fs-level abstraction.
[07:22:28] <_abc_> okay it works. Key points: 1) do NOT omit a 100k pulldown on CLK especially if the wiring is happily receiving noise. The card won't init if there is noise before proper setup and something gets clocked in 2) provide beefy driver on +3.3V card vcc. I used 10 ohms and I had 0.3V drop on it in idle. When working the card sucks power like a pentium!
[07:22:35] <carabia> You don't need to expose a big set of routines, and what I remember from some of the routines shipped with it seemed fishy at best. Then again, I don't know, cause the code looked like a mess.
[07:23:17] <_abc_> It's not fishy it is very nice and very clean. The man volunteered to do it, it is an enormous piece of work to make all that work together.
[07:23:33] <_abc_> He even comments in English which is probably hard for him.
[07:23:37] <_abc_> He's Japanese.
[07:23:54] <carabia> to me, it's far from clean. But sure, it probably works. Just the overhead that bothers me.
[07:24:09] <carabia> _abc_: what kind of frequencies are you clocking it?
[07:24:20] <_abc_> There is no serious overhead with -Os and properly set up ff.c using its fconfig.h
[07:24:29] <carabia> Eh, yes there is
[07:24:33] <_abc_> carabia: I did not look, cpu/64 or such
[07:24:44] <carabia> and what's cpu at?
[07:27:12] <_abc_> It starts at (F_CPU / 64) and runs at F_CPU/2. CPU is at 12.000MHz now
[07:27:33] <_abc_> Fast enough for what I need.
[07:27:57] <carabia> Because I've never had to use any sort of pulldown on spi running at clocks between ~150 kHz to 10 MHz
[07:28:14] <_abc_> It's just the OCR1+Timer1 based tick that gets in the way. I will fix that soon.
[07:28:18] <carabia> on the spi clock line, that is
[07:28:28] <_abc_> carabia: the pulldown needs to be on clk when the spi pins are tristate
[07:28:51] <_abc_> And a pullup on cs can also help but is not really needed apparently.
[07:28:59] <carabia> pullup on cs is usually just for the boot
[07:29:14] <carabia> and i don't get what you mean, when the "pins are tristate"?
[07:29:18] <_abc_> This circuit puts the spi in tristate / off mode when not using the card.
[07:29:37] <_abc_> iow spi peripheral off and normal io pins used as inputs and not pulled up
[07:29:47] <carabia> alright and you can't control it?
[07:29:57] <_abc_> ... please re-read what I wrote?
[07:30:12] <xoom> hi
[07:30:17] <carabia> so you're muxing them?
[07:30:28] <_abc_> Now I am switching power with a BC557C (!) with Ib ~ 2.5mA and it is just barely enough to not collapse the psu
[07:30:39] <_abc_> of the card when it draws power
[07:30:49] <_abc_> carabia: I am muxing them but the thing goes to sleep sometimes
[07:31:09] <carabia> yeah got it. Well, it's your application-specific thing, really
[07:31:24] <carabia> not a universal one
[07:31:49] <xoom> is there any good solution to make sure that one amega pin not goes high by glich or smth? :)
[07:32:15] <carabia> also, when using sdhc-cards (well, every sd card really is, nowadays), you're set to transfer size of 512 bytes
[07:32:28] <xoom> with that IO i control power supply output relay..
[07:32:48] <carabia> fatfs handles reads with offset (crossing sector boundary, and not) by first buffering the first sector
[07:33:01] <carabia> then it does a memcpy from the sector to the readbuffer
[07:33:23] <carabia> if the last sector is also not aligned, it does the same thing there. it buffers the sector, memcpy to readbuffer, and return
[07:33:37] <carabia> now with avr (not having dma), this is just overhead
[07:34:08] <_abc_> carabia: I only need to write some data from time to time and read a setup file once. Speed is no concern.
[07:34:14] <carabia> where you could implement a disk read function that can take a variable-length "read x bytes" argument, to deal with partial sectors and not aligned
[07:34:34] <carabia> he does mention this in his note, but yes, this is overhead. and memcpy isn't the fastest thing around.
[07:34:46] <_abc_> Code is quite fat at 11468 bytes flash just the fat and mmc systems and a simple test main.
[07:35:10] <carabia> now arguably he couldn't really do it, because you need to account for systems with dma-capability where you would just return blocks that are always 512-aligned
[07:35:20] <carabia> and do the memcpys from the front and the back if necessary
[07:35:34] <carabia> but i wrote a much more efficient way of handing it.
[07:36:01] <carabia> where you can read partial sectors straight to the readbuffer with an offset
[07:37:07] <_abc_> With no dma the speed will be about the same.
[07:38:41] <carabia> it is faster however, I have tested it
[07:40:00] <carabia> most of the time the real crux isn't even the transfer itself though
[07:40:08] <carabia> it's the seek time of the card itself
[07:40:52] <_abc_> What was that dd like utility again which copies from bad disks without wasting too much time?
[07:41:35] <xoom> im using external interrupt for button
[07:41:55] <_abc_> ddrescue!
[07:42:41] <xoom> is anybody can see my messages or im ignored? :D
[07:43:08] <LeoNerd> xoom: We see you fine. your question is just vague
[07:43:47] <xoom> oh atleast i know that you can see :)
[07:44:46] <xoom> the problem is that i want to make sure that this relay works withhout gliches
[07:45:03] <xoom> as it controls output (ON/OFF)
[07:45:28] <cehteh> add a external pullu/pulldown
[07:45:45] <xoom> so like now if try power up atmega rapidly few times i sometimes get relay ON
[07:45:55] <cehteh> and how do you drive the relay? why relay?
[07:46:19] <cehteh> and you didnt forget the flyback diise?
[07:46:20] <xoom> i drive NPN transistor that drives that relay
[07:46:22] <cehteh> diode
[07:46:24] <LeoNerd> Possibly high-Z noise on reset?
[07:46:35] <cehteh> yeah .. external pulldown
[07:46:35] <carabia> just pull the tranny down, problem solved
[07:46:37] <xoom> flyback diode is there
[07:46:37] <LeoNerd> Ah.. NPN. Less likely
[07:46:53] <LeoNerd> Quite often a problem on FET-based switches if people forget about the pull-{up/down} res
[07:46:55] <cehteh> also bootloader may do strange things on some io pins
[07:47:03] <xoom> reset is with 4.7k pulled up
[07:47:07] <xoom> + 100nF
[07:47:24] <xoom> there is no bootloader
[07:47:31] <cehteh> not reset, your io pin, but npn .. like LeoNerd saied, not that critical
[07:47:32] <carabia> xoom: pull the transistor down, d'oh
[07:47:42] <cehteh> 100nf on reset?
[07:47:50] <xoom> RC filter
[07:48:04] <cehteh> where?
[07:48:07] <cehteh> vcc?
[07:48:30] <xoom> C to gnd
[07:48:31] <carabia> the reset obv :D
[07:48:38] <cehteh> ah that way
[07:48:46] <carabia> lolol
[07:48:47] <cehteh> you likely dont need that, but wont hurt
[07:49:04] <cehteh> 100nF between VCC and GND is mandatory
[07:49:05] <xoom> but if i put pull downt on transistor ir can still swich on
[07:49:33] <xoom> i think there need so code to make sure it wont switch on
[07:49:44] <cehteh> are you sure your code doesnt have a glitch?
[07:50:27] <xoom> it can be .. atleast there is no any checking for gliches
[07:50:38] <cehteh> try to load some empty main and reset it a lot times .. then try some main which sets the pin as output pulls the relay down
[07:51:15] <cehteh> good idea is to add some blinking on some io pin/led on reset at least for debugging, then you see if accidental resets happen
[07:51:52] <carabia> ...or just scope it.
[07:52:18] <cehteh> led is simpler because its always there :D
[07:52:48] <carabia> well sure
[07:53:10] <_abc_> And learn morse so you can read proper messages off the led
[07:53:25] <xoom> :))
[07:53:39] <cehteh> anyway, drive strength on avr's should be high enough that you dont see glitches on a io pin, leaves only that the pin is high-z and has some undefined potential, which is a problem with fets, not so with bjt's
[07:53:53] <cehteh> which finally tells, most likely a bug in your code
[07:54:00] <cehteh> (or circruit)
[07:54:05] <xoom> now its more stable when interupting power to atmega
[07:54:08] <_abc_> breadboards induce enough noise to open bjts
[07:54:20] <xoom> (added more caps to power rails)
[07:54:29] <xoom> but still seen led blinked
[07:54:44] <cehteh> 100nF as close to VCC as possible?
[07:54:49] <xoom> (im light up led together with relay)
[07:54:56] <xoom> yes
[07:54:57] <cehteh> maybe some bigger cap somewhere else
[07:55:08] <xoom> there is 100nf's all around atmega
[07:55:15] <xoom> like 2mm away
[07:55:23] <cehteh> _abc_: even if noise drive the bjt i doubt somehow that its sufficient to drive a relay
[07:55:43] <cehteh> but if, just add a pulldown
[07:55:51] <cehteh> i'd add that anyway
[07:55:59] <xoom> its not noise :)
[07:56:04] <LeoNerd> If you're picking up stray noise on the base of a BJT sufficient to drive a relay into operation, I would ask why you are running your circuit board from the inside of an MRI scanner
[07:56:06] <xoom> its just code :)
[07:56:10] <_abc_> If you use BC547/557C's like I do, for beta, you have a beta 500 transistor.
[07:56:13] <cehteh> guessed so
[07:56:14] <xoom> when interupting power to atmega
[07:56:18] <_abc_> 10uA will turn it on just fine
[07:56:30] <cehteh> _abc_: but for how long?
[07:56:33] <xoom> i use 2n2222
[07:56:43] <_abc_> oh, depends what else you are touching
[07:56:49] <_abc_> 2222 is expensive and less sensitive
[07:57:19] <xoom> but um sure its not from "outside"
[07:57:27] <xoom> its from atmega code
[07:57:33] <LeoNerd> The 2N2222 is the sort of thing everyone should have box full of. Handy for little things like this
[07:57:38] <cehteh> like i saied, comment out the code and see if it still happens
[07:57:46] <cehteh> i bet it is a bug in your code
[07:57:47] <xoom> or maybe external interrupt somehow fires up
[07:57:59] <cehteh> interrupts are disabled at boot
[07:58:04] <LeoNerd> Jellybean transistor
[07:58:11] <cehteh> there is no 'somehow' :D
[07:58:20] <cehteh> just check your code carefully
[07:58:41] <xoom> when its powered up everyting works just fine
[07:58:59] <xoom> i just want to be carefull that it not swiches on operation
[07:59:11] <vpcd> i am having trouble programming efuse on m256rfr2 chip with avrdude. i can program hfuse and lfuse just fine but efuse does not quite work as expected, i.e. it writes some bits but then the verification fails because of the reserved bit that isn't being set. efuse on rfr2 is 4 bits unused (defaults to 1), 1 bit reserved (defaults to 1) and 3 lowest bits for BODLEVEL. i try writing 0xfe (the default from the datasheet) and the verification fails be
[07:59:11] <vpcd> cause avrdude expects 0xf6... so the reserved bit seems to cause trouble but i have no idea why. if i just disable the verification the device works fine, however, other chips work fine so this is bothering me.
[07:59:21] <xoom> lets say big power device is pluged in to mains
[07:59:44] <cehteh> add some safeies, in software and hardware
[08:00:18] <cehteh> like one arming and one switching relay, using watchdog timer and other code to verify that your code executes correctly
[08:00:36] <xoom> somehow i start to thinking maybe just better is to put hardware swich to swich on/off that relay :D
[08:01:04] <cehteh> after all it will boil down on how careful you code, io's dont switch randomly
[08:01:07] <xoom> yeah watchdot is still not implemented
[08:01:32] <xoom> in normal conditions they dont :)
[08:01:37] <cehteh> but sometimes adding consistency checks will be a good idea
[08:02:11] <xoom> anyhow have another question.. more analog part :))
[08:02:13] <cehteh> like my oven controller will error out when the sensors give implausible date, or error out on some overtemperature
[08:02:23] <xoom> im readint 20bit ADC
[08:02:37] <cehteh> thats hardcoded very first in the loop before any other more fancy control
[08:03:19] <xoom> and its gnd referanced
[08:03:20] <cehteh> 20bit?
[08:03:27] <xoom> yeah
[08:03:31] <xoom> LTC2420
[08:03:35] <cehteh> for what do you need that much?
[08:03:43] <xoom> voltmeter
[08:03:52] <xoom> and current meter
[08:03:54] <cehteh> i mean i often feel 10 bit is a bit too less and do oversampling
[08:04:06] <cehteh> but 20bit sounds way too much :D
[08:04:15] <xoom> :))
[08:04:21] <cehteh> anyway you want to lowpass/oversample too
[08:04:23] <xoom> im using 16 bit of then anyway
[08:04:28] <xoom> :)
[08:04:46] <xoom> but problem is about analog part
[08:04:46] <cehteh> often 12bit are enough
[08:05:07] <xoom> as im reading 2 channels with one ADC
[08:05:13] <xoom> im using 4053 mux
[08:05:44] <xoom> and when i need to measure current and voltage i have to short out one channel
[08:06:07] <xoom> or i can measure voltage before shunt
[08:06:15] <xoom> then it should be ok
[08:06:34] <xoom> but not sure if that is proper way to measure power supply output
[08:06:50] <cehteh> anything what works is ok :D
[08:06:53] <xoom> becouse before shunt in measure not the output voltage
[08:07:03] <_abc_> <off topic> when you play with lions you get pounced on by a leopard but saved by a tiger...
http://www.dailymail.co.uk/news/article-3741288/Dramatic-moment-zookeeper-saved-charging-leopard-TIGER-comes-rescue.html
[08:07:04] <cehteh> be carefuly not to overvoltage the ADC input
[08:07:09] <xoom> like lets say at 5A
[08:07:21] <xoom> i should get 2.5V biger reading
[08:07:32] <xoom> than actuali voltage is on output
[08:07:34] <xoom> :))
[08:07:53] <cehteh> 2.5 of what?
[08:07:55] <xoom> its 0.5ohm shunt
[08:08:08] <xoom> 2.5V
[08:08:21] <xoom> volts
[08:08:23] <xoom> :))
[08:08:45] <cehteh> 0.5ohm sounds a lot
[08:08:51] <cehteh> doesnt it get hot? :D
[08:09:00] <xoom> its 15W resistor :))
[08:09:16] <cehteh> still
[08:09:29] <xoom> yeah its get bit warm :))
[08:09:36] <cehteh> 0.5 ohm may already have some impact on voltage and the load, but depends on what you put there
[08:10:05] <cehteh> either way, the voltage there should be somehow correct, but how you measure is already important
[08:10:21] <xoom> im just dont know what is proper way to measure voltage on lab power supply
[08:10:30] <cehteh> i'd add a RC filter on the ADC ... and some ways of calibration and some *good* voltage reference
[08:10:49] <xoom> vref is good :)
[08:10:53] <cehteh> my lab psu is quite exact
[08:11:10] <cehteh> eh you building a lab psu?
[08:11:18] <xoom> i done it by my self srom mastech schematics
[08:11:22] <xoom> yeah
[08:11:30] <xoom> just little bit improved
[08:11:31] <xoom> :))
[08:12:08] <cehteh> measure the voltage over the shunt with a DMM
[08:12:16] <xoom> vref is 0.005% initial acuracy
[08:12:27] <xoom> no no no :))
[08:12:28] <cehteh> if its not the same as your code shown then something is wrong
[08:12:35] <xoom> ah
[08:12:42] <xoom> you about accuracy
[08:12:46] <cehteh> and usually the shunt has 2 taps
[08:12:51] <xoom> acuracay is good
[08:13:02] <cehteh> so whats the problem?
[08:13:19] <xoom> now shunt is not the best but for testing will be ok
[08:13:33] <xoom> the problem is common ground
[08:13:36] <xoom> of adc
[08:13:53] <cehteh> you want to add some calibration too
[08:14:07] <cehteh> i'd pull that from the shunts GND side
[08:14:18] <xoom> one channel for voltage and one for current but both use same ground
[08:14:21] <cehteh> but with a 0.5Ohms resistor it hardly matters :D
[08:14:43] <cehteh> yes
[08:14:56] <xoom> so i canot measure negative values
[08:14:57] <xoom> :))
[08:15:07] <cehteh> for voltage measurement its not that critical where you tap the gnd
[08:15:26] <xoom> but its same gnd and for current
[08:15:27] <cehteh> but for current any parasitic resistance in the path will add to the shnut
[08:15:50] <xoom> yes i know that :)
[08:15:59] <cehteh> thats why shunts often have 4 terminals, 2 for power and 2 for tapping the shunt voltage
[08:16:02] <xoom> but problem is that i cant measure voltage after shunt
[08:16:14] <cehteh> you dont need that?
[08:16:56] <xoom> in schematic i allways see that voltage is measured right at output terminals
[08:17:19] <xoom> with my setup i cant do that :))
[08:17:22] <cehteh> huh?
[08:17:37] <xoom> w8 i upload imake :)
[08:17:40] <cehteh> ah i start to understand
[08:18:01] <cehteh> well of course you want measire the voltage after the shunt
[08:18:43] <xoom> http://i.imgur.com/yl97xsj.png
[08:18:57] <xoom> here is like how i can do
[08:19:14] <xoom> as voltmeters have same ground
[08:19:20] <xoom> on zero volts
[08:19:57] <xoom> but if i tap (that 9V voltmerer) to other side
[08:20:26] <xoom> i will have negative voltage
[08:20:33] <xoom> or i short out channel
[08:21:20] <xoom> need differential input :)
[08:21:54] <cehteh> just tap the voltage where you need it
[08:22:22] <xoom> and then what to do with current measurement
[08:22:33] <cehteh> or add the voltage you measure over the shunt .. bu i think thats not elegant
[08:23:10] <xoom> i have subtract
[08:23:17] <xoom> drop voltage
[08:23:18] <xoom> :)
[08:23:29] <xoom> but offcourse thats not elegant :))
[08:24:15] <xoom> need somehow to make virtual ground
[08:24:33] <xoom> or some way to measure differentialy
[08:25:18] <xoom> oh btw i used 0.5ohm shunt now becouse vref is 2.5V
[08:25:30] <xoom> and my power supply is set to max 5A
[08:25:51] <cehteh> i'd consider a hall current sensor in anything new :D
[08:25:53] <xoom> so its playes out nicely :)
[08:26:28] <xoom> yeah.. looks like its best way :))
[08:26:41] <xoom> but dont have any chips now :)
[08:27:52] <cehteh> just google a bit how other people do that
[08:28:07] <cehteh> maybe differential input
[08:29:13] <xoom> ACS712 - 6euro
[08:31:46] <xoom> ah btw you talked about RC filter on ADC input
[08:32:18] <xoom> how much C should be there? :)
[08:32:40] <xoom> and for current sensing is it any good ?;)
[08:45:58] <theBear> how much filtering do you want ?
[08:59:07] <antto> i need a 112dB bieber-reject filter
[09:04:18] <theBear> heh
[09:04:53] <theBear> that looks legitimate that name... not as fancy as linkwitz-reilly maybe, get the double-hyphen-filter name goin' on , but still looks like it's a thing
[09:05:09] <theBear> course, we probly shouldn't trust my judgement on err, msot things :)
[09:05:35] <cehteh> antto:
https://www.youtube.com/watch?v=gdx7gN1UyX0
[09:05:40] <cehteh> does it work?
[09:06:44] <antto> i'm scared to click that link :/
[09:07:38] <cehteh> xoom: you have to understand that the ADC samples in a very small time slot and does not average between this and the last sample period
[09:08:40] <theBear> https://www.youtube.com/watch?v=gdx7gN1UyX0 is my link from 5 mins ago, try that instead, no music or bieber i promise, only a short burst of insantiy nonsense in a sensible voice
[09:08:41] <cehteh> ideally your filter should be a lowpass for your sampling frequency, practically it might be enough if it is higher just enough to remove the worst spikes and noise from the signal
[09:09:50] * cehteh wonders if a active filter on a ADC input would be more proper anyway
[09:10:58] <bss36504> cehteh let me know if you have questions about Hall current sensors. I used to test them
[09:11:16] <cehteh> bss36504: xoom's problem
[09:11:30] <bss36504> oh, well xoom, let me know then haha
[09:11:33] <cehteh> well he using a shunt
[09:11:59] <bss36504> probably best if you want high accuracy. Hall current sensors are designed to reduce BOM cost and complexity, not solve an accuracy issue
[09:12:35] <bss36504> However, some are approaching the precision of a shunt over their full scale range.
[09:12:58] <bss36504> But unless you're measuring whole amps, there won't be a hall sensor for you. It's just not really possible
[09:14:16] <cehteh> yeah, but at higher currents shunts become impractical
[09:14:31] <cehteh> http://www.analog.com/designtools/en/filterwizard/ .. nice one
[09:14:33] <bss36504> Exactly
[09:15:10] <bss36504> Allegro makes a 200A bi-directional current sensor with I think 3.5% accuracy over the full scale. Good luck measuring that with a shunt with that accuracy
[09:15:26] <bss36504> But at 200mA, you're sort of out of luck with a hall sensor
[09:17:00] <cehteh> maybe a shunt is ok for him
[09:17:06] <cehteh> but 0,5Ohm sounds high
[09:17:17] <cehteh> anyway not my priblem
[09:24:53] <LeoNerd> Hall sensors are fine for answering the general question of "is there at least half an amp or so of current flowing?". Note that this is generally a yes/no question
[09:25:08] <LeoNerd> They're no good at smaller currents, and they're no good for any amount of linear accuracy
[09:25:12] <vpcd> i am doing an eeprom test on m256rfr2 and my device keeps reseting after some amount of time. if i use the whole eeprom then it will reset during the first read passthrough at the exact point every time (at 1/4 progress), if i lower the amount of eeprom used then the read goes through but then the write fails. after reset the MCUSCR tells that power on, external and brownout reset occured. i am testing this on 2 devices, first is battery powered w
[09:25:12] <vpcd> ith switching power supply at around 3.5V and another is connected to RPi 3.3V output which i presume is regulated too. i have measured the voltage during the eeprom operation and it stays constant so it boggles my mind how the brownout reset occurs... any ideas on what else to check?
[09:25:24] * LeoNerd has spent Quite Some Time looking at current sensing options lately :)
[09:26:33] <bss36504> LeoNerd: linearity is usually better than 1%
[09:27:01] <aandrew> we used CTs or LEMs depending on whether there was a possibility for DC current
[09:27:11] <aandrew> LEMs are just active hall effect devices. fast and accurate
[09:27:46] <LeoNerd> Eh. I dunno. Unless you need the isolation because of high commonmode or other odd cases, I tend to go with shunts every time
[09:28:03] <aandrew> there are some nice high side shunt "preprocessor" devices
[09:28:10] <aandrew> SOT23 etc etc
[09:28:29] <aandrew> LeoNerd: well this was industrial power control; anywhere from fractional-hp through to 22k HP :-)
[09:28:36] <aandrew> shunts would not work very well
[09:29:01] <bss36504> Right but when you're making a motor control loop for an electric vehicle with 200A peak currents, you wont be using a shunt when an integrated sensor has 150uOhm resistance.
[09:29:38] <LeoNerd> aandrew: I have been looking at high-side shunt "preprocessing" right now in fact, yes. I may have a play with the LT1999 (which is a MSOP8 or SOIC8)
[09:29:59] <LeoNerd> But yes, I'll grant the sorts of power involved in industrial control suggest that maybe a shunt isn't so appropriate
[09:30:01] <aandrew> one moment, let me find the chip I used recently
[09:41:22] <aandrew> oh, sorry I forgot I switched the chip out
[09:41:39] <aandrew> I'm using an INA3221 (triple channel shunt monitor with I2C)
[09:41:56] <LeoNerd> Ah that chip. I'm familiar with the INA219, the single-channel version of it
[09:41:57] <aandrew> I *was* looking at the tiny high side sensing ones
[09:42:13] <LeoNerd> It's certainly a cute chip
[09:42:57] <aandrew> and on this design I'm working on now (STM32, sshh, I know this is an AVR channel :-) I'm going ot use an ADC128 to watch the current sense pins of the 6 motor drivers + an overall motor supply current+voltage over I2C and let it take care of the alarming
[09:43:30] <cehteh> i didnt first know what application xoom had, for me i have RC stuff in mind .. my small quadcopter can already draw 140A, i dont want to waste that power in a shunt
[09:43:39] <cehteh> (well i dont measure current at all yet)
[09:44:03] <LeoNerd> Hrm.. 8 single-ended supply-referenced channels.
[09:44:06] <LeoNerd> "eh"
[09:44:08] <cehteh> but at over lets say 10A or maybe 20A shunts become insane
[09:45:12] <LeoNerd> tiny tiny tiny shunts. yah
[09:45:18] <LeoNerd> For that current you want a hall
[09:46:07] <cehteh> in my battery switch thing i measure current by the voltage drop over the FET which is there anyway
[09:46:33] <cehteh> i wonder if one can make a nice formula to get that accurate
[09:47:06] <aandrew> LeoNerd: eh? it's 8 signle ended inputs but not supply referenced
[09:47:19] <aandrew> it's got an internal 2.56V ref or you supply something external
[09:48:24] <LeoNerd> Oh.. I misread the summary then
[09:49:38] <aandrew> it's not super fast but it's nice as a monitoring IC. You throw a bunch of analog at it, set the limits and let it interrupt you if anythign exceeds (too high or too low), and you can always poll it if you're interested in what the values are too
[09:49:52] <aandrew> we use something simlar on a job here. AD7291
[09:49:54] <LeoNerd> Ooh, nice
[09:49:59] <LeoNerd> That part is interesting, yes
[09:50:07] <aandrew> not terribly expensive either, but not awesomesauce
[09:50:08] <LeoNerd> So it's not just for DAq
[09:50:32] <aandrew> it's acquisition and monitoring (has an interrupt line that you can use to see if it detected any value outside the programmed ranges)
[09:50:54] <LeoNerd> Nice
[09:51:01] <LeoNerd> Is the monitoring done digitally by sampling, or analog?
[09:51:09] <aandrew> sampling, unfortunately
[09:51:17] <aandrew> so it's not simultaneous/instantaneous monitoring
[09:51:29] <LeoNerd> Ah.. :/ Yeah; not sure I'd use that for safety limits
[09:51:42] <aandrew> it's "channel 1 valid range is 800-1500 counts. channel 2 is 100-900, etc. etc.) and it alerts if the latest acquisition is outside
[09:51:51] <aandrew> well, it all depends on how fast you need it
[09:52:06] <daey> well if you know your acquisition time you can just add that to the safety margin
[09:52:09] <aandrew> this is for monitoring small DC motors (3A stall, but the clutch in the gearbox gives out at ~1.5A)
[09:52:13] <aandrew> yes
[09:52:49] <aandrew> so you say "ok, it samples at 30kHz (or whatever), /8 for a single channel sample interval, my IRQ response time is x,
[09:52:55] <daey> with some math magic you can estimate whats going to happen :3
[09:53:03] <aandrew> not hard to do but if you need fast response it's probably not what you're after
[09:53:28] <aandrew> for this application the motor will shut off before you realize it's stalled. it's fast enough for humans
[09:53:50] <daey> humans are quite a lowpass filter :/
[09:55:29] <Skippy_42> This is what you usually expect after 40 minutes of coding with selfmade "formulars" without testing in between doing things you do rareley and are not used to
[09:55:35] <Skippy_42> http://www.pbh2.com/wordpress/wp-content/uploads/2013/04/funniest-simpsons-gifs-homers-barbecue.gif
[09:55:50] <Skippy_42> after the first run
[09:56:24] <Skippy_42> and 2 times per project it actually works
[10:09:01] <daey> Skippy_42: yes. but in those two cases you look at the code and dont even understand why it actually works :D
[10:25:45] <Skippy_42> true ^^
[10:26:16] <carabia> "le grill, what the hell is le grill"???
[10:26:37] <carabia> that's one of the rare episodes of the simpsons I like. :)
[10:28:16] <carabia> Well it's alright, I've felt like that for a day now trying to get an stm32 working with an sdram. Finally made it. Yay.
[10:29:31] <carabia> Turns out the "easy-to-use configuration software" (that's supposed to generate all the init code for you), didn't generate the pin configuration after all. After that, I struggled with the fucking MPU and now it's finally working woop.
[10:53:09] <Skippy_42> carabia gz ^^
[10:56:45] <carabia> Oh yeah.
[11:10:08] <vpcd> i am using the contiki os and testing the eeprom on my m256rfr2 with 8k eeprom. it takes a while to do what examples/eeprom-test does so the chip kept reseting due to supposed brownouts reported in MCUSR, but instead it was the watchdog getting mad at the long running single byte read/write loops in the test :). now i am wondering on what is the "correct" way of handling the wd reset, do i do it on the application basis or handle it in the driver
[11:10:08] <vpcd> for the general case with perhaps a timeout? it seems strange to me for this eeprom test to not reset the wd during those potentialy huge reads/writes so i reckoned it must be done in the driver but the standard contiki eeprom driver does not do it either.
[11:11:38] <vpcd> https://github.com/contiki-os/contiki/blob/master/examples/eeprom-test/eeprom-test.c
[11:12:27] <vpcd> https://github.com/contiki-os/contiki/blob/master/cpu/avr/dev/eeprom.c
[12:01:46] <Lambda_Aurigae> vpcd, An OS on an 8bit AVR is like putting 22 inch wheels on a volkswagon bug. Might look neat but,,,why?
[12:02:06] <Lambda_Aurigae> that being said, anything that takes a while to do its thing in a loop needs to do the wdt reset occasionally.
[12:02:33] <Lambda_Aurigae> or, if it's known that a particular thing will take a while, turn off WDT temporarily.
[12:02:41] <Lambda_Aurigae> all kinda depends on the implementation.
[12:03:12] <Lambda_Aurigae> not all routines are cross compatible, even within contiki or other OSs.
[12:03:29] <Lambda_Aurigae> you have to make rules to cover the exceptions and exceptions to the rules.
[12:04:32] <Lambda_Aurigae> you could also kick the watchdog timer way up to whatever the max is, like, 16 seconds or something on some chips.
[12:23:58] <vpcd> it's quite capable 8 bit AVR, with radio and all! to use this thing to its potential (IPv6) you will surely want some kind of OS, or rather the set of tools, libraries, drivers, build system, etc.
[12:24:14] <vpcd> i believe contiki is just that, it's an OS as much as you want to make it, it does not force you to do things it's way, you can use as much as you want.
[12:24:43] <vpcd> anyways, it's a good idea to turn the wdt temporarily!
[12:28:12] <vpcd> my chip has 8 sec max timeout, which is enough for most sane cases. it's just that this particular test application didn't seem to care about watchdog at all, it may as well be writen intentionally that way to test just that, but it didn't say so anywhere.
[12:29:16] <vpcd> so i guess i should leave it to the "application" that wants to use eeprom to figure out what could take a while and kick the watchdog.
[13:16:39] <carabia> at least that thing has (AMAZINGLY BIG) 32k ram
[13:17:04] <carabia> for an atmel(r)(c)(tm)-device that's like unheard of!!!
[13:34:30] <_abc_> What has 32k ram?
[13:34:49] <_abc_> m256rfr2 ?
[13:36:07] <bss36504> _abc_:
http://www.atmel.com/devices/ATMEGA2564RFR2.aspx?tab=parameters
[13:36:24] <_abc_> 2564 is quite expensive, no?
[13:37:32] <_abc_> https://techxplore.com/news/2016-08-disk-hackers-transmit-covertly-air-gap.html does this explain the MEEP my hdd sometimes emits?
[13:40:24] <carabia> I would imagine that chip is ridiculously expensive
[13:42:18] <carabia> $8.85 for one off digikey, so basically you can get this chip for cheaper than 1284s and have double the flash and ram, hahaha
[13:42:31] <carabia> well actually no. but the price diff. is around $.4
[13:43:43] <carabia> and you can run this chip (apparently) at 16 MHz in-spec at 3.3 V
[13:44:13] <carabia> Oh atmel's so fucked up with their atmegas... and xmegas... and just about everything.
[13:45:55] <_abc_> $8.85 is way too much ;) ESP8266 module is less, complete.
[13:46:04] <_abc_> It only has 20kBytes of ram but...
[13:49:03] <carabia> actually I just checked the price for the picopower 1284. Maybe the normal one is cheaper, maybe a dollar. But still, this pricing schema is so fucked up. No wonder they were borderline bust and got bought.
[13:51:19] <_abc_> :)
[13:53:10] <Skippy_42> I would pay more if it wouldn't kill half the environment
[13:53:39] <carabia> huh?
[13:54:05] <carabia> jesus f. christ you can build cheaper mcus off discrete transistors than this god damn
[14:11:56] <bss36504> It's like 4.50 in quantity. It also has a radio in it. What were you expecting for cost?
[14:14:06] <bss36504> It also has a more sensitive receiver than the ESP8266, and uses significantly less power. Like 10x less power.
[14:14:19] <bss36504> they are different beasts for different applications.
[14:32:12] <carabia> Okay, to get real, it's ~$5 _in qty_
[14:32:17] <carabia> qty being 4000
[14:32:21] <carabia> quite a production run.
[14:38:07] <carabia> I'm not sure if power efficiency is needed when you are doing something with Wi-Fi. Usually wi-fi availability means availability of mains, also.
[14:40:21] <carabia> well, not always but if it's a simple mcu with wi-fi then it's most likely used as some kind of an iot-sensor-whatever-thingamabob. Which usually means it'll be installed somewhere and not meant to be carried around, no?
[14:41:29] <carabia> and then again if you want a low-range wireless sensor that's power efficient, i guess you should go for btle (nordic has nice chips with cm0+s in them)
[14:42:02] <carabia> (and ANT+)
[15:31:57] <bss36504> All I'm saying is the 256rfr2 is not a wifi chip, it's an IoT mesh networking chip and to compare it to an ESP is dumb, apples and oranges. And I think $5 for a potentially battery powered mesh device is fair, because efficiency IS a priority
[15:33:12] <carabia> And how so?
[15:33:31] <carabia> and as said, $5 in batches of 4k
[15:33:51] <bss36504> Well yeah, but 4K isn't really that many units
[15:33:55] <bss36504> How so what?
[15:34:14] <bss36504> I mean, phillips is gonna make a helluva lot more than 4K hue devices.
[15:34:27] <carabia> philips is philips.
[15:34:28] <bss36504> (i dont think they use this chip, but same application)
[15:34:35] <carabia> why does power efficiency matter?
[15:34:42] <bss36504> lol wut?
[15:35:52] <bss36504> What do you mean? It might not be important to YOU, or even me most of the time, but for remote battery operated devices, it's very important.
[15:36:07] <bss36504> Also, designing things efficiently is a good approach, no matter what.
[15:36:19] <carabia> I do realize these points aswell
[15:36:38] <bss36504> Otherwise you'd have the same problem in electronics that you have with software; where the designer just says "fuck it, i have unlimited resources so I don't care if it's efficient"
[15:36:49] <bss36504> [virtually] unlimited*
[15:36:56] <carabia> However, what all kinds of wi-fi networked IoT-devices you have that are mainly built to run on batteries?
[15:37:34] <bss36504> Well, personally I have none, because I don't give a f*** about iot yet, until I can do something cooler than turn on my lights with my phone
[15:38:03] <carabia> Well yeah, my poor choice for words. I meant what can you think of. It's not a rhetorical question, I'm merely thinking on learning something here.
[15:39:20] <bss36504> Oh, well I know that there is some demand for sensor platforms. Maybe not like 4k volume demand, but still. If you could make some passive air quality sensor that could live in an air duct for the same interval as a filter change, that would be an example of a necessarily low power, low cost IoT device
[15:39:55] <bss36504> It would be more expensive to wire all such sensors into mains compared to just swapping some batteries when you change the filters
[15:40:15] <bss36504> Or zone controlling thermostats, many of which are already wireless and battery operated
[15:40:47] <carabia> Though I'm sure such a device would be sleeping most of the time.
[15:40:49] <bss36504> A lot of this IoT crap doesn't make sense for normal people, IMO. But in a large commercial or industrial building, I think it could be helpful
[15:40:57] <carabia> Could be, yeah.
[15:40:57] <bss36504> Yeah true
[15:41:14] <bss36504> but you will burn through a CR2032 pretty quickly at ESP active currents
[15:41:23] <bss36504> or even a small LiPo
[15:41:44] <bss36504> The ESP draws 143mA in it's lowest power transmitting function, according to the datasheet
[15:42:42] <carabia> Alright. I understand you quickly pulled this application off the hat, and that it's not thoroughly thought and so on -- but as a pragmatist my mind races straight to thinking on what kind of signal would you expect to achieve in the ducts
[15:43:14] <bss36504> And, since the whole point of IoT is to make stuff/processes better, consider the air duct example again, how about instead of switching the filters on a schedule, you just monitor the air quality and switch when the filters are *actually* bad
[15:43:19] <bss36504> lol
[15:43:21] <bss36504> I realize that
[15:43:26] <bss36504> however, it's still workable
[15:43:29] <carabia> Yes, that would be cost-efficient
[15:43:40] <carabia> well, workable, perhaps.
[15:44:48] <bss36504> Ok, to flesh this idea out more, filters are a fixed budgetary item in most facilites because they get replaced on a schedule. If you could place one $10 air sensor for every zone, and only replace filters when needed in that zone, I imagine you would have a savings.
[15:45:08] <bss36504> lets just say a zone has n air filters
[15:45:08] <carabia> but, you can achieve similar-power characteristics with cheaper devices running arms, which makes the implementation more universal and not vendor-specific
[15:45:20] <carabia> you could - for example, use BT
[15:45:23] <bss36504> Oh, well that's an entirely different argument
[15:45:27] <bss36504> the arm one i mean
[15:45:44] <carabia> indeed, but I was not trying to emphasize that, it's merely an added bonus
[15:46:10] <bss36504> Also, the BT mesh spec isn't done yet AFAIK so it's not really ready for primetime in the IoT mesh space
[15:46:40] <carabia> yes, you would need bridging. But I think you would need hotspots in any case if you'd throw the sensors in ducts
[15:50:55] <bss36504> What if the sensors were just *near* the duct, but below the drop ceiling?
[15:52:48] <carabia> That would be a solution, and it would be applicable to an open space. Such as an assembly line or the likes.
[15:53:27] <carabia> Or whatever factory, which was the point I guess.
[15:53:39] <bss36504> Yeah, and honestly, most air filters are flush with the vent, so realistically you'd want your sensor somewhere after the filter, ie outside the duct
[15:54:04] <carabia> But I still think you'd want to drive down the cost of the hardware, there are cheaper solutions (and in qty a lot cheaper solutions) than that.
[15:54:04] <bss36504> Another application would be asset beacons.
[15:54:26] <bss36504> Yes, I agree there are much cheaper RF chips, but the Atmel one might have other desirable traits
[15:54:50] <carabia> the only real trait I believe is the rather large amount of I/O, I think
[15:54:58] <bss36504> I honestly don't know how it compares to other's chips in terms of TX/RX power/sensitivity, or power consumption
[15:55:05] <bss36504> others in it's class, that is
[15:55:52] <carabia> Well i guess its class would be the 8051s with wi-fi :)
[15:56:33] <carabia> and then there's arm modules with wi-fi, and then separate ones. I guess those are really your choices
[15:57:01] <bss36504> I'm looking at ti's proprietary 2.4G stuff now.
[15:57:16] <carabia> proprietary?
[15:57:24] <learath> why would you do that?
[15:57:41] <bss36504> No particular reason. I can look at their zigbee stuff to
[15:58:02] <carabia> mmm, that's some $$$ too
[15:58:07] <learath> (full disclosure: I don't like propritary protocols)
[16:13:59] <bss36504> Well, (and I'm not cherry picking, just haven't checked others yet) TI CC2545 has worse active transmit power and costs $5.19 compared to the atmel. 8051 core still though
[16:16:12] <carabia> quick glance, 26-30 mA tx, $2.2 in 2500 qty off digikey
[16:16:25] <bss36504> On the other hand, TI CC2630 (marketed as "Ultra-low power, also Zigbee compatible) has comparable price @ 2500 units, and a slightly lower active transmit power
[16:16:58] <bss36504> Yeah, I mis-quoted the price on the CC2545
[16:18:02] <bss36504> So for half the cost, you can have CC2545, but it used 2x the current of the 256rfr2
[16:18:46] <carabia> the 2630 is cheaper in qty though.
[16:20:08] <carabia> by about $1.5 per unit in 3k vs atmel 4k, but digikey has quite a long lead time for it though.
[16:20:29] <carabia> well, so they do for the atmel aswell.
[16:21:06] <bss36504> Yes, agreed. The 256rfr2 is $4.94 @ 4k, the CC2630 is $4.09 @ 2500, $3.93 @ 6250
[16:21:50] <bss36504> And I would say those are fairly well matched in capability, however the CC2360 offers a cortex M3, which is pretty dope
[16:22:55] <bss36504> But, one thing we can learn is that the pricing from atmel is not completely out to lunch, IMO. There might yet be more factors like supply availability, custom deals (when you order enough to attract sales attention) etc. Both are reasonable products, and the RF component is likely why they are so expensive.
[16:25:02] <carabia> Hmh, it's still an 8-bit avr vs a 32-bit arm.
[16:25:22] <bss36504> Yeah, I know :)
[16:25:47] <carabia> So yeah, I do believe it's slightly "out to lunch" :)
[16:25:59] <bss36504> Technically, the CC2360 is better in price, power and processor. But there's other factors to consider.
[16:26:30] <bss36504> If the company choosing them is already an Atmel shop (or 8051), might be worth while to go with them
[16:26:42] <bss36504> But if you're already doing TI development, then it's a no brainer
[16:27:55] <carabia> *ARM development
[16:28:08] <bss36504> sure sure :P
[16:30:28] <carabia> I'm just having a really hard time associating avrs with bigger players. Sorts of players who would be doing 4k-and-over production runs.
[16:31:39] <bss36504> Oh just wait a bit and arduino will make something lol
[16:31:40] <carabia> I might be wrong here, but I think more developers are familiar with CMSIS than with AVRs. Correct me if I'm wrong
[16:31:47] <bss36504> Probably
[16:32:25] <carabia> Well arduino sure, but I'm having even a harder time associating them with anything legit bigger haha
[16:33:22] <carabia> Isn't there like an arduino cm0+ out or something? I can't even begin to imagine what kind of a clusterfuck framework they have built around it :)
[16:34:30] <bss36504> Yeah I was kidding about that. Arduino is a joke
[16:34:44] <bss36504> I think they did make a something based on the SAM D21 though
[16:34:46] <carabia> (and i'm guessing that cm0+ is atmel-branded, they were trying their darnest to CPR them!)
[16:35:01] <carabia> Yeah, that
[16:35:03] <bss36504> Arduino Zero
[16:36:29] <carabia> Heh. The framework is probably built on top of atmel's framework which makes it a doubly-so clusterfuck
[16:36:52] <bss36504> Don't shoot me, but I think ASF isn't so bad now
[16:37:22] <bss36504> Then again, it might be because I'm using an Xmega now which has better ASF support, but still
[16:38:40] <carabia> I don't know. I remember trying to find this and trying to find that, and when you finally found it, the documentation to use the actual components was more-or-less lacking. But that's um, years ago.
[16:38:59] <carabia> two, three? I'm not even sure. Time goes by so quickly.
[16:40:52] <bss36504> It has definitely gotten better. I agree, two years ago was garbage but now it's not bad. It needs some help for certain APIs but overall, it's not bad. The Atmel Studio integration is nice; you just select what libs you want to use, and it manages the dependent libs as well. Most APIs have an example you can use. I got the Xmega DAC running in abo
[16:40:52] <bss36504> ut 10 minutes once I imported the library through ASF manager, and read the Xplained example
[16:41:06] <bss36504> And, you could use it without Atmel Studio too
[16:41:50] <carabia> Hmm? Exporting libs to X?
[16:42:22] <bss36504> What do you mean?
[16:42:47] <carabia> Using it without atmel studio, so you can export libs and it handles dependencies?
[16:42:58] <carabia> i.e. when exporting.
[16:43:02] <bss36504> Oh, no I don't think so
[16:43:17] <bss36504> I think the dependency management is baked into Studio
[16:43:20] <bss36504> could be wrong though
[16:43:29] <carabia> Alright, well not needed anyway I guess.
[16:43:41] <carabia> Defo sounds way better than what it was.
[16:45:21] <bss36504> I usually write my own stuff, but I figured i'd give it a new chance for this project. So far so good. The Xmega is fucking weird though with how it manages special functions on pins. Maybe it's the same for SAM as well. You gotta write to an IO config register as well as configure the peripheral just to get the signals out. Eg. to get the ACOUT to
[16:45:21] <bss36504> work for the analog comparator. Set up the AC to output that signal, then set up the IOMUX to mux that signal to one of many IO pins.
[16:45:24] <carabia> I mean, even when ASF was more or less broken, AS was still a selling point for them. For ARM-development too. It's a nice all-in-one implementation, and it's free.
[16:45:44] <bss36504> yeah, agreed
[16:45:57] <bss36504> and largely the libraries are the same as always, just with better ASF integration
[16:46:25] <bss36504> I like the new-ish data structure approach to writing peripheral configurations.
[16:46:36] <carabia> yeah, the libs themselves weren't that all that bad. And you mostly use them to get to know the implementation and then roll your own
[16:47:10] <carabia> yesh, with arms that's quite the norm 'roundabout.
[16:47:33] <carabia> you pass the structs into a function that writes the registers, makes it clean.
[16:47:39] <bss36504> Exactly.
[16:47:51] <bss36504> I like it a lot. Just takes a shitload more work for the librarian to setup
[16:48:01] <bss36504> Though they may have automated it internally
[16:48:09] <carabia> Probably
[16:48:57] <carabia> And bss36504 that's pretty much what SAM (and other ARMs) have. The way you described setting up peripherals.
[16:49:27] <bss36504> Yeah. Seems as though the way it works for Megas was the "Old way".
[16:51:04] <carabia> That's why the structs make it _much_ more cleaner. Also I like how arms have both pullups, downs, and even opendrain outputs
[16:51:21] <carabia> I think the XMEGA has too.
[16:51:47] <carabia> (if i recall correct)
[16:52:18] <carabia> And the way you can mux them is very nice. Makes it flexible.
[16:52:56] <carabia> well no, what the fuck am i rambling. nevermind that.
[16:54:25] <carabia> hahaha. Fuck me I'm tired
[17:03:35] <bss36504> haha it's about time for me to leave work. I'm tuckered out too
[17:05:20] <carabia> I feel like caffeine is a bitch. When it wears out you're dying.
[17:06:11] <bss36504> Haha, best decision of my adult life is to avoid the coffee addiction. The most caffeine I get is from an occassional cup of tea
[17:07:08] <carabia> That would be a blessing. I just can't function without coffee. Nor nicotine. I'm always trying to drop both when I'm on a vacation, but the vacation always seems too short.
[17:07:52] <bss36504> Ok, caffeine was my second best decision, avoiding nicotine was the first ;)
[17:08:00] <carabia> I simply can't focus. It's not so much as to craving for a coffee or cigarette, it's more like just not being able to focus thoughts. This is a real bitch when you're trying to do problem-solving.
[17:08:14] <bss36504> yeah, that's tough.
[17:08:30] <bss36504> Have you tried weaning yourself off one, then the other?
[17:08:41] <bss36504> I imagine cold-turkey quit on both would be miserable
[17:09:10] <bss36504> I'd say drop the smokes first, that shit will kill you faster than a few coffees
[17:09:13] <carabia> I guess I could try just dropping nicotine for starters. I feel like coffee helps me focus more.
[17:10:02] <carabia> It'll have to wait 'til the holidays though :(
[17:12:22] <carabia> But anyway, I guess you're heading off. Was good talking to you, broadened my horizons. Thanks and catch ya later!
[17:12:50] <bss36504> Yes indeed! i'm usually around while at work.
