Back
[08:19:10] <mux_> anyone feel like partying?
[08:37:47] <Steffanx> always mux_
[08:37:52] <mux_> let's go! \o\
[08:37:53] <mux_> /o/
[08:38:06] <Steffanx> \o/
[08:38:07] <mux_> macarena!
[08:38:16] <mux_> pfffff oh man I'm tired after that
[08:38:24] <Steffanx> What's next? YMCA?
[08:43:23] <mux_> I don't know if I can pull off YMCA
[08:53:07] <Steffanx> ok, maybe next time mux_
[14:29:59] <awozniak> I'm looking for a bootloader for the atmega324p, hopefully something avrdude can talk to. Where should I look?
[14:40:09] <RikusW> if you're not afraid of asm ->
http://www.ruemohr.org/code/BLM8.zip
[14:40:22] <RikusW> will need to be slightly modified for 324
[14:40:26] <RikusW> mostly uart
[14:52:22] <awozniak> I found the app note AVR109, but it has some problems compiling with my toolchain.
[19:58:22] <jadew> sup?
[19:59:14] <krysmin> Why write in asm/c is better to write than write in c/asm?
[19:59:40] <jadew> what do you mean?
[19:59:54] <jadew> asm/c c/asm would mean the same thing - a combination of both
[20:00:07] <jadew> so asm/c can't be different than c/asm
[20:00:13] <krysmin> Ah
[20:00:41] <krysmin> Why asm is better than c / why c is better than asm
[20:01:14] <wulax> I need some help with memory allocation in C I think. I have an array of struct pointers at the top of a source file. I malloc it from the main method with a function call. I then use functions from that source file to manipulate the array and the structs it points to. But somehow it does not work, it seems to point to totally wrong memory. Could someone have a look?
http://codepad.org/nURoPD2W The header file
[20:01:17] <wulax> just contains the function heads (or whatever it's called).
[20:01:24] <jadew> they're so different you can't really compare
[20:01:35] <jadew> c is a higher level language
[20:01:42] <jadew> asm is... raw instructions
[20:02:35] <jadew> why are you mallocing it at all?
[20:02:49] <wulax> jadew: what should I be doing then?
[20:03:01] <wulax> I am somewhat of a noob in c :-(
[20:03:22] <jadew> you're not destroying them until the program finishes, right?
[20:03:57] <wulax> nope, it is used until I shut off the power
[20:04:20] <jadew> in that the case, just declare them
[20:04:27] <jadew> MyType myarr[10];
[20:04:36] <jadew> and then you can use your queue to point to elements in there
[20:04:48] <wulax> alright, I'll try that out
[20:04:51] <wulax> thanks
[20:05:10] <jadew> that will solve 1 issue: it will let you know if you overflow at copile time
[20:05:12] <jadew> well.. after
[20:05:25] <jadew> you can check the .bss + .data segments size
[20:05:53] <wulax> I didn't know that, that's neat
[20:05:55] <jadew> then whatever is left after you do RAM - (.bss + .data) is what you are left with for dynamic allocations & stack operations
[20:08:08] <jadew> also, I see that when you're removing something from the queue, you're shifting the entire queue by 1
[20:08:21] <wulax> yes?
[20:08:22] <jadew> you can use that to figure out if the queue is empty or full
[20:08:30] <jadew> by simply checking the first and the last element
[20:08:33] <jadew> if the first is 0
[20:08:39] <jadew> the queue is not empty
[20:08:44] <jadew> if the last is not 0, it's full
[20:08:53] <wulax> that's true, thanks for the suggestion!
[20:09:05] <jadew> np, that way you can get rid of those for loops :)
[20:10:55] <jadew> your remove_first() function is wrong
[20:11:14] <jadew> you're assigning event_queue[EVENT_QUEUE_SIZE - 1]
[20:11:28] <jadew> and there's no warranty that that's actually the last item in the queue
[20:11:33] <jadew> the last one could be item 5
[20:11:45] <jadew> oh wait
[20:11:51] <jadew> that would be taken care of in the loop
[20:12:26] <wulax> the size of the queue never changes, so it should suffice I think
[20:12:35] <jadew> yeah, it's fine
[20:12:47] <jadew> everything looks ok
[20:13:20] <jadew> so you might have some memory corruption going on
[20:14:01] <wulax> you mean physical, or elsewhere in the program?
[20:14:17] <wulax> err, hardware I mean
[20:15:13] <wulax> maybe I should try changing out the mcu?
[20:15:32] <wulax> I have no idea how many write cycles I have made to it
[20:15:42] <Tom_itx> not enough to ruin it
[20:16:39] <wulax> maybe I have accidentally pumped too much voltage into it at some point
[20:17:12] <wulax> I have some spares fortunately
[20:17:38] <jadew> no
[20:18:04] <jadew> the most common issue when things act crazy and I don't know why, is some memory corruption
[20:18:12] <jadew> like some stack overflow
[20:18:37] <jadew> maybe you're doing char buff[100]; buff[100] = 0; somehwere
[20:19:16] <jadew> things like that can completely screw up your data and can be very hard to track down
[20:19:25] <wulax> I suppose. I'll have to look into it some more. thanks for all the suggestions though.
[20:19:41] <jadew> np, first thing you have to make sure is that you're not using more memory than you have
[22:57:41] * Casper justs realised that he can't use his attiny...
[22:57:46] <Casper> no programmer for them... grrrr
[23:04:11] <learath> so make one?
[23:06:20] <Casper> yeah
[23:40:53] <Casper> oh it's SPI! so I DO have a programmer!
[23:53:10] * Casper might needs to find a small serial bootloader...