#avr | Logs for 2015-10-29

Back
[06:02:35] <Lambda_Aurigae> ferdna, probably an IR laser diode...
[09:42:51] <rue_house> #arduino is a busy channel
[09:43:08] <rue_house> is #microcontrollers dead? I find this all funny
[10:08:05] <kristoiv> Is it safe to prepend to a "unsigned char buffer[200]", before giving it away to something that will read it by []-index lookup, by creating a struct containing your prepended byte followed by a pointer to your array (setting that pointer to the address of "buffer")? Something like: typedef struct {unsigned char prependedByte; unsigned char *buffer} extender; extender buff_extended; buff_extended.buffer = &buffer; buff_extended.prependedByte = 0xAB; writ
[10:08:05] <kristoiv> e(&buff_extended, buffer_len+1);
[10:09:30] <kristoiv> (I'm trying to avoid an additional buffer and memcpy)
[10:10:40] <twnqx> no, that won't work
[10:10:46] <twnqx> you'd have a byte folloed by a pointer
[10:10:54] <twnqx> not a byte followed by 200 bytes
[10:12:35] <kristoiv> twnqx, Yes, true
[10:12:46] <twnqx> if there was a good reason to that for me
[10:13:05] <twnqx> i'd go for u8 buffer[201]; u8 * smaller_buffer = &buffer[1];
[10:13:23] <twnqx> and normally use smaller_buffer, and if i want to prepend, use buffer
[10:14:21] <kristoiv> So the [1]-index position would be the pointer. But In my thinking was that any array in C is passed as pointers and indexing goes to the pointer address + sizeof(type)
[10:14:29] <twnqx> mh?
[10:14:46] <twnqx> no, the array is an array, and it is passed as a pointer to the first element
[10:14:47] <kristoiv> twnqx, smart trick :)
[10:15:20] <twnqx> and pointers can be dereferenced as arrays
[10:15:32] <twnqx> so *pointer or pointer[0] are alike
[10:15:41] <kristoiv> Yes
[10:15:59] <twnqx> as such, the smaller array is a pointer, yes, but it can be used just like an array
[10:16:54] <kristoiv> What I'm not seeing is why it would't work. The &buff_extended address should be the pointer address to the start of the struct. Meaning my prepended byte if dereferenced. If we index that to the first position [1], then that would hit the pointer (ok yes this isn't what we want)
[10:17:03] <twnqx> yes
[10:17:29] <twnqx> you could cast a pointer to the strict to an u8 *, and would get your byte
[10:17:29] <kristoiv> So there is no way of stitching together buffers then? :) Except from your suggestion that is
[10:17:36] <twnqx> (provided you chose #pragma pack (1)
[10:17:38] <twnqx> but
[10:17:39] <twnqx> after that
[10:17:44] <twnqx> you have a pointer
[10:17:48] <twnqx> C will not deref that
[10:17:59] <twnqx> but treat the first byte of the pointer as the second byte of your array
[10:18:11] <twnqx> an array is a consecutive memory block
[10:18:35] <twnqx> pointers only show up in multidimensional arrays
[10:18:43] <kristoiv> twnqx, yeah that makes sense. Interesting discussing this with you :) Thanks for the insight
[10:18:53] <twnqx> or do they even, not even sure here
[10:19:03] <twnqx> might just be layer fater alyer :P
[10:19:43] <kristoiv> twnqx, as far as I've understood multidimensional arrays are just normal arrays where the compiler fixes your indexes :)
[10:19:58] <twnqx> yeah
[10:20:03] <twnqx> might well be :P
[10:20:20] <twnqx> i rarely need them
[10:20:41] <twnqx> might be my "array of strings" thingy which could turn out kinda different
[10:21:02] <twnqx> but even then, not sure, never disassembled it
[10:21:03] <twnqx> :D
[10:22:00] <kristoiv> twnqx, hehe, well now you have something to do over the weekend :)
[10:28:32] <kristoiv> Another question. Are C buffer supposed to be cluttered on creation or am I doing something wrong?
[10:28:48] <kristoiv> (not calloc'ed)
[11:47:04] <twnqx> kristoiv: static buffers SHOULD be zeroed, malloc is whatever was in there before
[11:47:31] <twnqx> temporary buffers on the stack could hold random data as well
[11:48:16] <kristoiv> twnqx, that is exactly what I'm experiencing. Stack buffers cluttered with non-zero values
[11:48:33] <kristoiv> But I guess I see why based on how method headers / footers work
[11:48:57] <twnqx> i wouldn't want C to waste my precioud cpu cycles on initing memory :P
[11:48:58] <kristoiv> (I have been working with higher level languages for too long).
[11:49:04] <twnqx> trecious*
[11:49:08] <kristoiv> twnqx, hehe true! Thanks again
[11:49:30] <twnqx> precious* meh can't type
[11:49:47] <twnqx> multitasking = bad
[11:50:09] <twnqx> trying to understand if code i wrote several months ago is correct
[11:50:15] <twnqx> also never tested it
[11:50:31] <twnqx> so now reverse engineering what it does :S
[11:51:11] <twnqx> from a single line written in perl
[11:51:27] <twnqx> through the genrated code, several layers of macro expansion
[11:51:36] <twnqx> and static inline functions
[11:51:48] <twnqx> :S
[12:29:12] <gorroth> i just gave a little demo of my robot to our company, for fun.. i learned that i need to demo better
[12:29:16] <gorroth> i felt kinda silly, hehe
[12:29:23] <gorroth> but at least it worked, for the most part!
[12:43:41] <kristoiv> Damn! My compiler optimises away something vital making my code fail when I enable it.....
[12:43:54] <kristoiv> I guess it's back to debugging mode, I need optimisation
[13:14:07] <gorroth> kristoiv: is it taking out a piece of code or variable? declare it volatile
[13:17:00] <kristoiv> gorroth, thanks, I'll look. But I probably won't take this one on before tomorrow, it has been a long day already :). I did some quick looking and it seems like its deep into my code / SPI com or something ..
[13:17:56] <gorroth> well, how do you know it's taking out code? i was under the impression you had already gone deep if you know that
[13:19:26] <kristoiv> gorroth, sorry about that. It changed the flow compared to my C-code, so when I put in breakpoints I thought it removed a didThisThingFail clause and continued on, but after further research it's clear that it wasn't that which failed. It's the following function call
[13:19:44] <kristoiv> gorroth, that's when I decided I was hungry
[13:20:03] <gorroth> ahh, okay
[13:20:05] <gorroth> yeah
[13:20:08] <gorroth> good luck :)
[13:21:51] <kristoiv> gorroth, thanks!
[14:11:22] <Jartza> evening
[14:13:10] <Tom_itx> afternoon