Back
[09:03:39] <rue_more> my printer broke
[09:03:44] <rue_more> and I'm sick as a dog
[09:03:59] <Lambda_Aurigae> what broked on the printer?
[09:04:25] <rue_more> my quartz head shattered, simple to fix, but it rufuses to work again
[09:04:29] <Lambda_Aurigae> come down here and pick up a few from me. I have half a dozen working in good condition B&W laser printers.
[09:04:42] <Lambda_Aurigae> quartz head?
[09:04:49] <Lambda_Aurigae> what kind of printer?
[09:04:52] <rue_more> oh, 3d printer
[09:04:56] <rue_more> :)
[09:04:56] <Lambda_Aurigae> oh.
[09:05:01] <rue_more> ofcourse :)
[09:05:22] <Lambda_Aurigae> well, if you print on a sheet of paper enough times with a laser printer it will do 3D print.
[09:05:45] <rue_more> little too much cutting and glueing for me
[09:11:17] <tpw_rules> there's no magic way to inhibit the flag setting of an instruction is there
[09:11:52] <Lambda_Aurigae> tpw_rules, probably not...each instruction sets flags as it is hardware configured to do.
[09:12:12] * tpw_rules likes his arm optional flags
[09:12:27] <Lambda_Aurigae> much more complex processor there.
[09:13:21] <Lambda_Aurigae> optional flags would complicate the ARM core considerably. Adding 50% to the ALU core at least.
[09:13:44] <tpw_rules> yeah
[09:13:58] <tpw_rules> why would it add that much? the problem would be is the instructions are too narrow
[09:14:06] <Lambda_Aurigae> the AVR ALU is very simple really.
[09:15:01] <Lambda_Aurigae> making flags optional for each command would add considerable circuitry to each command's hardware.
[09:15:35] <tpw_rules> the parallax propeller can do it but it's just two bits always there so it's basically a gate that inhibits write (probably)
[09:15:52] <tpw_rules> i wish i could will instructions into existence. i need a "set bit in i/o register according to carry"
[09:17:53] <Lambda_Aurigae> if you were to do it globally for all commands to one flag then it wouldn't be so difficult...but doing it for each individual flag on each individual command would be horrid...literally gates for every bit and every command.
[09:18:07] <rue_more> so test the carry flag and jump over the instructions to set the io bit if its not set
[09:18:29] <rue_more> if thats what you mean
[09:19:08] <tpw_rules> well i can do that but i also have to clear it and the cycle wastage makes me sad, especially since it takes as long to service and return the interrupt as it does to execute
[09:19:35] <tpw_rules> Lambda_Aurigae: it would be easy if there were a couple bits spare in each instructiomn but they're already pretty crunched
[09:19:53] <Lambda_Aurigae> yup.
[09:20:04] <rue_more> have you ever seen MMX instructions?
[09:20:22] <rue_more> the most obscure junk you could ever imagine
[09:20:28] <Lambda_Aurigae> hehe.
[09:20:30] <Lambda_Aurigae> yeah.
[09:20:34] <tpw_rules> yup
[09:20:59] <Lambda_Aurigae> designed by committee of people who never did any multimedia programming
[09:21:12] <rue_more> if this value is bigger than that one and this flag is set then increment this register and copy this value to there
[09:21:33] <rue_more> rlly?!?
[09:21:33] <tpw_rules> and even intel can't figure out how many clock cycles that will take
[09:21:42] <Lambda_Aurigae> yeah.
[09:21:57] <rue_more> heh, it takes 1, how many clock cycles that is nobody knows
[09:21:58] <Lambda_Aurigae> some of those commands are variable clock cycles depending on what flags or input values and such.
[09:22:47] <Lambda_Aurigae> problem is there is a RISC core underlying the CISC frontend.
[09:22:54] <rue_more> more rediculus than the Z80 search instructions
[09:23:14] <Lambda_Aurigae> and the CISC/RISC interface is,,,,horrendous.
[09:23:16] <tpw_rules> and how that translates to real time depends on planetary alignment since you might stall a pipeline or miss a cache or the last three instructions had an opcode value < 0x84
[09:24:21] <Lambda_Aurigae> the x86 instruction set is bad enough as it is.
[09:24:29] <tpw_rules> i think we shoudl start using forth cores. 144 on a single chip
[09:26:40] <Lambda_Aurigae> C interpreter in hardware.
[09:27:06] <malinus_> rue_more: what was wrong with the search instructions :(
[09:30:29] <tpw_rules> now for more fun: designing a robust self programming protocol over a really weird serial link
[09:30:33] <rue_more> nothing, I liked them, I thought that was cool, but they are crazy
[09:31:31] <Lambda_Aurigae> tpw_rules, look at the programming protocol for the first generation lego mindstorms over IR...it's robust as hell.
[09:31:52] <tpw_rules> well the problem is not bricking anything
[09:32:43] <tpw_rules> i have to emulate spi in software because the device can generate messed up clock signals that i need to reject
[09:33:31] <tpw_rules> and how to not accidentally enter programming mode but still make it easy enough to detect that it's not too slow and what happens if it fails and etc
[09:36:00] <Lambda_Aurigae> challenge/response system for entering programming mode.
[09:36:36] <Lambda_Aurigae> I have a self-programming system in mind that should be lots of fun to implement.
[09:37:24] <tpw_rules> it has to withstand all sorts of bullshit and still be fast. that's why i'm fretting over shaving cycles off interrupts
[09:37:30] <Lambda_Aurigae> add an external spi sram...send the entire program over, do a verify, then have the chip go into bootloader mode and pull the data from the spi sram.
[09:37:48] <tpw_rules> it's also on an attiny so i don't even get a bootloader. and i have way not enough pins for that
[09:38:30] <Jartza> I do self programming on attiny with one pin
[09:38:33] <Jartza> and over audio :)
[09:38:54] <tpw_rules> can you dedictate a pin to it? and that's pretty schweet
[09:39:08] <tpw_rules> i'm building a ps/2 mouse/keyboard to controller converter for a nintendo entertainment system
[09:39:12] <Jartza> tpw_rules:
http://labs.rakettitiede.com/?p=87
[09:40:31] <tpw_rules> there's something wrong with your website and it's really wide horizontally
[09:41:28] <Jartza> hmm?
[09:41:31] <Lambda_Aurigae> looks ok from here.
[09:41:32] <Jartza> not on any browser I have
[09:41:47] <tpw_rules> well i can scroll like two screens over on firefox
[09:41:47] <Jartza> ok with chrome, firefox, safari and IE
[09:42:07] <Lambda_Aurigae> firefox works fine here.
[09:42:11] <tpw_rules> oh huh it fixes itself if i enable javascript
[09:42:19] <Jartza> ahh yeah
[09:42:27] <Lambda_Aurigae> javakrap.
[09:42:27] <Jartza> it's "responsive", javascript required though
[09:42:33] <tpw_rules> yeah eugh
[09:42:45] <Lambda_Aurigae> why do people use javakrap for static web pages?
[09:42:56] <tpw_rules> i wish i knew
[09:43:57] <tpw_rules> other disadvantage of attiny: i can't use like port d as debugging
[09:47:37] <Jartza> Lambda_Aurigae: that you need to ask from the creator of wordpress :)
[09:50:28] <NicoHood> I am very confused. Can someone check if i just dont understand the datasheet or if the datasheet has wrong values?
http://www.atmel.com/Images/doc7799.pdf page 290 the PLLCSR register has PLLP0-2 and on page 40 there are different names. And when i try to compile a u2 series device then the PINDIV in page 40 is not declared?! what is going wrong here?
[10:06:57] <Jartza> I've found several bugs from atmel datasheets, and reported them back
[10:12:18] <NicoHood> Jartza: did they correct it?
[10:12:23] <Jartza> eventually yes
[10:13:01] <Jartza> NicoHood: what compiler and libc you are using?
[10:13:12] <NicoHood> Arduino environment
[10:13:21] <NicoHood> so its a g++ or gcc
[10:13:30] <NicoHood> 1.5.8
[10:13:32] <Jartza> and what chip?
[10:13:51] <Jartza> iom32u4.h
[10:13:51] <Jartza> 318:#define PINDIV 4
[10:14:33] <Jartza> at least I have that #define, but seems to be only for 32u4
[10:14:50] <NicoHood> 16u2
[10:15:03] <NicoHood> the u2 series in general
[10:15:09] <NicoHood> 8, 16, 32u2
[10:15:38] <Tom_itx> you're not using flip or DFU to program it?
[10:15:52] <NicoHood> nope
[10:16:04] <Tom_itx> ditch the bootloader?
[10:16:10] <NicoHood> i made my own arduino compatible cdc bootloader + usb serial
[10:16:20] <NicoHood> https://github.com/NicoHood/HoodLoader2
[10:16:31] <NicoHood> i can reprogram both mcus now :) via arduino environment
[10:16:49] <NicoHood> or via avrdude
[10:16:51] <Jartza> #define PLLCSR _SFR_IO8(0x29)
[10:16:51] <Jartza> #define PLOCK 0
[10:16:51] <Jartza> #define PLLE 1
[10:16:51] <Jartza> #define PLLP0 2
[10:16:51] <Jartza> #define PLLP1 3
[10:16:53] <Jartza> #define PLLP2 4
[10:16:57] <Jartza> 16u2 has those defines
[10:17:10] <NicoHood> Jartza: okay. well then the datasheet is wrong?
[10:18:47] <Jartza> dunno, I have neither of those chips :(
[10:19:05] <Jartza> just looking at what my board defines say
[10:19:48] <Jartza> bit strange that they are different, when datasheet doesn't exactly say that those should be different between 16u2 or 32u2
[10:22:48] <Jartza> either the avr library is incorrect, or the datasheet
[10:22:50] <Jartza> not sure which :(
[11:59:33] <malinus_> Jartza: what avr library?
[12:00:02] <malinus_> you mean libc for avr?
[12:47:07] <Jartza> malinus_: yes, that
[16:06:51] <DO9XE> Hey there :) I need someone, who ist really good with LUFA on an xMega64a3u :) It's not working and i have no Idea why :/