Back
[05:10:26] <raminious> hi ppl
[06:18:47] * LeoNerd ponders methods of communicating between two AVRs via ~100m of low-cost alarm cable
[06:19:09] <LeoNerd> I'm wondering about low-clockrate I2C... like... 5 to 10kHz
[06:21:44] <LeoNerd> Oh, and optoisolated
[09:00:52] <balrog-k1n> hi, i'm trying to troubleshoot a problem with an I2C slave and wonder if anyone has hit a similar issue before and would know the answer right away. Problem: as soon as the slave is connected to the bus, all communication breaks but also every attempt on the master takes a few seconds as if timing out
[09:01:33] <LeoNerd> Is the slave behaving itself, electrically?
[09:01:44] <LeoNerd> Maybe it has pulled one or other lines down mistakenly, or forcing them up?
[09:02:04] <balrog-k1n> i'm not sure how to check, but the SCL and SDA voltages on the slave read as 5V so it's not pulling them low
[09:02:34] <LeoNerd> Maybe the slave isn't open-draining them, so they're being held high too long
[09:02:45] <LeoNerd> Try attaching just one or other line, and see if the entire bus still falls over
[09:03:33] <balrog-k1n> will recheck, but it looked like even just one line connected breaks the whole bus
[09:37:51] <balrog-k1n> it was only SCL and i now know what the problem was... the pcb has the labels next to the solder pads offset by one to fit all the labels in..
[09:38:12] <LeoNerd> Hah.. ohdear
[09:39:33] <balrog-k1n> thanks for help anyway
[10:23:48] <skandix> is there anyone who have a good description on what a prescaler is and how it works
[10:25:54] <LeoNerd> (e.g.) 16 clock ticks in -> 1 clock tick out
[10:26:04] <LeoNerd> It makes the timers count slower than the real CPU clock
[10:26:30] <skandix> aha
[11:01:21] <bss36504> Hey folks, haven't been on in ages. I have a friend using a mega328 and his ADC pins are truly low impedance, which is contrary to what the datasheet says. During testing, he was directly driving the ADC pins with an adjustable power supply, which was indicating a current of 80mA. This isn't right, and I think it's contributing to his spotty results. Any thoughts?
[11:02:04] <LeoNerd> Did you remember to turn off the digital output (DDRx) and the digital input (DIDx)?
[11:04:18] <bss36504> I will ask him. I'm unfortunately not local to him at the moment so I'm just looking for suggestions. Thanks for the tip
[11:05:47] <LeoNerd> To quote my DS: When an
[11:05:48] <LeoNerd> analog signal is applied to the ADC5..0 pin and the digital input from this pin is not needed, this
[11:05:48] <LeoNerd> bit should be written logic one to reduce power consumption in the digital input buffer.
[11:05:59] <LeoNerd> (also: fuckyou PDF for hard-linebreaking)
[11:08:01] <bss36504> That's a good tip, thanks. I like to think I remember all these things but I tend to go look when I actually need the peripheral. Since I'm not working on it directly it's hard for me to debug
[11:08:22] <LeoNerd> It's often a thing one forgets
[11:08:37] <LeoNerd> I've just been doing some low-power battery-based radio work lately so it happened to be in my mind
[11:08:50] <bss36504> Yeah it's easy to overlook for sure. "Why should I touch digital to do analog stuff?"
[11:09:13] <LeoNerd> Well, it's the digital input disable register; so ... :)
[11:09:18] <bss36504> Ah that makes sense. Usually I don't care but in this case it seems like it is affecting ADC performance.
[11:10:06] <LeoNerd> It shouldn't really affect the overall result, but it might change the power requirements
[11:11:08] <bss36504> Yeah well 80ma is a tad high.
[11:11:19] <bss36504> Who knows though, he might be reading it wrong lol
[11:14:01] <bss36504> Well anyway, I need to go back to work for now. I really appreciate the help. I'd love to be back on here more. I miss chatting but my work Internet blocks IRC and doing it on my phone kind of sucks.
[11:14:45] <LeoNerd> Mmm
[11:28:26] <Crak> hi all
[11:28:40] <LeoNerd> Afternoon
[11:28:49] <Crak> learath: i solved the problem with my clock
[11:34:39] <learath> Crak: what was it?
[11:53:09] <Crak> learath: i changed the interrupt from Overflow to PCINT. now the clock is correct
[11:54:47] <learath> interesting
[12:07:47] <Crak> yes
[12:08:05] <Crak> now i try to split my code into several files
[12:08:31] <Crak> but i get errors when compiling: Error 6 ld returned 1 exit status collect2.exe 0 0 MyClockInC
[12:08:42] <Crak> do i have to config my project somehow`?
[12:08:53] <Crak> cli and sei are not found any more
[12:25:10] <Crak> ah i got it
[12:25:11] <Crak> sry
[12:52:41] <Crak> is it possible to put my ISR(PCINT2_vect) routine into a separate .c file?
[12:53:06] <LeoNerd> Sure, why not? I spread mine about the place
[12:53:26] <Crak> how does the .h file look like then?
[12:53:43] <LeoNerd> It doesn't need to know..?
[12:53:53] <Crak> ISR(PCINT2_vect); ?
[12:54:17] <Crak> so i don't have to create a .h to include into my main.c?
[12:54:24] <LeoNerd> No..?
[12:54:27] <Crak> just let the linke do?
[12:54:36] <Crak> linker
[12:54:48] <LeoNerd> You'd only add function prototypes or extern variables to the .h file if you want to tell the compiler about their existence, when you mention hem
[12:55:01] <LeoNerd> Since you're not going to be *calling* the ISR from the other .c file you've no need to tell it
[12:56:51] <Crak> LeoNerd: ah, ok. so i have to make my volatile struct {} flags extern?
[12:57:16] <LeoNerd> If you want to share that between compilation units, yes.
[12:57:27] <LeoNerd> Are you at tihs point looking more for general C questions, than AVR ones?
[12:58:06] <Crak> sry for asking
[14:07:19] <avrdude> i have a joystick that doesnt quite divide the voltage equally when in the neutral position.. how would you guys fix this?
[14:08:11] <avrdude> i can just offset the reading by how far its off its center, but then i wouldnt be able to "read" the correct endpoints.. (it goes from 0 to 1023, but centers at 519)
[14:11:34] <LeoNerd> Maybe use sign/magnitude representation? If it's < centre, use LEFT and (centre - value); if it's > centre, use RIGHT and (value - centre)
[14:53:14] <jacekowski> avrdude: joystick calibration is a quite simple thing, but you need to know few things (by measuring them or some other means), that is: center position, and both extremes position at least, or ideally a full characteristic
[14:53:41] <jacekowski> avrdude: assuming that all you have is the 3 points, then it's just a matter of scaling it correctly
[14:55:45] <jacekowski> LeoNerd: the whole idea of the fact that you have to declare function prototypes is stupid in C
[14:56:00] <jacekowski> LeoNerd: it should be handled at compile time at linking stage
[14:56:07] <jacekowski> LeoNerd: like it's handled in most languages
[14:57:01] <LeoNerd> That isn't how C works
[14:57:28] <jacekowski> that doesn't meant it's not stupid
[14:57:35] <jacekowski> mean*
[14:58:38] <jacekowski> compiler should compile functions as they come along, leaving info to a linker, that there is a function call to function foo and arguments are int, int, float and something else
[14:58:42] <LeoNerd> How long have you known C, and been using it?
[14:58:55] <jacekowski> LeoNerd: 15+ years
[14:59:04] <LeoNerd> Interesting
[15:00:27] <jacekowski> then at linking stage, all functions are already compiled and known, so linker then can do a check if all functions are there and present and arguments match and other sanity checks
[15:01:07] <LeoNerd> It is conceiveable that some implementations could do type checking at link-time. Unfortunately, the ELF binary format does not permit such information to be embedded as to allow that to happen
[15:01:09] <jacekowski> and then actually link the thing
[15:01:22] <jacekowski> i do not mean link time at runtime
[15:01:29] <jacekowski> i mean link time during compile
[15:01:45] <jacekowski> before actual ELF is produced
[15:02:12] <LeoNerd> Prettysure the intermediate .o files are also ELFs
[15:02:28] <jacekowski> yeah, but that is not a requirement
[15:03:07] <LeoNerd> Yah - maybe there are C compilers that provide some other intermediate format. I don't believe gcc does
[15:05:43] <jacekowski> there are some windows ones
[15:05:55] <jacekowski> ICC is producing ELFs
[15:06:41] <jacekowski> .net with C# and other languages and the features make life really easy
[15:07:22] <jacekowski> C was designed 40 years ago or so
[15:08:08] <jacekowski> and back then you couldn't afford to waste few kb's of memory and JIT stuff as you please
[15:08:45] <jacekowski> but compared to modern languages there is a lot that could be added/fixed in it
[15:09:08] <jacekowski> however, C11 does make huge progress when it comes to that
[15:10:15] <jacekowski> in stuff i do there is shitloads of error handling code and possibility for things to go wrong
[15:11:06] <jacekowski> and it would save me massive amounts of time if it had proper exception handling
[15:11:48] <LeoNerd> Sure; you could take lots of non-C features and add them to C - at what point would it still be C?
[15:12:06] <LeoNerd> At what point would you instead surely be better off using some other language that already had those features? :)
[15:12:27] <jacekowski> that seems to be the way i'm going
[15:12:54] <jacekowski> 5 years ago most of the stuff i did was C
[15:13:08] <jacekowski> now i would say it's more around 50%
[15:14:03] <LeoNerd> I tend only to write in C where it's required; AVRs, low-level system libraries, inner parts of programs that can't be made faster in the HLL
[15:14:40] <LeoNerd> C isn't the language for writing high-level end-user-facing applications
[15:15:22] <jacekowski> thing is now, with things like RPI and stuff or the intel arduino compatible device (whatever the name of it was)
[15:16:09] <jacekowski> extra computing power costs a lot less than extra development time
[15:17:05] <LeoNerd> I'm sure that's been true for a long time
[15:18:05] <jacekowski> when you made 1000s of devices it was cheaper to spend some extra time developing it to save some hardware costs
[15:18:11] <jacekowski> but i don't think that's the case now as well
[15:18:46] <LeoNerd> Thing is, I've spent lots of development time lately making interesting AVR-based hardware. I don't think I could attribute very much of that time to "working around shortcomings of C"
[15:19:11] <LeoNerd> I can't particularly identify specific things that I could say "Oh, if C was different, then I could have avoided that issue"
[15:19:40] <jacekowski> for me it's pretty much a once per day "i wish i could just throw an exception here"
[15:20:02] <malinus> I remember when I thought I knew C, but then had to make a bigger (multiple files) project in it. Haha
[15:20:04] <LeoNerd> Hmm.. I'm not sure I'd like the sound of that on my 'tiny84 :)
[15:20:17] <LeoNerd> I don't know where I'd throw an exception *to*, or what would catch it
[15:20:34] <jacekowski> LeoNerd: yeah
[15:20:51] <LeoNerd> Nor even in what circumstance I'd throw it
[15:20:53] <malinus> tip: extern extern extern extern
[15:21:00] <malinus> ;)
[15:21:14] <jacekowski> LeoNerd: but things that are a given in bigger devices, like printf or malloc
[15:21:34] <LeoNerd> Hah.. malloc?
[15:21:43] <jacekowski> if you use that on avr and post the program here, first thing that someone will say is you shouldn't be using malloc or printf
[15:22:14] <aandrew> that's because you shouldn't be using malloc in embedded :-)
[15:22:16] <jacekowski> partially because overhead of malloc eats all the memory that could be allocated anyways
[15:22:30] <LeoNerd> Eh.. it's less "you shouldn't be using malloc", and more a question of "What kind of problem are you attempting to solve /on an AVR/ that you believe you need dynamic memory allocation to solve it?"
[15:22:37] <aandrew> yes
[15:22:52] <aandrew> which is almost always "I'm a newbie and didn't know any better" which is fine, that's what education solves :-)
[15:22:58] <LeoNerd> malloc is a great tool for solving a certain kind of problem; "don't use malloc" is more a statement of "don't solve that kind of problem"
[15:23:15] <aandrew> no, it's more "the type of problem that malloc() would solve doesn't exist on AVR"
[15:24:23] <jacekowski> i've had a problem when malloc would be a nice thing to use due to it being very clear about what it does
[15:24:59] <jacekowski> without going into detail, i've had a user configurable amount of ram space to be allocated to certain functionalities
[15:25:36] <jacekowski> to a total of around 500bytes
[15:25:45] <LeoNerd> I'd consider an array of union types
[15:25:52] <aandrew> what LeoNerd said
[15:25:58] <LeoNerd> Though I suppose that depends if the various alternatives are similar enough in size
[15:26:04] <LeoNerd> If they vastly differ that could get awkward
[15:26:05] <aandrew> you make your array bounds configurable within the maximum
[15:26:10] <jacekowski> no, it could be all over the place
[15:26:20] <jacekowski> as in, 500b to one and 0 to all others
[15:26:36] <jacekowski> so 0-500 for all of them was the setting
[15:26:41] * LeoNerd nod
[15:26:48] <LeoNerd> Yes, I believe I understand the problem
[15:26:54] <aandrew> I *very much* doubt that if your max was 500 and the user selected 250 you would be able ot realisticaly use the remainder for anything else, and if you did, it would be for one or two other things which could also be solved with variables that held the start/end indices
[15:27:24] <jacekowski> aandrew: that is what i've ended up doing
[15:27:39] <LeoNerd> For $N different types of data, I'd consider $N pointers to the 'base' of the storage, and $N limits of how much is valid; and have them all span an entire char array
[15:27:50] <LeoNerd> UB in C of course but we know it's AVR :)
[15:27:50] <jacekowski> exactly
[15:28:16] <LeoNerd> Which is *basically* what malloc will be doing underneath you anyway
[15:28:27] <LeoNerd> Just that you can do it nicer because you know you don't need to arbitrarily free the slabs, etc...
[15:28:28] <jacekowski> but i could just do malloc few times and it would be a lot cleaner solution
[15:30:33] <jacekowski> that was the same application where i wished i had room for printf in there
[15:30:44] <LeoNerd> I do use printf
[15:31:02] <LeoNerd> I should work out sometime why I can printf() with %s format, or sprintf with %d, but printf with %d causes it to reboot
[15:31:22] <LeoNerd> I end up basically sprintf'ing to a tiny buffer then printf'ing that with %s. It's very odd
[15:32:12] <jacekowski> i've ended up using my own implementation of printflike function that i could fit in remaining space and was a lot more limited than standard printf but it had all the functionality i needed from it
[15:32:51] <LeoNerd> Yah - one of C's limitations is the massively dynamic nature of printf.
[15:33:00] <LeoNerd> It's effectively a dynamic mini-language built inside the static outer one
[15:33:23] <LeoNerd> The problem there being that you can't statically determine which features you need to provide and which you can omit for space
[16:53:15] <Ad0> if you were to make a low power solution being able to pair and send data every minute over bluetooth smart, would you a) go for the total SOC from nordic semiconductors, or just use one of their BLE modules?
[16:53:39] <Ad0> I dunno if atmel has a full BLE SoC
[18:19:40] <kline> ok boyos, get your badposting in gear lets talk opinions: whats better: the old black and white datasheets or the new blue ones? examples:
[18:19:44] <kline> http://www.atmel.com/images/doc2543.pdf - old
[18:19:50] <kline> http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf - new
[18:25:46] <Ad0> hm
[18:27:47] <kline> #arduino came to a consensus in about 3 mins because they just googled it and grabbed the top results, but im sure you guys can do better ;)
[18:33:32] <Ad0> hehe
[18:33:42] <Ad0> how do I set up so my attiny runs at 1 mhz
[18:34:01] <Ad0> the timing on the blinking diode with delay_ms is completely random
[18:34:15] <Ad0> just acts plain weird
[18:34:31] <LeoNerd> Surely: either with a 1MHz crystal and set it to external crystal; or with the internal 8MHz RC oscillator and a /8 clockdiv?
[18:35:01] <Ad0> I am thinking of the internal one
[18:35:21] <Ad0> I mean the timing shouldn't be that bad that I can see it on a 200 ms interval. also the 200 ms looks more like a second
[18:36:01] <Ad0> there are some programmer settings I should have in addition to the CPU speed #define right
[18:36:15] <Ad0> what's it called, fuses?
[18:40:49] <Ad0> also I still have the programmer attached while running the diode
[18:41:00] <Ad0> maybe that messes things up ?
[18:52:57] <Lambda_Aurigae> LeoNerd, why not use Jartza's avr modem code?
[18:54:20] <LeoNerd> Lambda_Aurigae: for...?
[18:54:49] <Lambda_Aurigae> didn't you say something about a long range over common comms cable?
[18:55:34] <LeoNerd> Oh.. yah
[18:56:19] <Lambda_Aurigae> I'm kinda delayed...was at work when you asked earlier.
[18:57:19] <Lambda_Aurigae> that avr modem thingie seems very much like what you are wanting I would think.
[18:58:25] <Ad0> LeoNerd: you worked on the nordic semiconductor right
[18:58:45] <Ad0> nRF24L01+
[18:58:56] <LeoNerd> I'm doing so right this very second ;)
[18:59:01] <Ad0> hehe
[18:59:03] <Ad0> cool
[18:59:08] <LeoNerd> In fact as you were typing that I was making LEDs blink across my desk
[18:59:10] <LeoNerd> using them
[18:59:14] <Ad0> I am thinking about bluetooth smart
[18:59:29] <Ad0> and I see nordic semiconductors has a full soc
[18:59:46] <Ad0> that means you don't really need an avr
[18:59:51] <Ad0> but would the gain be that much ?
[19:00:00] <Ad0> I mean if you aim for a low power solution but like AVR
[19:00:14] <Ad0> afaik atmel isn't out with their full BLE SoC
[19:00:24] <LeoNerd> I've not looked into that at all, so I have no thoughts
[19:00:32] <Ad0> ok
[19:00:56] <Ad0> after what I have read, ble has longer range and low power
[19:01:04] <Ad0> and I guess it has pairing and encryption too
[19:01:21] <Ad0> which makes it excellent for sensor stuff
[19:07:29] <LeoNerd> Anyhow.. bedtime for me. Night all