Back
[00:07:54] <raden> what is rasberry pi exactly ?
[00:07:56] <raden> I dont get it
[00:08:00] <raden> maybe im retarded
[00:08:18] <Casper> basically a mini computer
[00:08:30] <Casper> that is ARM (?) based
[00:12:01] <raden> trying to find a way to remotely control like 8 relays
[00:12:03] <raden> via AVR
[01:05:11] <braincracker> <nickjohnson_> (I love Adafruit, but their code is _awful_) < girl coding
[01:07:40] <braincracker> ahahah raden
[05:37:44] <antto> could it be a problem if one of the UARTs is set to use interrupt, but the other doesn't?
[05:39:11] <antto> UCSR0B and UCSR1B
[05:42:51] <Roklobsta> what problem?
[05:43:25] <Roklobsta> what catastophe do you think could happen?
[05:44:30] <antto> i have a firmware which uses two UARTs, one for FTDI (usb-serial) and the other one for MIDI
[05:44:36] <antto> both are used in interrupt mode
[05:45:12] <antto> now, i have a bootloader, in which the first UART is used for connection to avrdude, but it's not in interrupt mode
[05:45:19] <antto> (that works of course)
[05:45:19] <Roklobsta> well, one will get priority over the other which is normal but there shouldn't be a problem.
[05:45:41] <antto> but i'm trying to get the other UART to act as MIDI just like in the firmware
[05:45:48] <antto> however, it doesn't appear so
[05:45:49] <Roklobsta> i have just done a bunch of interrupt code for the uarts and it's fine *if* you do it right.
[05:46:13] <antto> the code for setting it up - i took it off of the firmware, which sets it up to use interrupt
[05:46:49] <Roklobsta> i have a fifo mechanism involved.
[05:47:01] <Roklobsta> or lilo if you prefer
[05:48:56] <antto> i noticed the firmware calls sei() somewhere, i just added that to my bootloader
[05:49:10] <antto> maybe that's why it didn't work
[05:51:40] <antto> nope, just checked.. :/
[06:50:03] <Badaboom> h
[07:10:48] <antto> to get a UART functioning in interrupt scheme, what is required? timers? anything?
[07:11:02] <ziph> No, just interrupts.
[07:11:34] <ziph> e.g. enable all the right register bits and write an interrupt handler that correctly gets inserted into the interrupt table.
[07:17:25] <antto> http://pastebin.com/Re3v7fMc
[07:18:47] <antto> basically, i copied that code from the firmware and into the bootloader, but i still don't appear to have this midi working in the bootloader (the LED doesn't blink)
[07:46:38] <braincracker> [145612] <h4x0riz3d> the question is, if i program a firmware onto the chip, does it _really_ matter whether the "unused" bytes get set to 0xFF < all unprogrammed bytes are FF i think
[07:46:56] <braincracker> unless you set EESABE flag, and write into EEPROM
[07:47:36] <braincracker> [164312] <h4x0riz3d> what is "int" in avrgcc? < same as in gcc... the architecture integer type.
[07:51:14] <antto> well, i got stuck at even enabling the midi
[07:51:39] <antto> midi uart
[07:52:10] <braincracker> midi? where?
[07:53:01] <antto> to summarize, i have a firmware which uses the two uarts, both in interrupt mode, one is used for FTDI, the other is used as midi
[07:53:37] <antto> they both work.. now i also got a bootloader which uses just the FTDI uart but _not_ in interrupt mode
[07:54:21] <antto> i was trying to implement firmware update via midi, so i copied the code for setting up the midi uart from the firmware
[07:54:36] <antto> at least the pieces of code which i *think* are related to it
[07:54:40] <braincracker> what do you mean by midi?
[07:54:44] <braincracker> that was a sound thing on PC
[07:55:05] <antto> midi is for musical instruments, basically just like a serial port
[07:55:11] <antto> at a hardcoded baudrate
[07:55:24] <braincracker> and your atmel mcu has it?
[07:55:38] <antto> the device has it
[07:55:46] <antto> everything works in the firmware ;]
[07:59:41] <antto> braincracker
http://pastebin.com/Re3v7fMc <- this is the code which i took from the firmware and inserted in the bootloader
[08:00:05] <antto> if it works, it should blink one of the LEDs... but nothing
[08:02:00] <braincracker> no idea
[08:02:12] <braincracker> i'm on linux, avr-gcc
[08:03:08] <braincracker> and never used SIGNAL()...
[08:03:57] <braincracker> Badaboom <=
http://hof.povray.org/
[08:03:59] <braincracker> <;
[08:04:04] <braincracker> virtual reality
[08:05:19] <antto> uhm, what do you mean? i use avrgcc too
[08:05:27] <antto> what's wrong with this SIGNAL() thing?
[08:07:07] <braincracker> antto<=
http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
[08:07:43] <braincracker> Deprecated:
[08:07:43] <braincracker> Do not use SIGNAL() in new code. Use ISR() instead.
[08:08:04] <antto> i didn't write neither the firmware, nor the bootloader
[08:08:20] <antto> that code with the SIGNAL() is from the firmware, and it works there *shrug*
[08:08:34] <antto> i guess my avrgcc is old-ish (winavr)
[08:08:49] <braincracker> ok
[08:08:53] <braincracker> so what does not work then?
[08:09:41] <antto> that's where i'm stuck
[08:09:50] <antto> it doesn't work when i put that code in the bootloader
[08:10:10] <antto> and i took the code from the firmware where it works
[08:10:29] <braincracker> you do not put interrupt code in bootloader i tihnk
[08:10:41] <antto> so either that's not _all_ of the code required to make the midi work properly, or something else (part of the bootloader) is breaking it
[08:10:51] <antto> oh?
[08:11:03] <antto> bootloaders are not supposed to have interrupt stuff?!
[08:11:55] <braincracker> good question, i never even had a bootloader
[08:12:25] <antto> well if that's true, it would explain why it doesn't wanna work
[08:14:00] <antto> braincracker what version is your avrgcc?
[08:14:05] <braincracker> antto<=
http://blog.schicks.net/wp-content/uploads/2009/09/bootloader_faq.pdf
[08:15:16] <braincracker> "you just need to tell the CPU to jump to the interrupt vectors positioned within the bootloader rather than the vectors within the application"
[08:16:08] <antto> O_o
[08:16:18] <antto> what does all this mean?
[08:17:17] <braincracker> you need to setup the interrupt vector table if you want to use it
[08:18:28] <braincracker> bootloader loads the progam code... interrupt vector table is normally at the beginning of program code...
[08:19:22] <antto> using interrupts in a bootloader is different than using them in a firmware?
[08:20:03] <braincracker> no
[08:20:13] <braincracker> it is the same interrupt table
[08:20:31] <braincracker> but the bootloader interrupt pointers are in the bootloader area
[08:21:12] <braincracker> and you want to write program memory anyway
[08:21:56] <antto> uhm, to keep it simple, ignore the fact that i want to update the firmware via MIDI
[08:22:14] <antto> i just want to get the midi port "working"
[08:23:03] <antto> i need some additional code which sets up the "interrupt vector table" ?
[08:23:18] <braincracker> i'm not sure it is cool to run interrupts from program code while bootloading
[08:23:39] <antto> what do you suggest then?
[08:24:14] <braincracker> run it from bootloader first...
[08:24:36] <antto> run what?
[08:24:36] <braincracker> after bootloading done, jump to program code.
[08:24:52] <antto> this functionality already works
[08:25:10] <antto> i mean, the bootloader uses the other UART with an FTDI -> USB -> avrdude
[08:25:32] <antto> aka it self-programs via avrdude
[08:31:33] <antto> oh i found this thing you quoted, inserted "MCUCR = (1<<IVCE); MCUCR = (1<<IVSEL);" in main() and will test it now..
[08:33:06] <antto> oh sh*t, it works now \o/
[09:05:31] <braincracker> science works
[09:07:22] <braincracker> http://xkcd.com/54/
[09:07:24] <braincracker> ;>>
[09:09:25] <antto> braincracker but is it not a good idea to use interrupts in a bootloader?
[09:09:55] <braincracker> why not?
[09:10:00] <antto> i don't know
[09:10:15] <braincracker> just change back the interrupt vector pointer after you finished booting.
[09:10:25] <antto> oh?!
[09:10:29] <antto> eek
[09:23:07] <Casper> antto: there is 2 vector tables points, by default it's the one at 0x0000
[09:23:25] <Casper> but you can set a bit in one register to set it to the bootloader address
[09:24:40] <Casper> it's a very bad idea to use interrupts in the bootloader with the vector at the start, but perfectly fine if you set it to the bootloader part.... but remember to actually switch it back to the main code before jumping there (and disabling them most probably)
[09:25:51] <antto> so how do i set them back?
[09:26:09] <antto> MCUCR = 0; MCUCR = 0; ? ;P~
[09:26:28] <antto> oh, that's the same variable
[09:27:23] <Casper> you basically answered yourself there :D
[09:27:33] <antto> set the variable to zero?
[09:28:28] <Casper> I forgot if it default to 0 or 1.... but it's like set to 0 for main and 1 to bootloader.... or it's the inverse....
[09:28:58] <Casper> so at the begening set to like 1, at the end you set it back to 0, after having disabled your used interrupts and global interrupts
[09:29:36] <Casper> time to make a few phone calls
[09:31:43] <GuShH> Casper: calling the time lady?
[09:32:22] <Casper> first call done... man... can't understand what that guy say....
[09:33:08] <Casper> he dosen'T speak well, and speak too loudly so the phone distortion....
[09:33:33] <GuShH> tell him the phone goes on his face not his arse
[09:34:19] <antto> hahah
[09:44:16] <Casper> this look like a boring week
[09:44:37] <Casper> 30 minutes that the store is open after a long week end...
[09:44:43] <Casper> ... still zero call, zero client
[09:48:09] <Casper> yay! first call!.... we don't have what the guy wanted... so no order :/
[09:51:01] <RikusW> http://www.youtube.com/watch?v=8O89GPVbJm4
[09:53:12] <Casper> http://www.youtube.com/watch?v=PN_WMG2Q5pQ :D
[09:55:47] <antto> Casper surely as you said, the firmware fails to work for some reason
[09:56:07] <antto> and MCUCR = 0; didn't work
[09:57:37] <braincracker> [151434] <antto> oh i found this thing you quoted, inserted "MCUCR = (1<<IVCE); MCUCR = (1<<IVSEL);"
[09:57:48] <braincracker> this is not a simple bitmasking function...
[09:59:45] <antto> it looks like voodoo to me
[10:00:13] <Casper> learn voodoo
[10:00:14] <antto> no idea what it does or how it works, but my midi interrupt started working
[10:01:54] <OndraSter> it moves the interrupt table to BL
[10:02:57] <antto> but how do i move it back afterwards
[10:03:13] <OndraSter> (1 << IVCE), 0
[10:04:53] <Casper> foo |= (1<<bar); ← set bit bar in register foo
[10:05:07] <Casper> foo &= ~(1<<bar); ← clear bit bar in register foo
[10:05:21] <antto> Casper yeah, i know the bitwise ops
[10:06:07] <Casper> some registers however have some protection and require 2 write to it
[10:06:32] <Casper> first a "protect disable" bit, then within a few cycle you set what you want
[10:06:51] <Casper> for those, it might be wise to disable the interrupts if you use them
[10:06:58] <Casper> and reenable after
[10:07:06] * Casper wonders
[10:07:19] <antto> while messing with the MCUCR variable?
[10:09:06] <braincracker> http://www.youtube.com/watch?v=1ucSu8MJY94
[10:09:10] <braincracker> Milk Inc. - Undercover
[10:09:15] <Casper> http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html#ga072040fce54f112355cb9ebf9ce41dd7
[10:09:26] <Casper> this might actually be it
[10:09:36] <Casper> brb
[10:12:30] <antto> i got confused
[10:14:01] <antto> if you mean to cli() and sei() around the operations on MCUCR - that won't be an issues, since i'm only touching MCUCR in the very beginning of main() before i ever call sei(), and then again at the very end, after i call cli(), before jumping to the firmware
[10:14:23] <antto> * if i understand what's going on correctly
[10:14:56] <braincracker> but you want to set it back
[10:15:00] <braincracker> and you eanbled interupts
[10:15:24] <antto> what, when?
[10:15:53] <braincracker> at least you know what you are doing
[10:16:01] <Casper> at the end
[10:16:07] <Casper> before jumping to your code
[10:16:19] <Casper> you want to set it back to the main interrupt vector table
[10:16:30] <antto> yes, well i added the code which OndraSter suggested
[10:16:54] <antto> and i put that code _after_ cli() but before the actual jump to main
[10:16:59] <antto> ehm, jump to firmware
[10:21:11] <Casper> the firmware is the full flash content
[10:21:20] <Casper> so better call it main and bootloader
[10:22:14] <antto> i called it firmware cuz it's on address 0
[10:22:22] <antto> and to not confuse it with main()
[10:22:45] <antto> so the firmware works now
[10:22:50] <antto> yey
[10:53:46] * Casper wonders who decided to call that "firmware"....
[10:54:26] <Casper> maybe because software imply that it can change? and a software burned in rom can't change so isn't soft but firm?
[10:55:57] <antto> no idea
[10:56:08] <antto> i just don't want additional confusion ;]
[10:56:26] <antto> sometimes i call it "OS" cuz it's shorter and more fancy
[10:57:22] <antto> but interpret "main" as "main()" and that's present in both the firmware and bootloader (and most programs anyway)
[10:58:09] <antto> so i should have just said "before the actual jump to 0x0000" ;P~
[10:58:40] <Casper> OS is totally wrong
[10:58:57] <antto> but mortal users seem to interpret it as "firmware" ;]
[10:59:52] <antto> i have a device similar to the one i'm working on, but that one is commercial, made by a big company
[11:00:00] <antto> and they call it "OS update"
[11:00:19] <antto> their device is 32bit i think
[11:00:34] <antto> it has digital audio synthesis and sh*t
[11:04:07] <Casper> if it's 32 bits, chance that it run a real OS
[11:04:30] <Casper> avr 8 bits is too ressource limited to proprelly run an os
[11:04:30] <antto> oh?
[11:05:12] <antto> i've updated the so called "OS" on that device, and it was a very small file
[11:05:13] <antto> iirc
[11:05:33] <Casper> how small?
[11:06:15] <Casper> a meg?
[11:06:40] <antto> 384kB
[11:06:59] <Casper> still possible to be an os
[11:07:21] <Casper> specially if they compressed it
[11:07:33] <antto> it's not compressed
[11:07:40] <Casper> which is sometime the case... compressed and encrypted
[11:07:51] <Casper> why do you say it's not compressed?
[11:07:53] <antto> btw i'm not sure it's a 32bit device, i'm just guessing
[11:08:11] <antto> because you need proper power to do realtime DSP processing
[11:08:28] <antto> like audio recording, streaming and effects
[11:08:36] <Casper> the firmware file can be compressed
[11:08:46] <Casper> and decompressed and decrypted by the booloader
[11:08:53] <antto> Casper i see stuff like 00 00 00 00 00 FF FF FF FF inside
[11:09:05] <antto> if it was compressed wouldn't it look like random values? ;]
[11:09:23] <Casper> maybe, or not
[11:09:24] <braincracker> no
[11:09:32] <braincracker> compressed does not mean random.
[11:09:43] <Casper> I've seen compressed that have repetitive data
[11:09:55] <Casper> it all depend on the algo used
[11:10:22] <antto> i know but, i would think it's rare to get the output to not look random
[11:10:54] <antto> and especially to have long chunks of repeating values
[11:11:26] <Casper> maybe they didn't care about securing anything
[11:11:32] <Casper> or was too lazy :D
[11:12:00] <Casper> and yes... sadly even a simple compression does help for security
[11:12:04] <braincracker> no such thing as "securing data"
[11:12:07] <antto> it looks _very_ much like the contents of a .hex file, except it's not a hex but raw binary
[11:12:33] <antto> the data at the very end is all FF FF FF
[11:13:01] <antto> basically, you can't do anything with this
[11:13:18] <antto> what will you steal from their code? ;]
[11:13:44] <antto> it's a relatively cheap device from about 10 years ago
[11:14:12] <braincracker> who cares about copying a led flasher code?
[11:14:28] <braincracker> and who the fuck disassembles things like that?
[11:14:51] <braincracker> you usually want to change code, not just copy
[11:14:58] <antto> yeah
[11:15:14] <antto> i'm 99% sure it's raw, not compressed not even encoded
[11:15:29] <braincracker> machine code then.
[11:15:33] <antto> yup
[11:15:51] <braincracker> FF FF FF FF < that is unprogrammed region
[11:16:33] <antto> they have some sort of a bootloader too, because it self-programs.. the "OS" has to be placed on a SmartMedia card and then you power-up the device while holding two keys
[11:17:09] <jadew> what are you guys talking about?
[11:17:36] <antto> jadew about the words "Firmware" "OS" "main" and such
[11:17:38] <Casper> jadew: nothing, really, nothing about you, I swear!
[11:18:10] <jadew> ah ha, so you're talking about me, behind my back
[11:18:26] <Casper> I swear! I did not!
[11:18:48] <Casper> don't scroll up, you won't find anything!
[11:19:14] <jadew> I believe you
[11:19:40] <antto> *COUGH* *cough*
[11:20:19] <jadew> well, firmware is whatever runs directly on the chip, OS implies interface and API for higher level programs, main... main is just the entry point of a program, be it firmware or any kind of stand alone program
[11:20:44] <jadew> where's the confusion?
[11:21:51] <antto> my device, it has many buttons, LEDs, usb/midi all kinds of funky things
[11:22:10] <antto> it runs on an atmega162 or atmega2561
[11:22:15] <Casper> but the firmware can be in 2 parts, main code and bootloader
[11:22:19] <antto> so should i call it OS or Firmware?
[11:22:41] <Casper> antto: firmware, not OS...
[11:22:48] <jadew> antto, does it act as a hardware access layer, providing APIs for other programs that run on top of it?
[11:22:53] <jadew> if no, it's a firmware
[11:23:03] <jadew> or a library at best
[11:23:06] <antto> uhm, hardware access layer?
[11:23:17] <jadew> yeah, because that's what an OS provides
[11:23:35] <jadew> it provides an interface to the hardware, trough exposed APIs for the userland programs
[11:23:43] <Casper> to make it more simple: is there more than one program?
[11:23:56] <Casper> (bootloader excluded)
[11:24:04] <antto> ah, if you mean that an OS can run "smaller" programs, then no, this thing certainly doesn't do such things
[11:24:14] <Casper> so more than 2 able to run a the same time
[11:24:28] <jadew> well, they don'
[11:24:33] <jadew> don't have to run at the same time
[11:24:38] <antto> nah, it does whatever is programmed in the firmware or bootloader
[11:25:07] <jadew> what do all OSes do?
[11:25:10] <jadew> they load programs
[11:25:20] <jadew> that's something common across the board
[11:25:23] <antto> then the other device i mentioned, it can't be an "OS" either
[11:25:44] <jadew> so if you can load a program from that firmware and provide APIs to access the hardware to that program, then it's an OS
[11:25:56] <antto> yeah, i get it now
[11:26:37] <antto> OS is like a host for programs
[11:27:07] <antto> firmware doesn't host anything
[11:27:23] <specing> APIs for accesing hardware don't make sense when you don't have a mmu
[11:27:38] <jadew> mmu?
[11:27:43] <antto> mmu^2?
[11:28:06] <Casper> did you hear that?
[11:28:12] <Casper> the explosion?
[11:28:18] <antto> where?
[11:28:21] <Casper> that was a client bubble that I bursted
[11:28:56] <antto> O_o
[11:29:13] <Casper> "I want a gamer laptop for under 500$, because those acer are too expensive! I saw one at 387$... too expensive!"
[11:29:52] <Casper> told him a good gamer laptop is over 1000$, under that it's not worth it
[11:30:14] <Casper> I think he expected a gamer laptop for 200$ or less...
[11:30:21] <Casper> with 8-10G ram and all that
[11:30:40] <jadew> gamer laptop?
[11:30:58] <jadew> who would want to play games on a laptop? lol
[11:31:15] <Casper> kids
[11:31:35] <specing> Casper: you can have a $250 gamer laptop if all you want to play is minesweeper
[11:32:04] <jadew> kids shouldn't be alowed to play too many games
[11:32:04] <Casper> sure, however not the shooter of the year...
[11:32:12] <jadew> lol
[11:32:26] <specing> I can still play the shooter of the year on my 6 years old laptop ;P
[11:32:38] <specing> on *very* low, but still...
[11:32:38] <Casper> shooter of the year 1995? :D
[11:32:41] <jadew> with a whooping 3fps
[11:32:50] <specing> 2013 with >60 fps
[11:33:40] <Casper> ah write test done on that hd, time to start the read test...
[11:34:27] <jadew> specing, what kind of laptop is that?
[11:34:37] <Casper> man today seems to be a looong day
[11:34:52] <Casper> should have brought some sand paper and mastic for the car...
[11:35:10] <jadew> Casper, you tell me... I've been to the dentist today, that hour already counts as 2 regular days
[11:37:45] <specing> jadew: a gaming one >$1000, obviously!
[11:38:18] <jadew> my PC never seems up to date for this kind of stuff
[11:38:32] <specing> Did you build it yourself?
[11:38:35] <jadew> yeah
[11:38:50] <specing> how much?
[11:39:01] <jadew> don't know.. several k
[11:39:05] <specing> 0.o
[11:39:14] <specing> What did you put in it?
[11:39:33] <specing> (as a rule of thumb, > $1000 PCs are not worth it)
[11:39:37] <jadew> don't get me wrong, it can play a lot of games, just not all of them at top quality
[11:40:59] <jadew> well, I have a 6 core cpu, 2 x video cards (1 x gtx 550, 1 x nv 8600), 5 hdds, 16gb ram, water cooling
[11:41:15] <jadew> a decent sound card and that's about it
[11:41:49] <specing> 8600? did you reflow it yet?
[11:42:00] <jadew> hehe, didn't need to, still working fine
[11:42:22] <jadew> they're known to cause problems?
[11:42:30] <specing> yes
[11:42:35] <specing> I had to reflow mine
[11:42:41] <specing> 8600 M GT @ laptop
[11:43:05] <jadew> interresting, what are the symptoms?
[11:43:41] <Casper> specing:
[11:43:51] <Casper> specing: >1000$ comp does worth it
[11:44:23] <jadew> yeah, about that, it depends on what you do with it
[11:45:00] <jadew> I'm not using mine to play games (I do, but that's not the main purpose - altho that's why I got the gtx card)
[11:45:12] <specing> Its not worth it
[11:45:19] <specing> seriously
[11:46:04] <jadew> sure it is, a bad ass pc, an awesome keyboard and a good chair are a must for any programmer
[11:46:21] <jadew> any of that fails and you'll end up getting pissed off for the wrong reasons
[11:47:03] <specing> Its better to buy 3 slower computer for the money and link them together
[11:47:09] <specing> and you have better redundancy
[11:47:14] <jadew> also, reducing the compile time is a good reason to get an expensive pc
[11:47:24] <specing> distcc ;D
[11:48:02] <jadew> well, I don't mind it all happening on the same PC, on several threads :)
[11:49:04] <jadew> also, I didn't build it all at once
[11:49:26] <specing> 3*8 threads on commodity hardware > 1*12 threads on your super-duper PC
[11:50:45] <jadew> that's probably true, but I don't think it's possible with VC (haven't looked into it)
[11:51:19] <jadew> but this brings us to a previous disscussion, how could would it be to have a fpga farm that compiles c++? :D
[11:51:43] <jadew> *cool
[11:51:45] <jadew> how cool
[11:53:07] <jadew> would be hard/expensive to implement I guess
[11:55:55] <specing> jadew: very
[12:22:29] <braincracker> lold on gaming laptop
[12:22:52] <braincracker> unless you mean strategy
[12:23:11] <braincracker> redalert and such are fine, but do not expect things like FEAR
[12:23:15] <braincracker> STALKER
[12:29:15] <antto> someone earlier said something about disabling two "kinds" of interrupts
[12:29:32] <braincracker> level trigger, edge trigger
[12:29:53] <antto> hm
[12:30:17] <antto> doesn't cli() disable all interrupts?
[12:30:30] <braincracker> it does
[12:30:51] <braincracker> after exiting the current ISR ;)
[12:31:22] <antto> maybe that's not related to my problem then
[12:31:39] <braincracker> you seem to have many problems
[12:31:53] <antto> someone also said that i should set the so called interrupt vector _before_ jumping to the firmware
[12:31:55] <braincracker> dr h4x ;/
[12:32:46] <braincracker> i have 7 tracks remaining
[12:44:52] <antto> tracks?
[12:45:27] <braincracker> Milk inc - Undercover
[12:45:44] <braincracker> number of tracks: 21
[12:59:01] <braincracker> bb
[12:59:47] <antto> is that Milk from Milk n Sugar?
[12:59:50] <TehGookstuh> So I have a question. I'm using the Atmega324p and for some reason my spi clock doesn't work. any ideas?
[13:01:41] <Tom_itx> is spi enabled in the fuses?
[13:08:23] <TehGookstuh> in the status register is that what you mean by fuses
[13:08:24] <TehGookstuh> then yes
[13:08:46] <TehGookstuh> control register*
[13:20:45] <antto> TehGookstuh no, fuses are something else
[13:21:18] <TehGookstuh> what are fuses then?
[13:21:32] <TehGookstuh> the power reduction registers?
[13:21:38] <antto> well, they aren't part of your code
[13:23:04] <TehGookstuh> oh this is interesting
[13:23:10] <TehGookstuh> how do I check the fuses then>?
[13:23:21] <antto> do you have a programmer?
[13:23:31] <TehGookstuh> yes
[13:23:35] <TehGookstuh> AVR pocket programmer
[13:23:47] <antto> with that then
[13:24:15] <antto> just be extremely careful with fuses, if you change their values without care - you can brick the chip
[13:24:24] * antto knows from experience
[13:24:56] <antto> to read their values, you can use terminal mode
[13:26:13] <antto> then paste their values into this:
http://www.engbedded.com/fusecalc
[13:26:17] <antto> to see their meaning
[13:26:44] <TehGookstuh> thanl you :)
[13:28:28] <antto> what Tom_itx asked you about should be "SPIEN" i think
[13:30:06] <TehGookstuh> thanks
[14:08:55] <TehGookstuh> antto what would be the next step if SPI_EN is set in the fuses?
[14:13:59] <antto> if that's set, i guess it's up to the actual code
[14:14:10] <antto> and maybe the analogue voodoo
[14:14:16] <TehGookstuh> lol
[14:14:18] <TehGookstuh> ;(
[14:14:40] <antto> i'm not very competent to give the answer, as i'm in a fog myself ;]
[14:15:24] <TehGookstuh> ;(
[14:15:51] <TehGookstuh> what sucks is this is the actual first embedded thing I've done
[14:15:57] <TehGookstuh> so I really don't know if the code is right either
[14:15:59] <TehGookstuh> >_>
[18:07:02] <ozzzy> evening all
[18:08:20] <ozzzy> would an atmega328 running at 3.3v be tolerant of 5v ttl on the IO pins
[18:10:10] <IanCormac> No
[18:10:13] <IanCormac> It would not
[18:10:57] <IanCormac> If the voltage on a pin exceeds Vcc by too much (a small threshold), the clamping diodes will activate and nothing good will come of that
[18:13:06] <ozzzy> IanCormac: thanks.... I'll have to build in some buffers =)
[18:13:21] <IanCormac> You can just use a resistor divider if you want
[18:13:26] <ozzzy> yep
[18:13:31] <IanCormac> Or a voltage drop diode
[18:13:36] <IanCormac> that's pretty expensive and ghetto, though
[18:13:49] <ozzzy> either I run the avr at 5 and buffer the serial to the rpi... or I run it at 3.3 and buffer a lot more
[18:14:02] <IanCormac> Yeah, definitely buffer to the rpi
[18:14:20] <IanCormac> You only need to divide the arduino's TX pin
[18:14:25] <IanCormac> everything else will work as-is
[18:14:38] <IanCormac> the arduino can receive 3.3v from the rpi just fine
[18:14:46] <ozzzy> that's what I was hoping to do... =)
[18:14:53] <ozzzy> a divider it is
[20:33:35] <damjan> isn't the R-pi 3.3 V ?
[20:52:01] <Casper> afaik, yes it is