Back
[08:41:14] <tpw_rules> the attiny85 doesn't have any sort of protected bootloader area does it? how can i ensure my bootloader doesn't get blown up when self-programming (ignoring my own code going wrong)
[08:41:33] <LeoNerd> Use a mega
[08:41:48] <LeoNerd> One of the key distinguishing features between tiny and mega is the bootloader arrangement
[08:41:48] <tpw_rules> are there any 8 pin megas?
[08:42:59] <LeoNerd> you could build a "probably good enough" safety system by not calling SPW directly, but storing a tiny little procedure that just bounds-checks Z before calling SPM
[08:43:14] <tpw_rules> what about something like a power failure?
[08:45:07] <tpw_rules> this will be for a low-volume commercial thing so i want to have a reasonable guarantee it won't screw up
[08:45:24] <LeoNerd> So... conceptually you can just put a bootloader division whereever you want
[08:45:32] <LeoNerd> by that bounds-check on Z
[08:45:41] <LeoNerd> Ensure that it boots up in the bootloader protected area first
[08:46:03] <tpw_rules> but that's all the mega does? if i enable brownout then it won't start overwriting random junk either?
[08:48:21] <tpw_rules> cool
[12:03:18] <megal0maniac> I may have killed my attiny :/
[12:03:30] <megal0maniac> Only seem to get 1.6V out of the thing
[12:04:59] <megal0maniac> Input with pull-up or output driven high. VCC is 5V.
[12:08:17] <Tom_itx> woops
[12:09:27] <LeoNerd> AVRs tend to be somewhat fragile
[12:09:39] <LeoNerd> At least, that's what the PIC fans keep telling us - usually moreso than the PICs
[12:10:27] <Tom_itx> i had more problems with pic than i ever had with avrs
[12:10:38] <megal0maniac> PB1 still works
[12:10:53] <Tom_itx> that's all you really need :)
[12:10:54] <megal0maniac> PB0 is funky, which is a shame because it's where INT0 is
[12:11:07] <LeoNerd> You might have blown one of the push/pull drivers
[12:11:19] <LeoNerd> You might effectively have an open-collector output pin now
[12:11:23] <megal0maniac> Seems like it
[12:11:40] <megal0maniac> I pulled-up externally and the voltage didn't change
[12:11:50] <megal0maniac> Consistently 1.6V. Strange
[12:12:00] <megal0maniac> attiny10
[12:12:18] <megal0maniac> But I can just as well use PCINT
[12:13:12] <Tom_itx> not many pins to loose on that
[12:13:25] <Tom_itx> lose*
[12:17:31] <megal0maniac> No :/
[12:18:03] <megal0maniac> Would have been nice to have INT0 though
[12:30:55] <timemage> LeoNerd, i was under the impression that pic people mostly thought that because of how fuses work. and how a lot of the pics have a fail-over to internal osc, not so much electrical characteristics.
[12:32:00] <timemage> megal0maniac, :) you're using one of the 6pin ones?
[12:32:10] <megal0maniac> Indeed
[12:32:17] <LeoNerd> Mm.. I dunno
[12:32:39] <timemage> megal0maniac, i got one a while back and stuck it on an adapter board just to play with it. haven't done much with it though.
[12:33:46] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/avr/tiny10/goodies/pwm/
[12:33:56] <Tom_itx> iirc, that's a red light & siren effect
[13:27:42] <megal0maniac> Ooooh
[13:28:08] <megal0maniac> A LUT isn't really an option with 32bytes of RAM. Not a 128 point one anyway
[13:28:35] <LeoNerd> LPM available?
[13:29:16] <megal0maniac> Hmmm... Probably
[13:29:21] <megal0maniac> Forgot about that
[13:30:10] <megal0maniac> It's mainly sine, I might be able to calculate
[13:30:59] <LeoNerd> If you've enough program flash spare, you can use LPM. And don't forget you only need the first quarter cycle; the other 3 can be done by symmetry
[13:33:55] <megal0maniac> Good grief that was simple
[13:36:39] <LeoNerd> Oh?
[13:37:24] <megal0maniac> Oh. Except it didn't work. Apparently I need to access the vars differently
[13:38:19] <megal0maniac> Hmmm... Everything I'm reading about refers to string functions
[13:39:13] <stanreg> Atmegas: can one transfer the (small) EE's contents to the (large) flash memory using self-programming, as the EE fills up?
[13:40:09] <LeoNerd> If you can read EE and write flash, then sure
[13:43:20] <megal0maniac> pgm_read_byte(&byte) saves the day
[13:44:06] <LeoNerd> :)
[13:44:11] <LeoNerd> So, yeah.. LPM
[14:00:22] <rue_bed> ... maybe you should get a 24C256 or something?
[14:05:17] <megal0maniac> rue_bed: Noooo
[14:05:23] <megal0maniac> Not with an attiny10
[14:05:30] <megal0maniac> progmem is my friend
[14:20:10] <megal0maniac> So this code is supposed to toggle between LED on, LED off and a 'breathing' effect using a button press. However it isn't cycling through modes. Instead it seems to be selecting them at random
http://pastebin.com/3pzPswZT
[14:23:33] <megal0maniac> As if it's pointing to a random address in memory and not the variable
[14:28:10] <twnqx> OCR0AL = pgm_read_byte(&breathe[mode++]);
[14:28:18] <twnqx> are you sure you want to increase... mode?
[14:28:55] <twnqx> also, when exactly do you restart the loop for the breathe data?
[14:29:03] <twnqx> there are so many things wrong with that codde
[14:29:34] <twnqx> or is that exactly 256 byte, and you abuse the length of mode?
[14:29:54] <megal0maniac> Aaaah
[14:30:05] <megal0maniac> I refactored count to mode, and missed that
[14:30:16] <megal0maniac> And the array is 256 bytes
[14:30:29] <twnqx> then you kinda rely on undefined behavior :P
[14:30:35] <twnqx> gcc could even remove all that code, legally :D
[14:31:34] <megal0maniac> twnqx: Thanks, it works now :)
[14:31:47] <megal0maniac> In the interest of good practice, what would you change?
[14:32:13] <twnqx> probably nothing
[14:32:23] <twnqx> gcc currently does the right and expected thing
[14:32:43] <megal0maniac> So "if it ain't broke, don't fix it" kind of deal?
[14:33:19] <twnqx> yeah
[14:33:32] <megal0maniac> How would you have done it differently though?
[14:34:00] <twnqx> ffs i exploded my helicopter :(
[14:34:12] <twnqx> playing FPS and chatting doesn't mix ;)
[14:34:32] <megal0maniac> Respawn. The joy of software ;)
[14:34:34] <twnqx> well, legally you'd manually wrap
[14:35:17] <megal0maniac> So: if (count == 123) count = 0;
[14:35:26] <megal0maniac> 123 being the length of the array
[14:35:37] <twnqx> well...
[14:35:47] <twnqx> doesn't work with 8bit and 256 :P
[14:37:09] <megal0maniac> How so?
[14:37:19] <twnqx> well
[14:37:31] <twnqx> you can do if (count == 255) count = 0; else count++;
[14:40:25] <LeoNerd> count = (count + 1) % 256 might also work
[14:40:35] <LeoNerd> count = (count + 1) & 255 might also work
[14:57:46] <rue_more> how about actually make count 8 bits
[14:57:56] <twnqx> it... is?
[14:57:59] <rue_more> then it automatically rolls over to 255 when you add 1
[14:58:20] <rue_more> if count is 8 bits, it can never get larger than 255
[14:59:06] <rue_more> make sure to use the explicit type, and not char, as sometimes, people decide a char should be 16 bits
[15:21:27] <megal0maniac> It's a uint8_t
[15:22:27] <xpoqp> I'm used to dealing with PCs, now I'm curious about communication protocols for embedded systems, I'm implementing a device that takes commands possibly with arguments over serial port from PC and handles lots of peripherals from there.
[15:22:37] <xpoqp> like RPC.
[15:24:24] <xpoqp> what's the best approach for doing somethign like this? is there any libraries or resources I should take a look at?
[15:24:51] <LeoNerd> I'm not sure I understand the question
[15:28:48] <xpoqp> LeoNerd: perhaps it isn't a very good question. :)
[15:29:13] <xpoqp> I could implement my own protocol for communicating, suited for my application.
[15:29:28] <xpoqp> if I wanted a fast way to do this between two applications using a PC I could use RPC.
[15:31:42] <xpoqp> but maybe not for embedded systems with limited resources that communicates over serial port.
[15:31:54] <LeoNerd> "use RPC"
[15:32:12] <LeoNerd> You are aware that the acronym "RPC" relates to a general concept, right..? rather than a specific "use these bytes on the wire" format...
[15:32:47] <xpoqp> are there any good RPC libraries available?
[15:33:11] <LeoNerd> ?
[15:34:25] <megal0maniac> Is it ardweenie time?