Back
[02:41:30] <rue_house> hmm
[03:57:52] <julius> hi
[03:58:00] <julius> what up
[04:05:02] <NicoHood> If i use a naked interrupt for pin change for example, how much overhead will it take until the assembler code runs inside (assuming i do not need to push registers)? will it be zero overhead then, that is only there when you code in c or will it still take some time?
[04:08:27] <rue_house> C takes longer, cause it has to save ALL the registers,
[04:08:43] <rue_house> the start of the irq takes 1-2 cycles
[04:08:58] <NicoHood> that is pretty good, as i want to code in inline assembler
[04:09:10] <NicoHood> i need to safe at least r0 and r1, right?
[04:09:26] <rue_house> save what you modify
[04:09:48] <NicoHood> i will try to use GPIORs for my purpose. this way i do not need to reserve registers
[04:10:55] <theBear> i always stick a maple leaf over my interrupts, out of decency and mutual respect
[04:11:21] <theBear> naked interrupts are for hunter+gatherers, you know, deepest darkest african jungle kinda business
[04:12:09] * rue_house whispers to theBear that, that leaf isn't maple, its canibus...
[04:14:25] <theBear> hey man, they're all gods err, not-quite-creatures.... just so long as they cover those poor naked interrupts, imagine, running around the forest with all your parts just swinging in the wind, probly followed up by putting a small tree thru your lip and eating one of your associates or somethign ! as soon as one small thread like naked interrupts comes loose, the decency of the whole society is destablised and all it takes is someone to trip on the
[04:14:26] <theBear> thread and it all unravels in moments ~!
[04:14:55] <theBear> trust me buddeh, i've seen it happen countless times before....
[04:15:34] <rue_house> theBear, hows about a youtube video for you before I crash for the night?
[04:22:16] <rue_house> 76% uploaded...
[04:22:53] <rue_house> it was AMAZING this worked as well as it did, the odds of anything going right in any part of its process are only about 30%
[04:23:13] <rue_house> there are about 4 processes each cycle
[04:24:20] <rue_house> https://youtu.be/j4uz_yha9uI
[04:46:54] <theBear> ffs, i'll watch that if imgur will do my upload of 3 images
[05:57:41] <antto> 7 naked interrupts in one place
[05:57:45] <antto> nude party?
[05:59:11] <antto> theBear your login session may have expired, then it won't tell you, but the upload will not finish.. ever
[06:03:19] <ehsanv> hi, in avr-gcc, i have an PROGMEM array lib[] PROGMEM = {string1,string2,string3} and i want to read bytes from strings, i don't know how!!
[06:03:24] <ehsanv> please help me
[06:04:08] <ehsanv> strings are also defined as const PROGMEM
[06:17:30] <antto> how bout lib[i] ?
[06:17:48] <antto> or is it not multi-dimensional?
[06:55:59] <ehsanv> antto: confusing
[06:57:30] <Lambda_Aurigae> ehsanv, have you read the avr-libc section on progmem?
[06:58:34] <Lambda_Aurigae> or the atmel site on it.
[06:58:36] <Lambda_Aurigae> http://www.atmel.com/webdoc/AVRLibcReferenceManual/pgmspace_1pgmspace_data.html
[06:59:06] <Lambda_Aurigae> http://www.atmel.com/webdoc/AVRLibcReferenceManual/pgmspace_1pgmspace_strings.html
[06:59:36] <ehsanv> Lambda_Aurigae: yes, but it didn't say how to get byte by byte from strings(thats what i need) and it only give a strcpy_P example
[06:59:46] <ehsanv> Lambda_Aurigae: finally i figure it out!
[07:00:51] <ehsanv> pgm_read_byte(&lib[3]) return last character of lib[2], for first character i should use pgm_read_byte(&lib[3]+1) and so on...
[07:01:23] <ehsanv> is this a bug or it should be like this or i use it wrong?!?
[07:04:58] <ehsanv> Lambda_Aurigae: your first links looks good, but only for multidimensional arrays, but my strings are not same size, so you can't use this method
[07:05:05] <ehsanv> *i can't use this method
[07:07:09] <Lambda_Aurigae> http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
[07:08:54] <Lambda_Aurigae> hmmm
[07:09:06] <Lambda_Aurigae> not seeing a mid function
[07:09:50] <Lambda_Aurigae> odd
[07:11:05] <Lambda_Aurigae> at this point I would grab the whole string then grab what I needed out of it with standard string functionality.
[07:11:19] <Lambda_Aurigae> but that's just me being lazy.
[07:11:57] <ehsanv> Lambda_Aurigae: my strings are not strings actually, they are fonts, sadly i cant load them to RAM, :(
[07:12:00] <Lambda_Aurigae> I suspect that might be faster than reading byte by byte from string in program memory too...but I could be wrong.
[07:13:09] <Lambda_Aurigae> so, perhaps your pgm_read_byte method is best if it works and just know the offset is different for string.
[08:51:45] <kre10s_> why does power down require more power than power save mode?
[11:51:24] <phinxy> in I2C, ive tried two different libraries. On one the ACK seems to have more to it, the SDA goes up before slave pulls it down while on the other librariy SDL stays low all the time. Its still recognized as ACK. is this "removal of ACK spike" ??
[13:25:06] <Emil> Hmm
[13:25:35] <Emil> Would you happen to know if the usb charging circuits care if I generate the voltage to the data pins with pwm?
[13:29:56] <liwakura> Emil: i don't think you will be able to generate a PWM signal fast enough to be like, "constant" for an USB device
[13:30:09] <liwakura> the AVR's are just to slow for this
[13:31:01] <liwakura> also, image how your programs would handle a PWM signal on, for example, the analog comparator
[13:31:12] <Emil> liwakura: eh?
[13:31:37] <Emil> You do know how a low pass filter works
[13:31:40] <Emil> right?
[13:31:57] <liwakura> are there any low pass filters in there?
[13:35:00] <liwakura> how would the data pass through then?
[13:35:07] <Emil> ...
[13:35:18] <Emil> No data moves, it is a usb charging circuit
[13:35:42] <liwakura> then you would have to do the low-pass filter by yourself
[13:35:59] <Emil> I know?
[13:36:03] <liwakura> but then you are not giving PWM to the data pins
[13:36:07] <Emil> ......
[13:36:23] <liwakura> i see, you were just talking about the generation.
[13:36:52] <liwakura> you should have made clear that you implied a low-pass filter.
[13:37:10] <Emil> I'm curious if the chargers/phone only care about voltage levels
[13:39:34] <liwakura> probably they dont care at all since you are the one having to get the speed right
[13:39:44] <liwakura> if you are on the USB host side
[13:39:56] <Emil> I'm on the charger side
[13:40:34] <Emil> at #stm32 a person said that they might do some sort of lousy impedance check, do you have an idea what kind of test that would be?
[13:40:52] <liwakura> the thing is
[13:40:58] <Emil> #electronics, sorry
[13:41:01] <liwakura> that absolutely depends on the device you plug in
[13:41:15] <Emil> liwakura: true, but they are mostly standard
[13:41:24] <Emil> they don't go around inventing the weel
[13:41:39] <Emil> reinventing*
[13:41:41] <liwakura> then, why do you need to adjust your data line voltage levels?
[13:41:50] <liwakura> afaik hosts dont need to do that
[13:41:53] <Emil> ...
[13:42:17] <liwakura> just hard-wire the standart 15K pull-down
[13:42:24] <liwakura> *standard
[13:42:44] <Emil> again, I'm on the charger side and because. And second of all, while they all use voltage dividers their voltages vary
[13:42:54] <Emil> so what would work on Samsung wouldn't work on Apple
[13:42:56] <liwakura> "their" ?
[13:43:22] <Emil> the chargers'
[13:43:38] <Emil> Apple has different voltage dividers compared to Samsung
[13:43:44] <Emil> and ideally I'd like to support both
[13:45:05] <Emil> No, this is not a commercial product
[13:45:30] <liwakura> Both seem really far off the standarts
[13:45:31] <Emil> Just a diy powerbank. But people do borrow other people's chargers/powerbanks
[13:45:34] <liwakura> *stnadards
[13:45:49] <liwakura> fuck grammar today.
[13:46:18] <liwakura> Emil: make a Samsung vs Apple switch :D
[13:46:39] <liwakura> you could also just short some resistor using an transistor, that would seem much more secure to me
[13:47:01] <Emil> liwakura: That's the idea. But with pwm I could change it to whatever I want easily
[13:47:20] <Emil> -> would support any required voltage levels
[13:47:32] <Emil> now and in the future (as long as they are within 5V)
[13:48:26] <liwakura> mh.
[13:48:54] <liwakura> i would, passive agressively, just do the 15K host resistors
[13:49:03] <liwakura> and just accept the slower charging speeds
[13:49:22] <liwakura> just try it.
[13:50:35] <Emil> liwakura: nooooooooo
[13:51:08] <Emil> liwakura: :D That's loser talk. I have to bang my head on this for at least two more weeks before, in shame, giving up quietly
[13:51:42] <liwakura> "Wrapping your tech around the non-standard behavior of other devices"
[13:52:03] <liwakura> this is how we effectively broke transfer-encoding for http
[13:52:23] <Emil> liwakura: tell me more about that
[13:52:29] <Emil> Never heard of it
[13:52:54] <liwakura> Emil: look up the meaning of the "Content-Encoding" and "Transfer-Encoding" headers of the HTTP Protocol
[13:53:09] <liwakura> And how they are used.
[13:53:43] <Emil> chunked transfer encoding?
[13:54:05] <liwakura> Lets take gzip encoding, because its quite common.
[13:54:21] <Emil> sure
[13:54:41] <liwakura> Content-Encoding says something like, "im a gzip-encoded file!"
[13:54:56] <liwakura> Transfer-Encoding says "This data is transferred gzipped"
[13:55:29] <liwakura> the first one is an attribute of the transmitted file (syslog.1.gz)
[13:55:39] <liwakura> the other one is just some transmission thing
[13:55:51] <carabia> Does anyone know of a cheap dual digital pot with a simple interface
[13:56:05] <carabia> non-spi pref. even i2c would do
[13:56:16] <carabia> or anything simpler than that.
[13:56:26] <Emil> carabia: eh, why don't you like spi? SPi is awesome
[13:56:33] <Emil> and spi is the simplest
[13:56:43] <Emil> liwakura: okay, so umm,
[13:56:44] <carabia> no, it's not
[13:56:55] <liwakura> Emil: since devs did not understand the difference, "Content-Encoding" is used everywhere, breaking every HTTP feature relying on the difference.
[13:57:32] <carabia> Emil: Dallas has a dual digit. pot with a super simple interface that allows you to actually just use push buttons, last I checked here locally they go for €10+
[13:57:40] <carabia> so that's out of the question
[13:57:50] <Emil> liwakura: okay, so, content encoding is just encoding parts of the datastream differently, right?
[13:58:02] <Emil> And transmission encoding is encoding the datastream (or huge chunks of it)
[13:58:33] <Emil> carabia: depends on what you mean simplest.
[13:58:46] <Emil> Parallel data line is simple, yes, but takes a fuckton of pins
[13:58:57] <carabia> Emil: stop fucking around.
[13:59:01] <Emil> carabia: what
[13:59:08] <Emil> Please calm your tits
[13:59:10] <liwakura> Emil: its just the differantiation of if the encoding is a metadata of the file (like tar.gz), or just temporary for transmission
[14:00:03] <liwakura> the thing is, if you have different Content-Encoding, you have a different file.
[14:00:19] <liwakura> If you have different Transfer-Encoding, its the same file, just encoded differently.
[14:00:26] <Emil> carabia: of the serial standards, spi is the simplest. I2C is also a serial standard but requires additional logic to implement nicely. You can't just shift bytes out
[14:00:27] <carabia> That. Exactly. I'm not too fond of people who get stuck with the semantics.
[14:00:38] <liwakura> You must be able to determine the "same file" thing for caching (ETag)
[14:00:40] <carabia> Emil: I'm aware.
[14:00:56] <Emil> carabia: fuck off, then. Semantics is really important.
[14:01:00] <carabia> I clearly stated non-spi. To entertain you, let's forget the simple part.
[14:01:14] <carabia> Emil: bench engineering is a flavor i strongly dislike
[14:01:26] <Emil> carabia: Sure you did, but people do this idiotic thing of asking for b while wanting a
[14:01:39] <Emil> I'd like to know why you don't want to use spi
[14:01:41] <carabia> Emil: maybe you ought to drop the pretense then.
[14:01:53] <Emil> carabia: hey, I'm not the one who started being an ass
[14:01:55] <carabia> Reasons I do not want to use SPI, are irrelevant.
[14:02:09] <Emil> carabia: nope, not really
[14:02:15] <carabia> Emil: yep, really.
[14:02:25] <Emil> liwakura: but, if you encode both, say with gzip, it is not the same?
[14:02:52] <Emil> carabia: well, fuck off, then :)
[14:02:53] <liwakura> Emil: if you encode a file, it has a different Content-Encoding
[14:03:05] <liwakura> Emil: he clearly stated that he does not want to use SPI
[14:03:11] <liwakura> wtf is your problem with that
[14:03:13] <Emil> liwakura: sure he did
[14:03:14] <carabia> Emil: Yeah, Fuck you too. Another bench engineer on my ignore list.
[14:03:20] <carabia> Bye now
[14:03:22] <Emil> carabia: hey, we both win
[14:04:03] <Emil> liwakura: if I'm going to offer help I'd like to know I'm not going to spend ages troubleshooting what the guy really wants
[14:04:21] <liwakura> a 2 digit thingie without SPI ?
[14:04:22] <Emil> if the problem is clear I can offer my best advice and shut up after that
[14:04:44] <liwakura> Emil: you just questioned his preconditions
[14:04:52] <liwakura> without actually helping
[14:05:07] <carabia> liwakura: drop it, not worth it.
[14:05:35] <liwakura> carabia: and YOU have not to decide what I deem worth and what not
[14:05:47] <Emil> liwakura: "hey I need a hammer!" "What for?" "To cut that plank in half!" "Wouldn't you like to use a saw for that?" "NO FUCK YOU I WANT A HAMMER IT WILL BE AWESOME"
[14:05:50] <Emil> And so on
[14:05:57] <carabia> that's very true also
[14:06:26] <liwakura> Emil: yeah? If people just want to hammer things, that would be perfectly valid
[14:06:39] <Emil> liwakura: so, I hope you see why asking a few preliminary questions will help determining if they are worth my help or not
[14:06:48] <liwakura> "worth my help"
[14:06:48] <Emil> liwakura: sure, but I don't want to be part of that idiocy
[14:07:03] <liwakura> Emil: you are just an arrogant prick
[14:07:16] <liwakura> even more than i am.
[14:07:26] <Emil> liwakura: lol, and how do you justify that?
[14:08:31] <Emil> liwakura: I have not heard a bit of logic to support that claim. Mine is simple: 1) A person asks for help 2) I ask what is it for 3) the person explains and I offer help or the person doesn't and I don't have to talk to the guy again
[14:08:47] <carabia> I cannot use an spi-pot, because I have another device on the bus that's sensitive to the clock line. I might have to trim the pot in the middle of an operation to said device, and simply clocking out would corrupt said device's comms.
[14:09:07] <carabia> And yes, it's sensitive to the clock line even when chip select gets disabled. I have tried.
[14:09:30] <liwakura> Emil: THERE you have your perfectly valid reason.
[14:09:35] <Emil> carabia: thank you.
[14:09:38] <carabia> What I could do is, I could hack to disable the clock line to the device with a transistor
[14:09:46] <carabia> But that's just a really fucking hacky solution.
[14:10:04] <liwakura> Emil: congrats about being an ass for no reason.
[14:10:12] <Emil> carabia: I suppose you do have an additional twi pin then because twi obviously also has a clockline
[14:10:21] <Emil> liwakura: hey, still have not heard any justifications from you
[14:10:28] <carabia> TWI clock is not shared with the SPI clock line.
[14:10:33] <liwakura> Emil: just read your scrollback.
[14:10:38] <Emil> carabia: that was the point
[14:11:24] <liwakura> Emil: im in no way responsible to fix your bad behavior, but i really enjoy bitching to you about it.
[14:11:54] <Emil> liwakura: lol. You say my behaviour is bad. You are free to look at the logs but I suppose you are only interested in being hurt and a dick
[14:11:55] <carabia> Emil: it would be roundabout the same as bitbanging the clock then.
[14:12:10] <liwakura> Emil: im open about being an asshole.
[14:12:20] <Emil> carabia: sorry, meant additional i2c pins
[14:12:22] <carabia> I could do it. Just hacky. That, and also I find a serial bus overkill for a digital pot.
[14:12:28] <Emil> carabia: check AD5171
[14:12:30] <carabia> Emil: yeah, I do. They are not shared either
[14:12:38] <Emil> carabia: which was the point ; )
[14:12:53] <Emil> ebay show's them at 1.65€
[14:12:54] <kre10s_> liwakura, an open asshole... the smelliest kind.
[14:12:59] <kre10s_> :P
[14:13:25] <Emil> carabia:
http://www.ebay.com/itm/191770862832
[14:13:30] <liwakura> kre10s_: was that necessary?
[14:13:38] <Emil> ohshit, dat shipping cost, though
[14:13:57] <liwakura> I just cant stand people who spout "idiocy" because they do not understand or know something
[14:14:40] <Emil> liwakura: I just can't stand people who want to get hurt for feeling hurt's sake
[14:15:04] <liwakura> you mean "offended"
[14:15:15] <Emil> http://www.pixteller.com/pdata/t/l-194039.jpg
[14:15:19] <Emil> There you go
[14:15:40] <Emil> carabia:
http://www.mouser.fi/Analog-Devices-Inc/Semiconductors/Digital-Potentiometer-ICs/AD5171-Series/_/N-4c498?P=1yxyv6rZ1yyh4l4
[14:16:53] <liwakura> Emil: i'd like to note that you two wouldn't have resolved the misunderstanding if i hadn't jumped on you
[14:17:23] <liwakura> so. if you fuck up alone, its probably not my fault.
[14:17:53] <Emil> liwakura: 5/7 nice way to say you are responsible for getting results here
[14:18:35] <liwakura> carabia got the idea of explaining WHY he cannot use how?
[14:18:45] <liwakura> *why he cannot use SPI how?
[14:18:54] <liwakura> so now shut up.
[14:19:18] <Emil> because he realized he will get (better) results by just explaining the issue he is facing
[14:19:30] <Emil> Not because you wanted to be an ass
[14:19:42] <liwakura> because we both we were talking about that problem!
[14:20:01] <liwakura> and he was reading it
[14:20:10] <carabia> Emil: no.
[14:20:22] <Emil> liwakura: I'm simply amazed by your way of looking at things
[14:20:27] <carabia> Emil: It was simply a matter of what I believe in
[14:21:02] <carabia> The common practice in the internet is to believe anyone facing problem x, is driven into it for not knowing a better way
[14:21:14] <carabia> now, i get the idea of trying to go around it, to a certain extent
[14:21:31] <carabia> in an internet forum such as irc this kind of thinking is just too pronounced
[14:21:41] <Emil> carabia: you said you'll put me into ignore but you didn't. This implies that rather than not getting results it is better to get some results and thus you saw that taking 20 seconds of your time is better than not doing that
[14:21:45] <liwakura> i think its important not being stuck to it
[14:22:16] <carabia> Emil: Actually, I more like figured I didn't come across as I should have
[14:22:32] <carabia> this, on the other hand is a question of manners
[14:23:06] <carabia> eventually, you ended up giving me an i2c-solution. Which was what I originally wanted. We could have gotten to the same result cutting the bullshittery in-between of questioning the motive for such a solution
[14:23:13] <Emil> carabia: I agree. Being friendly does get better results
[14:23:30] <Emil> carabia: but you see, I'm interested in what people do and what problems people face
[14:23:39] <carabia> I'm hanging on a mobile-network thread at this moment, which is why I wanted to save myself some googling.
[14:23:42] <Emil> and you want help
[14:23:56] <Emil> so we both exchange something
[14:24:09] <carabia> When you put it that way, it does sound better.
[14:24:43] <liwakura> :P
[14:24:51] <liwakura> you two see
[14:25:09] <liwakura> in face of an even bigger villain everyone forgets their minor issues.
[14:25:37] <liwakura> so, i had fun, carabia got help
[14:25:45] <liwakura> im done here
[14:25:57] <carabia> €2.71 in 10 qty, sounds good. Thanks.
[14:27:24] <carabia> Hmh. It's not a dual pot though. Well, I'll look into more AD-stuff as Dallas' pots seemed to be super expensive.
[14:27:38] <Emil> carabia: np, glad you found a solution. That spi clock thingy is trange though
[14:28:20] <carabia> It is, and I've verified the behaviour with an LA.
[14:28:47] <carabia> in case of a pending transmission, even when you deselect the chip it would try to send the data regardless
[14:29:19] <carabia> and i'm going to have an interrupt to trim the pot, and it could corrupt the transmission. So for this one-off, I rather leave the spi-bus as-is
[14:30:27] <Emil> la?
[14:30:32] <carabia> logic analyzer
[14:30:34] <Emil> ah
[14:30:49] <Emil> what kind of device do you control with the spi?
[14:30:55] <Emil> or what spesifically?
[14:31:01] <Emil> specifically*
[14:31:04] <carabia> now you're intereted, huh :)
[14:31:20] <Emil> carabia: yeah, because I have parts I have just bought from ebay :D
[14:31:43] <Emil> And I'd rather not no what the fuck is going on if a problem like that exists with a subset of them
[14:31:54] <Emil> s/not no/not know
[14:32:28] <Emil> Like, I have a lot of transceivers and I'd hate to waste time on trying to debug that
[14:32:33] <carabia> This is very black-ops thing, I don't think you'll have any of them :)
[14:32:40] <carabia> for the sake of the argument, it's not a transceiver
[14:32:42] <Emil> carabia: sure ; )
[14:33:07] <Emil> Did you implement the protocol yourself?
[14:33:15] <Emil> Or did you use a premade library
[14:33:16] <carabia> well, in a sense most spi-devices are transceivers... Heh.
[14:33:49] <carabia> Emil: If you mean the mcu code, yeah I implemented it myself
[14:34:31] <Emil> it's somewhat easy to miss a part of the datasheet. Like with most of the 8x8 dot led matrix drivers, it is nowhere near clear enough said that you have to send NOPs
[14:34:54] <Emil> Was stuck there until I took a look at the arduino implementation of it and realised my mistake
[14:35:30] <carabia> Emil: but this sort of case, is kind of "undefined behaviour", when datasheets are concerned
[14:35:33] <Emil> The point is that you could have missed a part of the expected packet or command and the device, badly designed as it is, still waits for that data even after giving up on slave select
[14:37:40] <carabia> Emil: yeah. I know what you mean.
[14:38:28] <Emil> When designing electronics, one might usually start with asm trees. If you enter an illegal state you really do want to define an exit from that state to avoid any mistakes
[14:38:54] <Emil> but people are lazy and go "we never get into this state!"
[14:39:10] <Emil> carabia: but yeah, good luck with resolving the issue :D
[14:41:27] <carabia> Emil: I wish I could change the device. But goalposts move, independent of me. This far in the design I really can't. These things have to ship someday, if you know what I mean.
[14:41:49] <carabia> A bit of a bitch, overall.
[14:41:56] <Emil> carabia:
http://www.ti.com/product/TPL0102-100/samplebuy
[14:42:07] <Emil> carabia: true
[14:42:30] <Emil> cheaper and dualchannel
[14:42:54] <carabia> It won't be a large batch. Talking of tens of units. And that sounds perfect, I owe an apology and thanks.
[14:43:16] <carabia> This mobile network really is killing me :)
[14:43:39] <carabia> I wrote that down, and now it's time for me to retire. Have a good one!
[14:43:50] <Emil> carabia: np, remember to keep a positive outlook ; )
[14:43:53] <Emil> see ya, man
[15:13:04] <Toffe> The idea: A "black" box for road trips / hikings. The wish: Logging GPS data every 1 minute, with a button to activate intensive logging.
[15:13:48] <Toffe> I think an Attiny85 is enough for this, but what ideas do you guys maybe have to make it less power hungry? So on long hikings i can have it .. maybe a day?
[15:18:05] <kre10s_> Toffe you can save the gps location and time of the last fix. Turn off the GPS stuff, and a minute later turn it back on, feeding it the last fix to speed up getting the next fix.
[15:18:42] <Toffe> Cool, but would the be nessesarry when i got a clock battery on it?
[15:18:47] <kre10s_> In the gps chip datasheet it will refer to it as getting a 'hot' fix.
[15:19:01] <Toffe> Think that clock batt is for hot fix?
[15:19:11] <Toffe> But thats a cool idea, never heard about that
[15:19:21] <kre10s_> which GPS chip are you using?
[15:20:08] <Toffe> https://www.adafruit.com/product/746
[15:20:24] <kre10s_> how will you be getting the data out of your black box? USB?
[15:20:42] <Toffe> got an
https://www.adafruit.com/products/254
[15:23:19] <Toffe> and Arduino Pro Mini 328
[15:26:26] <Emil> Hmm, apparently most Galaxy S-series phones follow the USB-IF BC v1.2
[15:26:34] <Emil> for DCP, CDP and SDP
[15:29:13] <kre10s_> Toffe, theres a pin on the chip called Vbackup used to keep the fix data even when the chip is off. I don't know how the adafruit board does it, but it looks like thats what the coin-cell is for.
[15:29:59] <Toffe> "a footprint for optional CR1220 coin cell to keep the RTC running and allow warm starts and a tiny bright red LED"
[15:30:12] <kre10s_> So the idea is that you do little sprints. wake up do some logging, turn everything off and deep sleep.
[15:32:00] <kre10s_> yea. but well forget the LED it draws power. also you may want to accumulate some data points in ram and only fire up the sdcard once to write a page of samples at a time.
[15:34:23] <Toffe> smart sd cards eats i heard.
[15:34:36] <Toffe> ram means eeprom? or a variable?
[15:34:49] <Toffe> (not an expert on avr)
[15:34:52] <Emil> Toffe: pls
[15:35:04] <Emil> Toffe: ram means sram, eeprom means eeprom
[15:35:28] <Toffe> Emil thanks for explaining :)
[15:36:11] <Emil> Toffe: writing to eeprom is more time consuming and takes more energy, but you are guaranteed that your data is there
[15:36:13] <kre10s_> also eeprom writes also use power.
[15:36:24] <Emil> keeping it in ram, it will only stay there as long as you have power
[15:36:46] <Toffe> yeah, so bascicly writing to sram is same as .. char msg[] = "I am in ram"
[15:37:02] <Emil> yes
[15:37:27] <Toffe> Must see how much ram i got left after i have created my sketch doh :P
[15:37:45] <Emil> but I suppoise you only want to do unsigned char data[ASMUCHASPOSSIBLE];
[15:37:54] <Emil> Toffe: program in avr c for better results
[15:38:15] <Toffe> oh no its 3 weeks til the trip and learn C in 3 weeks :P
[15:38:45] <kre10s_> you could probably do what you want with an attiny.
[15:40:09] <Toffe> hum yeah, you are right, the attiny has spi and serial
[15:40:30] <Emil> Toffe: also remember, saving frequently to eeprom will kill eeprom
[15:40:52] <Toffe> yeah =)
[15:40:53] <Emil> And jumping from "arduino code" to avr c is easy
[15:41:02] <Emil> And finally, with attiny, you don't have much time
[15:41:12] <Toffe> time?
[15:42:21] <Toffe> With attiny i need software serial too
[15:42:52] <Emil> ...
[15:42:56] <Emil> s/time/sram :D
[15:43:01] <Toffe> aah
[15:43:09] <Toffe> sram is 2k on attiny too?
[15:43:21] <Toffe> nah .. 0.5
[15:43:31] <Toffe> but thats a few readouts :P
[15:45:06] <Emil> Toffe: just use a sd card with atmega328p or atmega32u4
[15:45:09] <Emil> super simple stuff ; )
[15:45:16] <Emil> an sd card
[15:46:17] <Toffe> mm if i want a switch to turn on intensive logging i maybe should
[15:48:46] <Toffe> found a atmega238pu here ;D
[15:49:05] <Toffe> the joy xD
[15:59:39] <Tom_itx> 328?
[16:15:06] <Toffe> Tom_itx ofc typo :)
[17:46:16] <Jan-> hihi avr people
[18:21:09] <kre10s_> Will an low level interrupt on int0 fire repeatedly if I hold the line low? I see that the flag gets cleared when the ISR runs, but will it stay cleared? when will it get set again?
[18:40:52] <Lambda_Aurigae> kre10s_, set to rising edge, falling edge, or level?
[18:42:16] <Lambda_Aurigae> if you have ISCn1 and ISCn0 set to 0 then a low level will continue to generate interrupts.
[18:42:32] <kre10s_> level. It apears that on level interrupts the flag is not cleared by the ISR hardware, but simply reflects the pin level. Implying that the interrupt will fire again if interrupts are enabled.
[18:42:37] <Lambda_Aurigae> can set to any edge, falling edge, or rising edge.
[18:42:49] <Lambda_Aurigae> it's right in the datasheet.
[18:44:12] <Lambda_Aurigae> at least, it's in the atmega1284p datasheet.
[18:44:46] <kre10s_> well I'm reading "This flag is always cleared when INT1 is configured as a level interrupt" in the atmega48pb datasheet, so I was confused.
[18:45:08] <kre10s_> so... does that mean it NEVER fires?
[18:46:16] <Lambda_Aurigae> no...it means it fires and clears automatically.
[18:46:24] <Lambda_Aurigae> at least, that's how I read it.
[18:47:09] <kre10s_> that's the only thing that makes sense. But, the interrupt being a level interrupt, when is the flag set again? right after reti?
[18:47:41] <Lambda_Aurigae> soon as the interrupt handler hardware checks to see that the pin is low...which is after the next command as I read it.
[18:50:07] <kre10s_> by command you mean instruction?
[18:50:21] <Lambda_Aurigae> yes.
[18:56:39] <kre10s_> right. reti only sets the global interrupt enable bit.
