Back
[04:22:48] <Jartza> morning
[04:25:30] <hypermagic> hello my friends
[04:30:14] <hypermagic> <Lambda_Aurigae> I suspect they don't do so well with overclocking either. < actually, they work faster at lower voltage :)
[04:32:16] <hypermagic> Shavik|Work2, that is a simple buck regulator, you just need to make sure parts will not glow red hot
[05:44:23] <apo> Speaking of timing, I love how the watchdog's clock is supposed to be 128kHz but doesn't ever actually reach that
[05:58:28] <hypermagic> watchdog is a failsafe timer.
[05:58:44] <hypermagic> it works by applying a reset after a timeout
[06:24:40] <apo> what
[06:24:55] <apo> that has nothing to do with its clock rate
[06:30:52] <LeoNerd> It's not supposed to be particularly accurate
[06:33:02] <Jartza> ohh
[06:33:09] <Jartza> got my blog post to HaD :o
[06:37:30] <LeoNerd> Had?
[06:46:49] <apo> LeoNerd: Nope, but it's still amusing that it's called 128 kHz oscillator when it doesn't even reach 128
[06:48:11] <apo> e.g. on the mega32u4, the highest it gets is 124 kHz... at -40 degrees, and 2V
[06:49:40] <Jartza> LeoNerd:
http://hackaday.com/2014/11/30/transferring-audio-to-an-avr-at-12kbps/
[06:50:40] <LeoNerd> Ah, "hack-a-day"
[06:51:30] <LeoNerd> Heh.. cute ;)
[06:51:39] <LeoNerd> Do you need to carry a Sony Walkman to reload the images though? ;)
[06:53:25] <twnqx> nah, can use you ipod or mobile, too :P
[06:54:12] <LeoNerd> Stick a tiny electret mic on the board, and you could load it "wirelessly" :)
[06:54:30] <LeoNerd> Just hold the phone up to it, run a little app on the phone, and there.. new image.
[07:35:18] <hypermagic> apo, you don't get it, it does not have a clock rate.
[07:35:32] <hypermagic> it is a monostable multivibrator
[07:37:27] <Jartza> LeoNerd: hehe, no need for walkman, just a smart phone ;)
[07:57:32] <hypermagic> <Lambda_Aurigae> I suspect they don't do so well with overclocking either. < actually, they work faster at lower voltage :)
[07:58:02] <hypermagic> lower power, lower voltage, and higher frequency.
[07:58:17] <Lambda_Aurigae> interesting..that's not what the datasheet says, but, go for it.
[07:58:29] <hypermagic> read it again
[07:58:32] <Lambda_Aurigae> but, by overclocking, I meant going beyond the rated clock speed.
[07:58:49] <hypermagic> you didnt pay attention to details
[07:59:24] <hypermagic> well it is meaningless to say that
[07:59:43] <hypermagic> frequency limit is function of power supply voltage
[08:00:11] <hypermagic> and slightly varies by part, depens on temperature
[08:00:42] <Lambda_Aurigae> so, page 2 of the datasheet is wrong?
[08:00:44] <hypermagic> it is not wise to run a cpu beyond limit.
[08:00:52] <Lambda_Aurigae> 0 - 4MHz@1.8 - 5.5V, 0 - 10MHz@2.7 - 5.5.V, 0 - 20MHz @ 4.5 - 5.5V
[08:01:00] <hypermagic> limit = when it hangs
[08:01:32] <Lambda_Aurigae> that tells me it won't run reliably at 20MHz below 4.5V
[08:01:42] <hypermagic> so we subtract a percentage from the limit and add a safety margin to make a system that will not fail randomly
[08:02:42] <hypermagic> this is just a guideline you read
[08:03:17] <hypermagic> stability is not this simple - far from being this simple
[08:03:37] <hypermagic> but it can be shown in a graph
[08:04:36] <Lambda_Aurigae> like the one on page 303, figure 29-1
[08:04:55] <hypermagic> anyway, if you want 20MHz just add a boost converter.
[08:05:17] <Lambda_Aurigae> still have to run it at higher voltage to get higher speeds.
[08:05:24] <hypermagic> microcontroller could boost its own supply voltage too using some simple parts.
[08:07:57] <hypermagic> i used atmega168pa @8MHz, had no issues, it was hitting 1.5V and still ticking ok and the performance is outstanding, and i only wrote stuff in C
[08:16:19] <hypermagic> i did not expect it to run at the forward voltage of a red led ^^
[08:16:47] <hypermagic> but i turned on UVLO just to "be safe"
[08:17:55] <hypermagic> it sux a bit however the pars can not work properly with lowest @1.8V uvlo...
[08:18:16] <hypermagic> design engineers failed on this sone
[08:19:25] <hypermagic> the 1.8V uvlo might be good for 3.3V system
[09:25:42] <tpw_rules> i have an atmega8 in an embedded system that i'm trying to dump the flash of. how can i determine if lock is enabled? all the data i'm reading appears to be the lowest byte of the address, so i suspect it is?
[09:26:20] <Lambda_Aurigae> can you read the lock bits and fuses?
[09:26:46] <tpw_rules> H:DF, L:2F according to avrdude, not sure how to read lock bits. plugged it into the fuse calculatore and it mentions nothing about lock
[09:27:03] * tpw_rules pulls out datasheet like somebody who knows what they're doing
[09:28:09] <tpw_rules> SPIENB is checked
[09:30:48] <Lambda_Aurigae> -U lock:r:-:i
[09:30:57] <Lambda_Aurigae> as part of avrdude to read the lock bits.
[09:31:14] <Lambda_Aurigae> -U lock:r:-:h for hex format
[09:31:42] <tpw_rules> aw darn it is locked
[09:31:47] <tpw_rules> boot isn't though
[09:32:20] <Lambda_Aurigae> that's normal.
[09:32:40] <Lambda_Aurigae> bootloader could then be used to write the flash.
[09:32:51] <tpw_rules> avrdude only wrote 2K to the hex file though?
[09:33:50] <tpw_rules> oh i see. it puts each page on a line
[09:35:15] <tpw_rules> so i guess i still can't read the bootloader either
[09:36:56] <tpw_rules> so i'm fairly hosed. darn.
[09:38:06] <LeoNerd> You're never totally hosed.. you can always just chip-erase the entire thing and start again
[09:38:17] <tpw_rules> i can't break this because it's worth quite a bit of money unmolested. nah LeoNerd it's out of a commercial product
[09:38:26] <Lambda_Aurigae> that's useless if he wants the data off it though.
[09:38:29] <LeoNerd> Ah
[09:39:12] <tpw_rules> oh well, more protocol RE time!@
[09:41:19] <tpw_rules> i wonder if you can defeat this by powering off in the middle of a chip erase. if they're intelligent they'll do fuses first though
[09:41:26] <tpw_rules> s/fuses/flash/
[09:41:37] <LeoNerd> Atmel thought of that ;) The fuses are done last
[09:42:51] <tpw_rules> what about browning it out? this has an external clock, perhaps glitch that? i guess it would be smart to verify the erase though. haters :<
[09:47:33] <twnqx`> just slice the chip open and wipe the fuses with a microprobe or ion beam
[09:47:42] <twnqx`> there are companies that'll do that for yu
[10:53:16] <tuxx_> hey guys
[10:53:23] <tuxx_> i am trying to modify optiboot
[10:54:36] <tuxx_> i added a function 'void uart_puts(char *buf) { char *p = buf; for(; *p; p++) putch(*p); }'
[10:55:25] <tuxx_> when i call uart_puts("blaa"); buf is empty.. it is all \0\0\0\0
[10:55:58] <tuxx_> it seems that the address is not being passed correctly or something.. maybe it has something to do with how main() is defined: int main(void) __attribute__ ((OS_main)) __attribute__ ((section (".init9")))'
[10:58:52] <tuxx_> http://pastebin.com/AgX00Sr0
[10:59:21] <tuxx_> in main static const char *str = "hello"; is defined and uart_puts(str); is called
[11:00:04] <tuxx_> but uart_puts does not iterate over the string because the pointer buf in 'void uart_puts(char *buf)' somehow has a wrong address
[11:00:07] <tuxx_> very frustrating
[11:00:51] <tuxx_> any advice would be greatly appreciated
[11:13:05] <hypermagic> hi
[11:13:38] <hypermagic> correct notation is 'char* exitmsg="Press ESC to exit.";'
[11:13:43] <hypermagic> so what is the problem?
[11:14:56] <hypermagic> "buf" will become a pointer to a character string.
[11:18:04] <hypermagic> will 'uart_puts(&str);' work?
[11:40:08] <Tom_itx> void lcd_puts(const char *s)
[11:40:29] <Tom_itx> void lcd_puts_p(const char *progmem_s)
[11:42:49] <tuxx_> hypermagic: hey sry
[11:43:19] <tuxx_> hypermagic: why would it be &str?
[11:43:40] <hypermagic> &str means address of pointer
[11:43:58] <tuxx_> exactly
[11:44:12] <tuxx_> so in this case it should ont be &str
[11:44:19] <hypermagic> i haven't read your code
[11:44:59] <hypermagic> for(; *p; p++) putch(*p); ?
[11:45:31] <tuxx_> http://pastebin.com/v0YgXqy7
[11:45:58] <tuxx_> hypermagic: this is not a problem with my coding.. it is some memory issue in GCC
[11:46:09] <tuxx_> hypermagic: i fully understand pointers
[11:46:12] <hypermagic> maybe try using an integer to index your buffer ?
[11:46:20] <tuxx_> anyway if you check my post you will see the output
[11:46:23] <tuxx_> of what i am seeing
[11:46:58] <tuxx_> 00000000 68 61 01 00 62 63 01 00 64 68 65 01 00 66 00 68 |ha..bc..dhe..f.h|
[11:47:04] <tuxx_> forget the last 'h'
[11:47:08] <hypermagic> ofc i assume you wrote what you wrote because you believed it was right
[11:47:22] <tuxx_> hypermagic: i am an experienced C programmer
[11:47:36] <tuxx_> i code C for roughly 15 years
[11:48:01] <tuxx_> hypermagic: the issue here is that i am seeing some very strange behaviour in C... possibly due to not copying the right memory sections of the bootloader
[11:48:14] <hypermagic> happens
[11:48:25] <tuxx_> hypermagic: so.. what i am seeing is that... i for some reason
[11:48:26] <hypermagic> did you verify you still have available ram?
[11:48:38] <tuxx_> well the string is static
[11:48:39] <hypermagic> stack overflow can be interesting too
[11:48:47] <tuxx_> hmmm
[11:48:56] <tuxx_> so i am printing the addresses of the pointer
[11:49:04] <tuxx_> hypermagic: stack overflow is a good point
[11:49:15] <tuxx_> but i dont really think so actually
[11:49:34] <tuxx_> let me rule out those issues
[11:49:47] <hypermagic> i usually store tables and static things in flash, especially in low ram devices
[11:50:09] <tuxx_> not sure if i can do that in the bootloader section
[11:50:13] <tuxx_> but possibly, yes
[11:50:18] <hypermagic> your const may be loaded into ram all the time...
[11:50:32] <hypermagic> many small things will consume all ram
[11:50:38] <hypermagic> like 1-10kB ? ;)
[11:51:02] <tuxx_> hmm
[11:51:21] <tuxx_> you might be right actually
[11:51:51] <hypermagic> if the code looks right then search a reason to fail
[11:53:12] <hypermagic> once my cpu overheated during computation (amd) and it missed floatingpoint operations bad (!)
[11:55:58] <tuxx_> :D
[12:15:23] <tuxx_> hypermagic: check this out:
[12:16:48] <tuxx_> hypermagic:
http://pastebin.com/JLP54jMg
[12:17:58] <tuxx_> unbelievable
[12:18:19] <Tom_itx> would p++ work?
[12:18:26] <Tom_itx> or ++p
[12:18:47] <tuxx_> how exactly do you mean that?
[12:18:52] <Tom_itx> to increment p
[12:18:57] <tuxx_> it should not make a difference
[12:19:14] <Tom_itx> it would loop on it's own then
[12:19:22] <tuxx_> that is what i am trying to do
[12:19:39] <tuxx_> simply pass a nullterminated string to the function aand do for(p=buf; *p; p++) putch(*p);
[12:19:57] <tuxx_> but for some reason my memory goes all \0\0\0\0 as soon i enter the loop
[12:20:02] <tuxx_> its insane
[13:18:27] <Lambda_Aurigae> "If this works, it'll keep us from gettin' caught. If it doesn't, it'll keep us from gettin' old."
[18:01:04] <reportingsjr> what would a normal Vcc be for programming from the STK500v2?
[18:01:14] <reportingsjr> I'm seeing about 2V which seems like it is too low.
[18:01:50] <atom1> it is too low
[18:01:55] <atom1> 5v is normal
[18:02:20] <Lambda_Aurigae> official stk500 board runs at 5V by default but there is a voltage adjustment in the protocol.
[20:31:18] <apo> oh hey abcminiuser
[20:31:48] <apo> Damn, I was about to go to bed, guess that'll have to wait :p
[20:33:23] <abcminiuser> Ahoyhoy
[20:34:24] <abcminiuser> I should probably check here more often :P
[20:34:52] <Tom_itx> you should!
[20:34:54] <apo> abcminiuser: I'm a first-time LUFA user and was taking a look at the MIDI example with a Leonardo board. I don't have any joysticks or buttons attached, so I just wanted to make it send a control change every once in a while, this is what I did:
http://p.0au.de/49696979/midi.tar.bz2
[20:34:58] <apo> Heh
[20:35:41] <abcminiuser> Tom_itx, I was busy this weekend, I have an excuse:
http://fourwalledcubicle.com/blog/2014/11/we-interrupt-this-irregularly-scheduled-program/
[20:35:56] <apo> I don't seem to be receiving any USB packets after it enumerates (checked with wireshark), and one of the configuration packets seems to be malformed
[20:35:59] <abcminiuser> apo, neato!
[20:36:18] <apo> I don't have it here at the moment, but if you're willing to troubleshoot this with me I can get a hold of it quickly :)
[20:36:48] <Tom_itx> you are doomed now!!
[20:36:52] <Tom_itx> congrats!
[20:36:56] <Tom_itx> (i think)
[20:37:04] <abcminiuser> Hah yes, O'
[20:37:06] <apo> the only change in the code above to the class driver example is that I removed the joystick/button stuff and replaced it with a counter + control event change messages
[20:37:09] <abcminiuser> *It was my decision :P
[20:37:26] <abcminiuser> apo, what happens when you plug it in?
[20:37:43] <Tom_itx> she must like the nerdy type
[20:38:51] <apo> abcminiuser: it goes through the arduino bootloader, then shows up as a midi device
[20:39:00] <apo> for more than that, gimme a second to load the firmware
[20:41:17] <apo> abcminiuser: want a dump of the wireshark stuff?
[20:41:42] <apo> the reply to the second configuration request is malformed, according to it
[20:42:14] <apo> other than that it seems to do its stuff (that is, the LEDs are toggling and indicate that the control is changing), but I don't see any packets
[20:42:48] <apo> this is my first time actually working with USB, so I don't know what exactly you'll need :)
[20:43:37] <apo> woah
[20:43:43] <apo> I just got a whole bunch of packets at once <_<
[20:44:51] <apo> They all have some leftover capture data that doesn't seem to have the incrementing counter from the control change, hrm
[20:46:30] <apo> bInterfaceClass: Unknown (0xffff)...
[20:47:22] <abcminiuser> (Was on phone, I'll poke at the code now)
[20:51:13] <abcminiuser> Hrm code looks OK other than the fact it will absolutly spam the crap out of the bus
[20:51:52] <apo> abcminiuser: Oh? The LEDs only toggle maybe 4 times per second
[20:53:33] <abcminiuser> Every 255 iterations of the main loop it will try to send a new packet, but since there's no delays anywhere that will be quite fast
[20:54:21] <apo> Yeah, 4 times per second :D
[20:58:29] <apo> I'm still getting those packets now, but I'm not seeing the value counter anywhere
[21:05:06] <apo> wait a minute, those are from a different device... I forgot about the internal stuff.
[21:05:13] <apo> Okay, it's just not sending anything, then
[21:07:19] <apo> http://p.0au.de/124569d/packets.txt no idea if this is any help
[21:07:55] <apo> That should be everything it does while starting up, including the bootloader stuff
[21:27:11] * apo pokes abcminiuser with a logic analyzer probe
[21:30:21] <abcminiuser> Sorry was attempting a bit of that old "Who's on first" routine with someone trying to work out what the heck they were doing
[21:30:55] <atom1> what's on second?
[21:31:06] <abcminiuser> *sigh*
[21:31:29] <abcminiuser> It's too hot to try to pry information such as "what bus is it attached to" out of someone :P
[21:31:38] <abcminiuser> That trace shows the comms going dead after enumation
[21:31:43] <abcminiuser> *enumeration
[21:32:08] <abcminiuser> So looks like the client app isn't trying to read the data out of the device, it will buffer packets waiting for the host to pick them up and time out every so often
[21:32:14] <abcminiuser> Which is probably why you see only 4Hz
[21:32:25] <apo> hmm
[21:32:31] <apo> but alsa shows the card
[21:32:37] <apo> I wonder if I need a client...
[21:33:10] <apo> but I've started gmidimonitor, and that didn't do anything either
[21:34:54] <apo> oh wow
[21:35:33] <apo> abcminiuser: Thanks for explicitly saying that something needs to be reading from the device
[21:35:47] <apo> I just tried getting jack to read as well, and /now/ I'm getting data! :D
[21:36:47] <apo> And yeah, much faster than before. I thought that 500 calls to the main loop per second was rather slow, but of course I've never done this :)
[21:37:24] <abcminiuser> Science!
[21:38:23] <apo> whee
[21:38:27] <apo> now I can build my pedal
[21:39:35] <apo> and I can forget about getting out of bed any time soon, too :p
[21:39:41] <apo> Good night, and thanks again \o
[21:41:25] <abcminiuser> Night