Back
[00:23:48] <inflex> hiya Tom_itx
[05:13:01] <l9> :) morning all :) anyone that knows if there is a chan just for raspberry pi?
[05:13:23] <aep> l9: #raspberrypi
[05:15:28] <l9> aep: thanks :)
[06:31:39] <catphish> i'm a little confused by timer speeds, I am running this code to use timer0 of an atmega:
http://pastebin.com/LnZp8Eic
[06:33:20] <catphish> i'd expect the timer to run at at least 1MHz, and with an 8bit timer, i'd expect my overflow to get fired often (at least 7KHz)
[06:33:46] <catphish> but instead i'm seeing the interrupt fired at 1Hz
[06:35:49] <catphish> actually i need to look at this closer, i believe i'm mistaken!
[06:47:19] <catphish> oh, seems the problem is that i call a method called micros(), and i forgot my include for it, but it linked it with some other micros function, i'm not sure where from :(
[06:53:27] <catphish> oh, it's implicit function declaration, but it doesn't link corectly
[06:54:15] <catphish> that'll teach me to turn on -Wall
[07:14:37] <aep> any idea what could be wrong if i get no voltage from usart? the pins work fine as regular gpios and print() at 300 baud is visibly slow, so something is happening
[07:18:22] <aep> actually the baudrate has no effect on how fast print() is. weird
[07:25:52] <megal0maniac_afk> aep: Code?
[07:26:14] <_abc_> So what's the consensus to write main() prototype in avr-gcc to avoid a warning?
[07:26:22] <_abc_> int main( int argc, ... )
[07:26:33] <_abc_> is a waste, main never returns.
[07:26:37] <aep> megal0maniac_afk:
http://npaste.de/p/GdDh
[07:26:50] <_abc_> Also using the pragma for that still does not remove the warning completely, I get another instead.
[07:32:34] <megal0maniac_afk> aep: This looks overly complicated
[07:32:43] <aep> yeah. let me reduce
[07:33:01] <megal0maniac_afk> Oh! AVR32
[07:33:16] <aep> that too
[07:33:48] <aep> i need a fricking i2s<>usb thing, and this is the only chip i have that is fast enough :/
[07:34:59] <aep> less code:
http://npaste.de/p/XeV
[07:36:01] <catphish> i use int main(void)
[07:36:08] <catphish> doesn't generate any warnings afaik
[08:18:23] <Duality> catphish: why would it ?
[08:19:01] <catphish> Duality: _abc_ asked
[08:20:21] <Duality> there is a compiler flag which disables return from main
[08:23:33] <Duality> what works though is a main without return but with a call to its self. like:
[08:23:45] <Duality> int main(void){main();}
[08:32:01] <_abc_> I seem to get a warning no matter what I try. I will post more Monday probably.
[11:52:06] <Dreamer3> anyone have experience with assembly? i'm compiled this boot loader but the code it's generating doesn't look right... none of the jump instructions are correct
[11:54:27] <specing> yes
[11:55:14] <Dreamer3> hmmm
[11:55:17] <Dreamer3> weird
[11:55:24] <Dreamer3> the binary file is ok, but .o and .hex are wrong
[11:55:45] <myself> I think we're about to learn something about how linkers work :)
[11:56:17] <myself> (I have no idea, I popped in to eavesdrop on the convo because I'm curious too)
[11:56:22] <Dreamer3> the linker shouldn't rewrite all the rumps to +0
[11:56:30] <Dreamer3> https://code.google.com/p/picoboot/
[11:56:33] <Dreamer3> i'm trying to compiled this
[11:59:36] <specing> myself: thats alright, I hate linkers, too
[11:59:44] <specing> especially the GNU one
[12:01:12] <Dreamer3> http://pastie.org/8600838
[12:01:18] <Dreamer3> source vs output
[12:01:28] <Dreamer3> ;look at what is happening to the rcalls to SPIxfer
[12:05:28] <megal0maniac_afk> Bought one of these
http://www.ebay.com/itm/161180119731
[12:06:16] <megal0maniac_afk> JTAG is accessible, and it's an awesome LUFA experimenter board. For under $5
[12:06:23] <megal0maniac_afk> Shipping incl.
[12:07:20] <specing> megal0maniac_afk: $1.15?!
[12:07:24] <specing> How so cheap?
[12:08:24] <specing> free shipping?
[12:08:30] * specing shakes megal0maniac_afk
[12:08:32] <megal0maniac_afk> specing: If you buy 2, the shipping cost doubles. So it's effectively AU$5.27 with free shipping
[12:08:47] <megal0maniac_afk> Free shipping for you?
[12:09:05] <specing> it says $1.15
[12:09:19] <megal0maniac_afk> Yeah, but mine also says $3.99 shipping
[12:09:39] <specing> Eh, it says shipping $3.4
[12:09:57] <specing> thats like 3x the board!
[12:10:35] <megal0maniac_afk> They just draw you in with the cheap item price
[12:11:08] <megal0maniac_afk> Read it as $5.27 with shipping included (which is US$4.73)
[12:11:25] <megal0maniac_afk> Which is still awkwardly cheap
[12:12:16] <tigarab> what do you tell avrdude what device it is
[12:13:12] <megal0maniac_afk> tigarab: I think arduino, if it's the standard bootloader. But I'll most likely be using JTAG
[12:14:16] <tigarab> nice find
[12:14:50] <tigarab> Do i really need 20 wires to do parallel high voltage programming?
[12:15:20] <tigarab> i only bought 10 male-female wires. god dammit
[12:16:03] <megal0maniac_afk> tigarab: Yeah, sorry. 8 control, 8 data, VCC, GND
[12:16:24] <megal0maniac_afk> And maybe RST
[12:16:27] <megal0maniac_afk> I can't remember
[12:16:34] <tigarab> Wow
[12:16:42] <megal0maniac_afk> It is 8bit parallel
[12:17:08] <tigarab> Should have bought a zif socket for my dragon
[12:17:19] * megal0maniac_afk doesn't understand why they didn't just use HVSP for all devices
[12:18:12] <megal0maniac_afk> From what I understand, HVSP is just ISP. Except the 12V forces programming mode regardless of fuses
[12:21:55] <tigarab> What are the zif sockets without zero force called?
[12:23:02] <vectory> sockets?
[12:24:02] <megal0maniac_afk> Lol
[12:25:28] <megal0maniac_afk> Sometimes called tulip sockets (the ones with cylindrical recepticles)
[12:25:31] <specing> tigarab: you need 20 wires for HVPP
[12:25:37] <specing> you don't need 20 for HVSP
[12:26:02] <megal0maniac_afk> specing: He did say parallel
[12:27:59] <specing> well then
[12:28:04] <specing> hes f*cked
[12:28:08] <megal0maniac_afk> :)
[12:30:07] <megal0maniac_afk> Oh look, they do use all 20. Additional 4 are XTAL, RESET, VCC, GND
[12:35:17] <Jan-> just to clarify if I have a 16mhz AVR and I don't set dividers, the SPI goes at 8MHz?
[12:35:25] <Jan-> If so, yowza.
[12:35:50] <megal0maniac_afk> There might be an additional limitation on that, but yes
[12:36:01] <Jan-> Ooh.
[12:36:18] <Jan-> Is it a bad idea to use SPI to talk to just shift registers? Will I go to engineering hell?
[12:36:44] <megal0maniac_afk> No. If it can work, then it's a good idea
[12:37:07] <Jan-> awzum.
[12:37:12] <megal0maniac_afk> Less bit-banging. More processing time for other stuff
[12:37:17] <Jan-> that was the thinking.
[12:37:27] <Jan-> I will need to send 8 bytes (I'm driving 8x 7 segs)
[12:37:57] <megal0maniac_afk> Jan-: Note how in the datasheet, there's no "recommended applications" section for specific peripherals ;)
[12:38:05] <Jan-> Uhhuh.
[12:38:12] <Jan-> It does rather make things easy.
[12:38:57] <Jan-> Otherwise I guess I'm just flipping a pin up and down a lot.
[12:40:04] <Jan-> Oh one question. I saw a project - done in arduino, but bear with me - in which they were bit banging shift registers, and they had programmed a delay between asserting clk and setting the data.
[12:40:10] <Jan-> Of 10 microseconds.
[12:40:36] <Jan-> Is that actually likely to be necessary, given 595s are fast, or will the intrinsic delay of the avr running its code be enough?
[12:41:13] <megal0maniac_afk> Test it and see. Check the 595 datasheet
[12:41:30] <Jan-> I assume the SPI peripheral sorts that out automagically. I mean, 595s will accept data at 8mhz.
[12:42:16] <Dreamer3> ok
[12:42:19] <Dreamer3> the make file is broken maybe?
[12:42:39] <vectory> Jan-: might be for other reasons. meybe reasons they didnt even udnerstand
[12:42:45] <Dreamer3> it generates "boot" from "boot.o"... if you use boot vs boot.o for then it works
[12:43:09] <vectory> e.g. i heard that switching a pin on doesnt guarantee that its set in the next cycle, because of parasitic capacities on the pin
[12:43:11] <Jan-> vectory: I did wonder. Especially given that digitalWrite() on arduino is notoriously slow anyway.
[12:43:42] <vectory> that is when switching pull up, iirc
[12:44:07] <Jan-> I do like the fact that at 8mhz I can clock out a byte in a microsecond.
[12:44:13] <Jan-> that's fast
[12:44:35] <Jan-> barely even need to latch the 595s, just let it chase through at that speed.
[12:44:41] <vectory> do you need it that fast?
[12:44:45] <Jan-> actually no.
[12:44:46] <Jan-> not really.
[12:44:59] <Jan-> It does need to be camera safe. But that's nothing to do with the load time really.
[12:46:26] <Jan-> on the other hand I could pretty much ignore the load time and just do it on spec.
[12:46:32] <Jan-> as opposed to having to predict.
[12:47:16] <vectory> how do you adress 8 ICs from one SPI?
[12:47:35] <Jan-> Shift registers.
[12:47:37] <Jan-> They chain.
[12:47:45] <vectory> oh, right
[12:47:49] <Jan-> In point of fact I don't, I address the first one.
[12:48:11] <Jan-> is 8mhz fast enough to have to start worrying about PCB layout screwing it up
[12:48:17] * Jan- *headscratch*
[12:49:42] <specing> Jan-: no
[12:49:59] <specing> 299792458 m/s * (1 / 8000000.0MHz) = 37.47405725 meters
[12:50:12] <specing> so unless your traces are more than 40 meters long...
[12:51:45] <Jan-> I'm sure I heard a video from adafruit once about some board they'd made where they had to be careful
[12:51:48] <Jan-> it might have been an arm
[12:51:53] <Jan-> but they're usually only a few tens of mhz
[13:17:58] <Amnesia> hi, does is any over here familiar with avrdude by any chance?
[13:23:00] <Jan-> Amnesia: I used it for the first time the other night, but you might as well ask :)
[13:25:58] <_abc_> Wow a Jan- invasion
[13:26:14] <_abc_> You are *everywhere* *and* stalking ;)
[13:26:51] <_abc_> Can someone say quickly what speed grades of atmega8 exist? would an atmega8a do 18.432 MHz if overclocked a little, at 5V?
[13:27:13] * Jan- jumps on _abc_'s back
[13:27:14] * Jan- clings on
[13:27:41] <myself> any time you're outside the datasheet specs, nobody can say for sure, but I'd certainly try it
[13:27:50] <_abc_> Someone says it works for them
[13:28:02] <Jan-> I've always been told that AVRs overclock quite well.
[13:28:02] <myself> you might want to write yourself a test program that runs some arithmetic, checks some memory, toggles some pins, etc..
[13:28:03] <_abc_> Also I am under the impression 8a is better silicon wise than 8 (die shrink etc)
[13:28:20] <_abc_> This is a one off I want to try, someone else wrote it, so...
[13:28:33] <Jan-> Apparently there are 4 combinations of clock polarity and phase.
[13:28:43] <Jan-> is that what you're talking about
[13:28:47] <_abc_> YES! Did you read what I wrote Jan- ?
[13:28:49] <myself> SPI is a PITA, if that's what you mean :P
[13:29:00] <Jan-> you said there are four modes, I wasn't sure if that meant the same thing
[13:29:09] <_abc_> myself: compared with what? i2c which is a tv hack from philips 1970s?
[13:29:29] <Amnesia> Ok, well I've become unable to upload sketches anymore to my arduino
[13:29:31] <myself> Oh it's the best PITA we've got, for sure.
[13:29:45] <_abc_> Jan-: the 4 modes result from the two sets of two possibilities: one) clock edge positive or negative two) clock then read or read then clock
[13:29:48] <Jan-> Amnesia: did you inadvertently overwrite the bootloader
[13:29:50] <Amnesia> I'm suspecting the bootloaders fucked up, since I;m getting messages like "not in sync" or the connection just times out
[13:29:52] <Jan-> _abc_: yes that's what I was asking.
[13:29:57] <Amnesia> Jan-: not that I know
[13:30:06] <Amnesia> I've only been fiddling around with some leds
[13:30:13] <_abc_> Amnesia: it's a miracle you remember what you wrote above with your condition
[13:30:15] <Jan-> Amnesia: ah. did you triple check your baud rate and serial device settings in the programmer?
[13:30:25] <Amnesia> yep
[13:30:36] <Jan-> try another USB port?
[13:30:36] * myself facepalms
[13:30:37] <Amnesia> this settings, namely vim + makefiles, worked befpore
[13:30:46] <myself> another cable, too, always worth a try
[13:30:49] <Jan-> mm
[13:32:52] <Amnesia> dafuq, another port does do the job...
[13:32:57] <Amnesia> what could've been the cause of that..
[13:33:37] <Jan-> sometimes USB device enumeration can be weird
[13:33:46] <Jan-> frankly I find USB quite unreliable
[13:33:48] <myself> point for Jan-
[13:33:57] <Amnesia> hm
[13:34:03] <Amnesia> never experienced something similar before
[13:34:09] <_abc_> Okay so speed grades seem to guarantee operation at 16MHz only
[13:34:15] <Amnesia> it has to be a bug in the usb controller..
[13:34:29] <_abc_> Amnesia: windows?
[13:34:36] <Amnesia> nope, linux
[13:34:36] <myself> probably OS failed to unload a driver
[13:34:52] <_abc_> Unlikely. So wait the boot loader is f*d?
[13:35:58] <Dreamer3> does the CBI instruction not work on higher I/O ports?
[13:36:03] <Amnesia> it's working now
[13:38:15] <Amnesia> and now it's happening again:|
[13:38:21] <Amnesia> ioctl("TIOCMSET"): Connection timed out
[13:41:39] <Dreamer3> http://pastie.org/private/pg143mjplxon24suorqq
[13:41:42] <Dreamer3> why does the CBI not compile?
[13:42:45] <learath> hah!
[13:47:52] <phinxy> Is the AVR Dragon's HV_prog pins connected to the prototype area were i can solder a zif socket or do i need to wire that manually?
[13:48:22] <phinxy> nevermind stupid question. of course its different for each microcontroller
[13:48:55] <phinxy> What would be the most "elegant" solution that doesnt need to be flexible?
[13:50:50] <Casper> another microcontroller with an lcd display that allow you to select which IC you're inserting, with some circuit around it to reroute the signals :D
[13:53:00] <phinxy> wow that would be cool :)
[13:53:23] <Casper> there would even be a way to do reset pin detection too
[13:53:37] <Casper> I beleive it's the only pin with no protection diode
[13:54:17] <Casper> doing that would allow to restrict the choice and half confirm that you got the right one
[13:54:34] <Casper> oh I guess that VCC and GND autodetection is doable too
[13:54:43] <Casper> due to the protection diodes
[15:07:09] <Dreamer3> grrrr
[15:07:11] <Dreamer3> wish i knew more
[15:07:28] <Dreamer3> can't get my modified boot loader for 328 to run
[15:07:50] <Dreamer3> boot section `.text' will not fit in region `text'
[15:07:55] <Dreamer3> but i don't understand why not
[15:09:04] <Epsilon-Auriga> how big does your bootloader compile to?
[15:09:44] <Dreamer3> well it has .org (FLASHEND - SPM_PAGESIZE - 1) so it compiles to the full size, but the boot code itself is < 128
[15:09:49] <Dreamer3> which is less than the page size
[15:09:53] <Dreamer3> significantly so
[15:10:34] <Tom_itx> is .text the same as .data though?
[15:10:36] <Epsilon-Auriga> and what is the bootloader section set to on the chip?
[15:10:49] <Dreamer3> Tom_itx: there is no .data
[15:11:01] <Tom_itx> or other sections
[15:11:06] <Dreamer3> no other sections :)
[15:11:49] <Tom_itx> well cram it in there then. it'll fit
[15:11:52] <Dreamer3> no other sections :)
[15:12:13] <Dreamer3> you'd think
[15:12:27] <Tom_itx> who's bootloader is it?
[15:12:39] <Tom_itx> i got a 328 here somewhere...
[15:12:57] <Tom_itx> might have to dig for it
[15:14:20] <Dreamer3> collect2 is throwing the error
[15:14:53] <Dreamer3> https://code.google.com/p/picoboot/
[15:24:36] <Dreamer3> wish it would tell me what it thought the sizes were
[15:26:50] <Dreamer3> if i remove all my code it still doesn't work
[16:01:22] <Dreamer3> grrrr
[16:01:29] <Dreamer3> -r to the linker fixes it
[16:01:35] <Dreamer3> but why does it think it needs to relocate my code
[16:03:30] <Dreamer3> no wait, the jumps are all wrong now
[16:09:57] <megal0maniac_afk> Anyone here know how to deal with xmega interrupts?
[16:20:36] <Dreamer3> megal0maniac_afk: what is your qusetion
[16:23:23] <megal0maniac_afk> Dreamer3: Nevermind, figured it out. Was getting confused by the fact that there was a single vector for an entire port of pin interrupts
[16:30:54] <Dreamer3> yeah
[16:31:00] <Dreamer3> if you're talking pin change
[16:31:05] <Dreamer3> i think there are 3 possible interrupts
[16:31:11] <Dreamer3> well, for different groups of pins
[16:31:17] <Dreamer3> but not an interrupt per pin
[16:32:16] <PoppaVic> signal major changes to poll minor?
[16:37:49] <Dreamer3> if you want to check a single pin some AVRs have interrupts just for that
[16:38:06] <Dreamer3> so i think i found my linking problem: text 0x00000000 0x00002000 xr
[16:38:17] <Dreamer3> why does the memory configuration of the linker only have 0x2000 for text?
[16:39:46] <Tom_itx> i remember something about word vs byte
[16:39:51] <Tom_itx> very vague though
[16:40:15] <Dreamer3> well it works if i keep it under 2k
[16:40:24] <Dreamer3> well, 0x2000 whater
[16:41:18] <Dreamer3> n/m
[16:41:21] <PoppaVic> $2000 . 8192 ok
[16:41:32] <Dreamer3> hmmm
[16:41:39] <Dreamer3> duh
[16:41:40] <Dreamer3> :(
[16:41:45] <Dreamer3> so that's not it either
[16:41:47] <Dreamer3> man this is killing me
[16:41:49] * PoppaVic chuckles
[16:42:02] * Dreamer3 my linker keeps saying: boot section `.text' will not fit in region `text'
[16:44:08] <Jan-> what PCB software does everyone use? Don't say "eagle"
[16:44:19] <Jan-> it costs one human soul and, I'm told, your sanity.
[16:44:34] <myself> Genus Acciptridae.
[16:44:47] <myself> er wait, that's a family. Whatever. dammit.
[16:45:58] <PoppaVic> there is a older linux package I got peeved with, and Kicad - the latter actually seems to work for me - and I pretend it wasn't written in c++
[16:46:15] <Jan-> oh that's so linux
[16:46:26] <Jan-> "This program is great, but it's written in a language I don't like, so I don't recommend it."
[16:46:27] <Jan-> :/
[16:46:50] <Dreamer3> rofl
[16:46:53] <PoppaVic> <shrug> That wasn't what I said - enjoy
[16:47:07] <Dreamer3> that makes a bit more sense when people are used to hacking on everything vs just using it
[16:47:24] <Jan-> if a few more linux people expected users to be users not hackers, linux would have more users :/
[16:47:44] <myself> "I'll ask for people's advice, but tell them not to answer the most common answer, and then pick apart the other answers they provide! That'll surely make everyone more likely to answer my questions in the future."
[16:47:47] <PoppaVic> I could care less about lemmings
[16:48:17] <PoppaVic> myself: the amusement never ends
[16:48:35] <Dreamer3> rofl
[16:49:28] <_abc_> How exactly are you operating the magic shield which keeps arduino users from pestering this channel? It clearly works...
[16:49:48] <_abc_> Maybe the mantra 'arduino is not avr' was drilled well into them
[16:50:17] <myself> we're here, we just know better than to ask arduino questions here. mostly.
[16:50:41] <_abc_> Aha! And you have no such qualms on #electronics? >;)
[16:51:15] <Jan-> I got into a situation the other day when I was trying to use an arduino board as a normal AVR where both channels were refusing to help on principle.
[16:51:18] <myself> I had to stop going there. The advil budget was getting excessive.
[16:53:02] <_abc_> advil?
[16:53:41] <myself> the WTF density in #electronics was pain-inducing.
[16:54:32] <Dreamer3> rofl
[16:54:40] <Dreamer3> --noinhibit-exec Create an output file even if errors occur
[16:54:57] <Dreamer3> so now i have an output file that looks great, disassembles great, but does it work? :)
[16:55:19] <Dreamer3> hmmm
[16:55:21] <Dreamer3> i see
[16:55:27] <Dreamer3> my hex file is suddenly 91k for some reason
[16:55:32] <Dreamer3> despite boot.bin being 32k
[16:56:11] <_abc_> hex uses 2 characters per byte... and some change
[16:56:48] <Dreamer3> hex file, not hex digits
[16:58:23] <_abc_> ...?
[17:02:26] <theBear> on that note, i finally got this little eeprom programmed up right (long story, but it doing ddc/edid vga style), but damn, every single app and i2c-dumper and edid-dumper (just i2c via vga port) and hex editor in town seems to disagree on output formats and what bin formats aren't worth supporting and that they should all have a unique layout for noting address on a dump so that you can't just grab output with a pipe or something sensible like that (unle
[17:02:26] <theBear> ss yer into regexp ninjarey)
[17:03:25] <_abc_> theBear: you spoke the truth
[17:05:40] <Dreamer3> so yeah that is the problem
[17:05:51] <Dreamer3> it should be 0x8000, 32k
[17:06:00] <Dreamer3> and instead it thinks it's only 8k
[17:06:03] <Dreamer3> so how to tell it the truth
[17:10:18] <theBear> it was also a good reminder that corner-cutting often wastes more time than "doing the right thing" ... i did the right thing finally yesterday, knocked up a little 'easyi2c' parport interface on a veroboard, but the stupid thing didn't work 1st try (an outrage !) so in frustration i did one last quick webby search and found a little script that does work to program via vga port (aka kernel i2c subsystem) and programmed on the 100% passive vga thinger i m
[17:10:19] <theBear> ade last week
[17:10:52] <_abc_> theBear: fix the parallel port item
[17:10:57] * _abc_ -> sleep
[17:10:58] <theBear> still, quick poke with a scope/meter and some 5v/gnd i should have a proper buffered hw programmer with lights and all
[17:11:56] <theBear> yeah, i will, just that this is a single 'project' which blew WAAAAY outta schedule that i wanna get off my workbench... been using this netbook as my only working machine for a month or more now !
[17:12:07] <theBear> was supposed to be a single night :(
[17:16:51] <Dreamer3> anyone know where ld has template linking scripts?
[17:37:05] <Dreamer3> ok new error
[17:37:06] <Dreamer3> (.text+0x0): relocation truncated to fit: R_AVR_13_PCREL against `no symbol'
[17:38:35] <Dreamer3> the only reference i can find to it is in all the AVR toolchain binary files
[17:41:00] <Dreamer3> man some of these error messages are insane
[17:43:43] <Dreamer3> ha
[17:45:39] <Dreamer3> stupid rjmp vs jmp
[17:45:51] <Dreamer3> since the memory is so much larger on 328 you need a jmp
[17:46:26] <Dreamer3> still need the linker script fix too though, that was a real issue
[17:46:30] <PoppaVic> amusing, since I'd never think "jmp" OR "rjmp" from the R_AVR_13_PCREL clue
[17:48:44] <Dreamer3> there isn't a imp on the tiny avrs
[17:48:48] <Dreamer3> just rjmp
[17:48:50] <Dreamer3> too funny
[17:59:01] <phinxy> what computer can you compare a ~atmega32 to? like apple II?
[18:00:20] <Epsilon-Auriga> roughly, yeah.
[18:00:23] <Epsilon-Auriga> only much faster.
[18:00:45] <Epsilon-Auriga> apple-2 ran the 6502 at 1mhz....that was less than 1 mips..more like 0.25 mips at best I think.
[18:00:54] <Epsilon-Auriga> atmega32 runs close to 16 mips.
[18:01:12] <Epsilon-Auriga> but roughly the same program space.
[18:01:25] <phinxy> Can you run apple os on a controller? :O
[18:01:31] <phinxy> its basic
[18:01:46] <Epsilon-Auriga> well, if you ported it, yeah.
[18:01:54] <phinxy> zomg
[18:02:11] <Epsilon-Auriga> apple basic is a modified microsoft basic, same as commodore basic
[18:02:24] <Epsilon-Auriga> but the basic for those was written in 6502 assembly.
[18:02:34] <Epsilon-Auriga> so, porting is not exactly a trivial task.
[18:02:40] <Epsilon-Auriga> but it is doable.
[18:02:59] <Epsilon-Auriga> I have 4 different basic interpreters that I'm playing with for the atmega1284
[18:03:15] <Epsilon-Auriga> all of them are written in C, however, so porting is much easier.
[18:03:57] <phinxy> do you know if apple had an external video chip?
[18:04:02] <Epsilon-Auriga> it did.
[18:04:05] <PoppaVic> afaik, there is no "os" tossed to the little things, though. Unless you mean RTOS - and I dunno who uses such
[18:04:05] <PoppaVic> ..prolly due to the memory-model[s]
[18:04:44] <Epsilon-Auriga> PoppaVic: it's not difficult to do a BASIC OS like the apple and commodore basic on an avr...it is an interpreter after all.
[18:04:59] <Epsilon-Auriga> now, the basic programs that did things with assembly routines and such would be harder, granted,,,
[18:05:04] <phinxy> Prob lots of custom hardware too.
[18:05:12] <Epsilon-Auriga> phinxy: google is your friend.
[18:05:34] <PoppaVic> Epsilon-Auriga: well, since I once had a c64, and evena t/s-1000, I know it CAN be done - but the ram is poor, and you'll end up running pcode.
[18:05:48] <phinxy> yep =) ill look for a complete scheme if there is
[18:06:10] <Epsilon-Auriga> PoppaVic: that's what basic is anyhow,,,kindasorta....have you ever looked at how the C64 stored its basic in ram?
[18:07:07] <Epsilon-Auriga> it is very interesting..when you added lines of code, it didn't put them in order in ram...it just used a linked list and added new lines at the end of the program storage ram area....and commands like print and goto were stored as 1 byte symbols.
[18:08:09] <Epsilon-Auriga> by using the atmega1284 I have 16K of sram to store basic programs.
[18:08:17] <Epsilon-Auriga> that and variables...but,
[18:14:46] <Epsilon-Auriga> I also have a C interpreter that I'm trying to fit on the atmega1284...
[18:27:09] <PoppaVic> turn yer damned back, and the wifi is dead. *sigh*
[18:28:02] <PoppaVic> Epsilon-Auriga: I've seen flashforth for the AVR's, but I'd rather a tethered/umbilical forth for development - and I am NOT buying Swiftforth ;-)
[18:34:11] <N2TOH> forth?
[18:34:34] <PoppaVic> forth
[18:35:16] <N2TOH> the language born to control CNC motors for telescopes yes?
[18:35:28] <PoppaVic> yes
[18:36:32] <PoppaVic> I think it was really born of a need for reliability, simplicity, small-size, and "keep the scientists out of the code!"
[18:36:46] <N2TOH> ah yes also the same used to trade commodities before the NYC/Chicago exchange debacle...
[18:36:51] <PoppaVic> well, they COULD code - but.. they couldn't hurt much, I suppose
[18:37:08] <N2TOH> ^^^
[18:37:29] <phinxy> lets say i have a bit at position 46 in eeprom, eeprom_read_byte (( uint8_t *) 46); does that take up exactly 1 bit in eeprom?
[18:37:58] <PoppaVic> if it's reading a byte, it reads a byte
[18:38:20] <abcminiuser> You could use packed bitfields
[18:38:28] <abcminiuser> But the read/write access code would then be large
[18:38:37] <phinxy> What if theres a uint32? wouldnt it overlap to position 46,46,47 etc?
[18:39:41] * N2TOH was good friends with the guy that did 100% of the "canned" routines for the tandem mainframe X.25 pads years ago
[18:39:52] <PoppaVic> 46 8 /mod .s <2> 6 5 ok
[18:40:21] <phinxy> assembly? :|
[18:40:56] <N2TOH> nay, written in Machine code.
[18:41:09] <N2TOH> 68K
[18:42:02] <N2TOH> it all needed to be cycle by cycle perfect for the clock rate they used...
[18:42:56] <N2TOH> it was 9600 Baud head on tails, with 0% error rate!
[18:43:15] <N2TOH> no room for mistakes
[18:47:01] <Roklobsta> 68k easy
[18:47:12] <Roklobsta> nice cpu
[18:58:42] <atom1> 68332 was one of my favorite
[18:59:15] <phinxy> There arent any real reason to program .eep for starting variables, are there? Been told to have a check in main() for starting vars anyway
[19:00:52] <phinxy> Nevermind, i think i got it.
[19:08:17] <Dreamer3> hmmm
[19:08:29] <Dreamer3> stk500 protocol looks a lot more complex than i see in the optibootloader
[19:09:04] <Epsilon-Auriga> it can be...lots of options.
[19:10:23] <Dreamer3> i mean it looks like it wraps all messages in this big packet and i don't see that code anywhere
[19:10:32] <Dreamer3> reading the AVR PDF on the protocol
[19:19:18] <Dreamer3> hmmm
[19:19:23] <Dreamer3> virtual boot partiion is an option?
[19:19:25] <Dreamer3> not default?
[19:19:30] <Dreamer3> i must really not understand how this stuff works yet
[19:24:10] <Dreamer3> ha
[19:24:18] <Dreamer3> it has code to undo it's patch so the verify still works, cute
[19:26:27] <Dreamer3> where the heck is SIGNATURE_0 set
[19:26:57] <Dreamer3> i can't find it in all the source but it's referenced
[19:28:25] <PoppaVic> I prolly should get the protocol pdf, but I figure that is what avrdude and libavrdud are for
[19:28:39] <Dreamer3> i'm trying to understand the early boot process
[19:30:17] <PoppaVic> what's "early boot"?
[19:30:50] <Dreamer3> when it turns on :)
[19:31:02] <Dreamer3> how the program and boot loader co-exist, etc
[19:31:20] <Epsilon-Auriga> oh, that's not so difficult.
[19:31:24] <PoppaVic> oh, you mean the TIME
[19:31:30] <Epsilon-Auriga> there are 2 sets of vectors.
[19:31:39] <PoppaVic> it restarts at zero. It vectors. boom
[19:31:54] <PoppaVic> it's like most other cpu's
[19:32:08] <PoppaVic> the SPI enable is the part I like ;-)
[19:32:11] <Epsilon-Auriga> if you are setup for a bootloader then the bootloader vectors are prominent,,interrupts and startup and all...so when the chip powers on it jumps to bootloader section.
[19:32:35] <Epsilon-Auriga> when bootloader is done, usually, it switches things over to main and runs away.
[19:33:21] <Dreamer3> i get that part, but why doesn't the boot loader get wiped when it's told to flash itself
[19:33:34] <PoppaVic> well, it calls setup() and then loops on whatever
[19:33:51] <Epsilon-Auriga> bootloader can't write to itself, I think...
[19:33:57] <Dreamer3> i'd assume something like VIRTUAL_BOOT_PARTITION optiboot, but that's not default
[19:33:58] <PoppaVic> yes, it can
[19:34:19] <PoppaVic> but the chip itself is "flashable" w/o a bootloader installed
[19:34:29] <Dreamer3> right
[19:34:36] <PoppaVic> so-say the docs, anyway
[19:34:43] <Dreamer3> it totally is
[19:34:58] <PoppaVic> (why I run into dozens of sites insisting on "programmers" or "bootloaders" is another issue)
[19:35:25] <PoppaVic> Dreamer3: the only caveat I saw was: Do Not Mung The SPI fuse!
[19:35:35] <Dreamer3> cause you need some hardware without a bootloader
[19:35:39] <PoppaVic> Or, yes: you need an HV programmer or a trashcan
[19:35:47] <Dreamer3> though i don't understand why that's true for boards with their own USB avr chip
[19:36:18] <Dreamer3> though maybe that chip isn't patched into the SPI lines
[19:36:36] <PoppaVic> Dreamer3: once I get a few spares, I will friggin' test it. I've an uno r3, (sans ftdi) AND an ftdi-breakout-board - and the wiring looks totally doable.
[19:36:40] <Dreamer3> looking
[19:37:13] <PoppaVic> the u2 or whatever subbing as an ftdi HAS to speak SPI to get back to the 386p
[19:37:57] <Dreamer3> ah i got it
[19:37:58] <PoppaVic> the issue there is only that a RESET line must go low, (and the ftdi board can use DTR to do so) - not sure what the lil SMD they use would need
[19:38:38] <Dreamer3> the usb chips only real connection to the main AVR is RX/TX (not the SPI kind) and the reset pin of the ICSP header for the big avr
[19:38:58] <PoppaVic> From the 20-some tabs I have open, I get an awfully confused set of "answers"
[19:39:19] <Dreamer3> if it were wired differently then the atmega 16u2 could ref lash the larger chip over ISP
[19:39:58] <PoppaVic> Dreamer3: I was thinking that as well: that their wiring was deliberately lamed.
[19:41:49] <Dreamer3> it's whole Port C is free
[19:42:23] <PoppaVic> I wonder where the code for that thing got stashed.. Seems sad to sue only part of it
[19:42:26] <PoppaVic> use, two
[19:43:23] <Dreamer3> 6k flash
[19:43:25] <Dreamer3> 8k
[19:43:41] <Dreamer3> you'd think that'd be enough for a USB controller and squeeze a simple SPI control mode
[19:44:08] <PoppaVic> well, I think it'd just be edumacational - and maybe useful.
[19:44:23] <Dreamer3> well it'd let you flash the whole chip
[19:44:27] <Dreamer3> remove that 0.5k you can't use
[19:44:35] <Dreamer3> move it into the USB chip
[19:44:43] <Dreamer3> well, that doesn't work on arduinos without a AVR for usb controller :)
[19:44:55] <Dreamer3> and i still don't understand how the boot loader doesn't overwrite itself
[19:45:07] <PoppaVic> except it's very handy to use the bootloader on the dip, pop it off and stuff it in another board, yes
[19:46:09] <Dreamer3> huh?
[19:48:02] <PoppaVic> Dreamer3: the-bootloader-on-the-328p
[19:48:21] <PoppaVic> am I going too fast? my mind is blipping all over it.
[19:49:22] <Dreamer3> yes talking about an uno for example, 328
[19:49:43] <PoppaVic> right, you suggested moving bootloader to the U2
[19:51:17] <Dreamer3> maybe the Arduino tools just rewrites the boot loader each time
[19:51:20] <PoppaVic> if you did, then the 328p would get some extra space, but.. it'd be lamed - except if it allows serial-loading *anyway* then I am not sure wtf the bootloader is actually doing. I was trying to read source, but got sidetracked - and I still gotta' sidetrack back to work for a meeting in a couple hours.
[19:51:24] <Dreamer3> i.e., the compiled file has the bootloader?
[19:51:27] <PoppaVic> nah
[19:51:43] <Dreamer3> it allows serial loading
[19:51:59] <Dreamer3> but you need something to talk TO it
[19:52:14] <PoppaVic> the sequence I've seen listed is: blow the fuses-as-required; blow-the-bootloader AND/or blow-the-application.
[19:52:45] <Dreamer3> hmmm
[19:52:58] <PoppaVic> Dreamer3: I think the serial-loading-sans-bootloader is hardwired. So, I am not sure what a bootloader does itself - maybe twiddle settings for higher speeds?
[19:54:48] <Dreamer3> ok
[19:54:50] <Dreamer3> starting to see
[19:56:02] <Dreamer3> 00007e00 <main>:
[19:56:39] <Dreamer3> so it's last
[19:56:49] <Dreamer3> i just didn't see that mentioned in the C code like it's easy to find in assembler
[19:57:19] <xorm> anyone know off-hand how long it takes to tristate a bank of pins?
[19:57:27] <Dreamer3> oh that's done in the makefile for th linked
[19:57:30] <Dreamer3> atmega328: LDSECTIONS = -Wl,--section-start=.text=0x7e00 -Wl,--section-start=.version=0x7ffe
[19:58:53] <PoppaVic> Dreamer3: I have "issues" reading linker-isms and "assembler". I last touched real asm on a 286 - yes eons back - and I preferred z80. So, it's all greek.
[20:00:28] <PoppaVic> from the docs, I know the bootloader runs at one of N points in hi flash, does SOMETHING, and if there is no twiddling on the USB, it will leap over to the application.
[20:00:45] <Dreamer3> right
[20:00:57] <Dreamer3> but it's up to the app not to ref lash the first instruction of memory poorly
[20:01:08] <PoppaVic> "re Flash"
[20:01:11] <Dreamer3> it has to be a JMP to the bootloader
[20:01:27] <PoppaVic> I keep reading "ref flashing" - and wonder why yer beating the docs ;-)
[20:01:34] <PoppaVic> ref-lashing
[20:02:21] <Dreamer3> ok maybe ino doesn't build reflashable stuff :)
[20:02:22] <PoppaVic> I need to puzzle out WHAT the bootloader is doing - and seems to manage in multiple sizes, no less.
[20:02:35] <Dreamer3> the firmware it's building is def going to cancel the boot loader :)
[20:02:47] <PoppaVic> ino just runs other programs
[20:04:54] <Dreamer3> right
[20:05:13] <Dreamer3> but i though it's promise was to work with the arduino framework files and just kind of nix the whole UI :)
[20:09:53] <PoppaVic> well, from all I saw so far: ino just avoids dribbling Makefiles around - so, it's an "automake" w/o leaving that - just doing the job. (I think you CAN ask it to leave intact files for reference, though)
[20:10:29] <Dreamer3> no it looks into the official Distro and uses all their libraries, etc
[20:10:34] <Dreamer3> automatically
[20:12:39] <Dreamer3> ok
[20:12:53] <Dreamer3> i'm left concluding that the JAVA build environment does something funky to the programs before they are written
[20:13:15] <Dreamer3> wait do i have all that java source too?
[20:15:02] <PoppaVic> optiboot: clear Z, set SP, check USB & if not loader, appstart - OTHERWISE.. set timer; usart speed; watchdog; led/heartbeat pin; flash; protocol-loop (cmd processor)...
[20:15:32] <Dreamer3> right
[20:15:35] <PoppaVic> should be a fairly small bit of code.
[20:15:44] <Dreamer3> i get all that
[20:16:03] <PoppaVic> I had not taken the time to page DOWN from the notes at the top ;-)
[20:16:28] <Dreamer3> the problem is all that optiboot code starts at 07e00
[20:16:34] <Dreamer3> and the device boots to 0
[20:16:44] <Dreamer3> i wonder if you can change where it boots to
[20:16:46] <PoppaVic> which jaba? the IDE? just the gui-part is jaba. the rest is all CLI program invocations
[20:17:00] <PoppaVic> no
[20:17:29] <PoppaVic> the AVR *runs* at zero - that is space-enough for a JMP BOOT; or whatever - just like it was on the Z80's
[20:17:47] <PoppaVic> it does have some weirdness I see ifdef'd
[20:17:59] <Dreamer3> sure, but how to prevent the jmp from being zapped by the first avrdude
[20:18:40] <PoppaVic> huh?
[20:18:54] <Dreamer3> writing your first app will overwrite location 0
[20:19:08] <Dreamer3> that's why the boot loaded is LAST... so it can just check size < MAX and then say "no, bad boy"
[20:19:14] <Dreamer3> but the first location is game
[20:19:49] <PoppaVic> I believe we are missing more info on the nekkid commo with the chip, sans bootloader - WITH the bootloader, you talk to the command-processor
[20:20:10] <Dreamer3> right
[20:20:15] <Dreamer3> but ti doesn't have any protection
[20:20:16] <Dreamer3> i read the source
[20:20:29] <Dreamer3> except for the cool VIRTUAL stuff, which is what i would expect, but that's not on by default
[20:20:40] <PoppaVic> and, iirc, the nekkid serial also takes a specific pin/signal flutter.
[20:21:07] <PoppaVic> I was looking for the VIRT again - got caught staring at soft-uart
[20:22:11] <Dreamer3> ha all the java code is here too
[20:22:13] <Dreamer3> i love OSS
[20:22:24] <PoppaVic> I don't read jaba
[20:24:07] <Dreamer3> first looking in their avrdude code
[20:24:09] <Dreamer3> ha
[20:24:12] <Dreamer3> it's all programming code
[20:24:21] <Dreamer3> easy enough to grok for them doing soothing funny
[20:24:28] <Dreamer3> hard thing is knowing where to look
[20:25:03] <PoppaVic> I really don't much care what avrdude does, if I know what it should do, can do, we should/can/may do
[20:26:20] <Dreamer3> oh boy it's killing my TM to do a text search
[20:26:21] <Dreamer3> that's new
[20:27:08] <Dreamer3> no, not some avrdude hack :)
[20:33:23] <Dreamer3> is there a verbose building mode?
[20:33:28] <Dreamer3> it'd help to see a list of commands the UI runs
[20:33:55] <PoppaVic> which one?
[20:34:05] <PoppaVic> oh, the IDE? preferences
[20:34:07] <Dreamer3> the Anduino when it builds and uploads
[20:34:14] <PoppaVic> just under the text boxes
[20:34:19] <Dreamer3> oh i haven't got the UI installed
[20:34:25] <Dreamer3> well i do, but no java :)
[20:34:34] <PoppaVic> run from a CLI and use redirection to capture it ;-)
[20:34:41] <Dreamer3> you don't want to generate an output do you?
[20:35:15] <PoppaVic> for blinky? It means little except filepaths/args
[20:35:16] <Dreamer3> or can you generate a .hex file separately?
[20:35:24] <Dreamer3> i'd love to see the file
[20:35:37] <PoppaVic> I am sure it can generate a .hex
[20:37:39] <Dreamer3> man
[20:37:45] <Dreamer3> it's not in the hex generation :)
[20:37:54] <Dreamer3> that's just a simple objcopy
[20:38:52] <Dreamer3> so now i bet it's in a C file or S file they include
[20:39:22] <Dreamer3> damn does no one ever talk here?
[20:39:26] <Dreamer3> can't believe no one would know this
[20:40:34] <Dreamer3> but how would they know where to jump?
[20:41:19] <PoppaVic> Dreamer3:
http://codepad.org/kXB4AdaE and
[20:41:33] <PoppaVic> http://codepad.org/uxGZmpJV
[20:41:45] <Dreamer3> i don't need more than one :)
[20:42:46] <Dreamer3> ick
[20:42:49] <Dreamer3> can i get the actual file
[20:42:50] <Dreamer3> wait
[20:43:06] <Dreamer3> can i get the hex file itself
[20:43:18] <Dreamer3> or can you run avr-dumpobj -D -mavr on it
[20:43:25] <PoppaVic> how would get that?
[20:47:07] <Dreamer3> ok now i'm going to be upset when i finally figure this out
[20:47:09] <Dreamer3> it's going to be something easy
[20:47:33] <PoppaVic> ugh, no dumpobj cruft around
[20:47:46] <Dreamer3> http://stackoverflow.com/questions/19926930/no-bootloader-overwrite-when-programming-arduino-with-avrisp
[20:47:50] <Dreamer3> ah, this might be useful
[20:47:55] <Dreamer3> he's asking my question indirectly :)
[20:48:27] <Dreamer3> "Regarding the fuses, you just have to make sure that the boot loader (address) stays configured as the entry point."
[20:48:59] <PoppaVic> well, yes - $0000 again
[20:50:06] <Dreamer3> don't think so :)
[20:51:18] <PoppaVic> Dreamer3: it restarts at zero. period. Now, THAT number needs to point right at +0 of the bootloader - which can sit in any one of 3 or 4 sized-slots.
[20:52:23] <PoppaVic> I'm still wondering how on earth yer actually conning the HW to "write this code to this chip. Yes, I know it has no bootloader - do as yer told"
[20:57:07] <Dreamer3> yep
[20:57:08] <Dreamer3> i'm right :)
[20:57:10] <Dreamer3> fuses
[20:57:21] <Dreamer3> # 512 byte boot, SPIEN
[20:57:22] <Dreamer3> atmega328_pro8_isp: HFUSE = DE
[20:57:34] <Dreamer3> you can configure 4 different size boot loaders at the end of flash
[20:57:38] <Dreamer3> and change the restart vector
[20:57:49] <Dreamer3> http://www.engbedded.com/fusecalc/
[20:57:51] <Dreamer3> shows you how
[20:58:05] <Dreamer3> but i guess 328 can come with different RAM amounts, so that has the wrong addresses
[20:58:17] <Dreamer3> oh that is pretty cool
[20:58:40] <Dreamer3> means there is no point in reducing the size further unless we can get it down to 256 bytes
[20:58:45] <Dreamer3> since that's the next config value
[20:58:51] <Dreamer3> i.e., 384 wouldn't be helpful
[20:59:58] <Dreamer3> thanks for your help :)
[21:00:21] <Dreamer3> now back to the original thought boot loader on the 16u chip
[21:01:28] <PoppaVic> umm. OK.
[21:01:40] * PoppaVic returns to semi-amused confuzzlement
[21:02:20] <Dreamer3> so it just changes where it can boot from
[21:02:33] <Dreamer3> evidently EVERY chip can't do that, hence the VIRTUAL PARITTION code
[21:02:40] <Dreamer3> which hacks the burning process
[21:02:45] <Dreamer3> inside the bootloader
[21:02:54] <PoppaVic> ah
[21:02:54] <Dreamer3> but for most chips it's just a FUSE
[21:03:10] <PoppaVic> well, I already knew the 328p had it - not met the other kids
[21:03:13] <Dreamer3> man i feel silly now, so much to learn
[21:03:34] <PoppaVic> yes, set a fuse, specifies 'main' and set the zero-jmp
[21:08:34] <Dreamer3> so now
[21:08:46] <Dreamer3> is the AVR 16u usb controller code open source?
[21:10:31] <Dreamer3> http://arduino.cc/en/Hacking/DFUProgramming8U2
[21:10:33] <Dreamer3> interesting
[21:10:45] <Dreamer3> so you can flash it after you disconnect it from usb
[21:11:01] <Dreamer3> i guess the protocol is simply enough to just do like high/low over base USB wires?
[21:12:27] <Dreamer3> *looking*
[21:14:33] <Dreamer3> i don't see how
[21:16:05] <Dreamer3> HAHAHA
[21:16:08] <Dreamer3> it's a fucking bootloader
[21:16:13] <Dreamer3> http://www.atmel.com/Images/doc7618.pdf
[21:16:26] <Dreamer3> DFU is a boot loader on the 16u
[21:16:32] <Dreamer3> i'm too new to ask the right questions :)
[21:16:40] <PoppaVic> lemme read, already
[21:16:50] <Dreamer3> so the chip doesn't go anywhere it just resets and runs the bootloader
[21:17:46] <Dreamer3> rofl
[21:17:48] <Dreamer3> too easy
[21:18:02] <Dreamer3> which is why there is no "What if i fuck up my chip bad" FAQ
[21:18:12] <Dreamer3> worse you can do it mess it up and have to DFU it again
[21:19:46] <Dreamer3> so i think you could do it but you'd have to hard wire some of those extra C register pins
[21:20:23] <Dreamer3> and have some way to switch it out of "Talk to main chip" into "program main chip" mode
[21:20:44] <Dreamer3> since you'd want it to pretend to be a stk500 or whatever, not a ardiuno :)
[21:22:11] <PoppaVic> ok I need to read that later - because that STILL doesn't explain the ability to shoot a bootloader into a NAKED avr chip
[21:22:29] <Dreamer3> you do that over SPI
[21:22:37] <Dreamer3> most all AVR chips support that are the hardware level
[21:22:42] <atom1> first time bootloader loads via ISP
[21:22:50] <Dreamer3> right, that's how you BURN a bootloader
[21:22:52] <atom1> then you change the boot fuses
[21:23:05] <Dreamer3> but there is no reason the ATMega16u2 couldn't do that TO the larger chip
[21:23:11] <Dreamer3> other than the pins not being connected
[21:23:21] <atom1> true
[21:23:22] <Dreamer3> and it not being a necessarily "safe" mode... i'd have a jumper or something
[21:23:29] <atom1> some of their demo boards do that iirc
[21:23:44] <atom1> or at least after you load dean's code in it
[21:23:52] <atom1> xplain
[21:23:53] <Dreamer3> ok so again, is the code for the ATMega16U2 usb controller available?
[21:24:14] <atom1> you may have to request it but i think it is
[21:25:07] <Dreamer3> omg
[21:25:11] <Dreamer3> my opinion of arduino keeps going up
[21:25:14] <Dreamer3> here it is in the main source tree
[21:25:19] <Dreamer3> and the DFU code also :)
[21:25:32] <Dreamer3> usb serial is 243 LOC
[21:25:41] <PoppaVic> link
[21:26:28] <Dreamer3> i have the source local
[21:26:31] <Dreamer3> it's in github though
[21:26:42] <Dreamer3> hardware/arduino/firmwares
[21:26:47] <Dreamer3> that's the dir
[21:30:16] <Dreamer3> though it doesn't seem to use the fuse trick
[21:30:20] <Dreamer3> AVRDUDE_FUSES = -U efuse:w:0xF4:m -U hfuse:w:0xD9:m -U lfuse:w:0xFF:m
[21:30:28] <Dreamer3> http://www.engbedded.com/cgi-bin/fcx.cgi?P_PREV=ATmega16U2&P=ATmega16U2&M_LOW_0x3F=0x3F&M_HIGH_0x06=0x00&M_HIGH_0x20=0x00&M_EXTENDED_0x07=0x04&M_EXTENDED_0x08=0x00&B_SPIEN=P&B_HWBE=P&B_BODLEVEL1=P&B_BODLEVEL0=P&V_LOW=FF&V_HIGH=DF&V_EXTENDED=F4
[21:40:43] <Dreamer3> wait isn't there a DFU jumper
[21:43:00] <Tom_itx> to enter dfu mode?
[21:43:35] <Tom_itx> short HWB then pulse reset
[21:43:39] <Tom_itx> low
[21:43:42] <Tom_itx> both
[21:43:47] <phinxy> Wheres a good place to ask for regex help?
[21:45:00] <learath> How complicated?
[21:45:24] <phinxy> very easy
[21:45:36] <learath> Well?
[21:46:04] <phinxy> basicly i just want to find <category>Episodes HD</category> in a rss
[21:46:24] <phinxy> dont need the last </category>
[21:46:53] <phinxy> sorry for OT >.< now i feel bad
[21:47:47] <learath> s/\<\/category\>// ?
[21:49:43] <Dreamer3> but the amtel PDF says it is
[22:06:11] <Dreamer3> ha
[22:06:15] <Dreamer3> man
[22:06:17] <Dreamer3> these tiny chips
[22:07:01] <Dreamer3> so if you HWBE then it user the reset vector address programmed
[22:07:05] <Dreamer3> *pull down
[22:07:11] <Dreamer3> and it's pulled down by default on new boards
[22:07:22] <Dreamer3> and the vector address is programmed, just not enabled
[22:22:19] <Dreamer3> man
[22:22:23] <Dreamer3> i wish PDFs have <title> tags
[22:22:27] <Dreamer3> having a bunch open in safari is madness
[22:23:07] <learath> I wish PDFs had cattle prods & electric chairs :P
[22:38:13] <Dreamer3> ok now i'm disapopinted
[22:38:33] <Dreamer3> "two .hex files in this directory combine the dfu and serial firmwares into a single file"
[22:38:39] <Dreamer3> where is the Makefile or process to make this reproducable?
[22:51:09] <Dreamer3> guess that's more of an arduino question maybe :)
[22:52:16] <Dreamer3> might have to change the jump point though
[22:52:22] <Dreamer3> but maybe there is no room
[22:52:39] <Dreamer3> usb firmware is almost 4k
[22:52:54] <Dreamer3> and dfu loader weighs in at 3.5kish
[22:53:42] <Tom_itx> i just tied HWB low on my board
[22:53:56] <Dreamer3> man usb libraries must be HGUE
[22:54:09] <Tom_itx> LUFA
[22:54:09] <Dreamer3> the source is only 240 lines
[22:54:23] <Dreamer3> is lufa huge?
[22:54:31] <Tom_itx> it has alot of demos etc so i dunno
[22:54:35] <Dreamer3> it says it's "Lightweight" :)
[22:54:45] <Dreamer3> i'm sure the demo's aren't compiled in
[22:54:55] <Tom_itx> it was for a while the bootloader in uno
[22:55:00] <Tom_itx> not sure if it still is
[22:55:26] <Dreamer3> what was?
[22:55:34] <Tom_itx> dean has a bootloader you should look at
[22:55:34] <Dreamer3> LUFA is a usb device framework
[22:55:41] <Tom_itx> uh huh
[22:55:48] <Tom_itx> but he has a bootloader as well
[22:56:23] <Tom_itx> serial bridge was what it did in the uno iirc
[22:56:41] <Tom_itx> to take the place of the FTDI chip
[22:57:06] <Dreamer3> yeah, that's what the usbserial is doing now
[22:57:26] <Dreamer3> to allow you to talk to the arduino over serial
[22:57:26] <Dreamer3> is that what you're talking about?
[22:57:30] <Tom_itx> the original one fit in 8k
[22:57:36] <Tom_itx> yes
[22:57:55] <Tom_itx> but later on i noticed they started using the 16k chip
[22:58:12] <Dreamer3> well this all fits in 4k
[22:58:14] <Dreamer3> but when you have the DFU
[22:58:23] <Dreamer3> i was considering adding a SPI programmer on top of all that
[22:58:33] <Dreamer3> to reprogram the main chip via SPI over the usb serial
[22:58:45] <Tom_itx> xplain do that
[22:58:57] <Tom_itx> at least with his loader
[22:58:57] <Dreamer3> link?
[22:58:57] <Tom_itx> i haven't tried it though
[22:59:12] <Tom_itx> you should ask dean about it
[22:59:12] <Dreamer3> it shouldn't be possible because the right pins aren't connected
[22:59:23] <Dreamer3> the AMega16u2 needs access to the SPI pins
[22:59:36] <Tom_itx> jumpered something
[22:59:42] <Tom_itx> on the xplain
[22:59:53] <Tom_itx> http://fourwalledcubicle.com/
[23:00:06] <Tom_itx> http://fourwalledcubicle.com/XPLAIN.php
[23:00:11] <Tom_itx> there
[23:00:49] <Dreamer3> man i've done so much reading today
[23:02:57] <Tom_itx> http://fourwalledcubicle.com/AVRISP.php
[23:03:02] <Tom_itx> recognize that?
[23:05:09] <DarkSector> How can I learn to create a boatloader? I have read the source code for optiboot, the arduino boot loader, but I can't understand it. Is there a resource to learn how to make the boot loader?
[23:05:22] <Tom_itx> read app note 109
[23:05:23] <Tom_itx> iirc
[23:05:41] <Dreamer3> DarkSector: what do you not understand?
[23:05:46] <Dreamer3> perhaps not the best project to start with
[23:06:12] <DarkSector> Dreamer3 well I don't recall all the things, but they were so many. I gave up on it a day ago.
[23:07:11] <Tom_itx> yes, app note AVR109: Self Programming AVR
[23:08:13] <DarkSector> Okay, let me check it out
[23:08:27] <Tom_itx> i've compiled the source
[23:08:34] <Tom_itx> seems to work
[23:09:35] <DarkSector> Nice, this is a good introduction
[23:09:51] <Tom_itx> AVR106: C functions for reading & writing to Flash Memory
[23:10:02] <Tom_itx> Self-programming” makes it possible for an AVR to reprogram the Flash memory during program run. This application note provides C functions for accessing the Flash memory.
[23:10:31] <Tom_itx> better not try that one first
[23:10:33] <DarkSector> Sweet
[23:11:53] <Dreamer3> rofl
[23:11:57] <Dreamer3> yeah that is pretty cool
[23:12:05] <Dreamer3> though some parts of the memory aren't always readable during flash
[23:12:12] <Dreamer3> so one might have to work around that
[23:12:17] <Dreamer3> i didn't understand the division of areas
[23:12:21] <Tom_itx> you can protect some too
[23:12:23] <Dreamer3> it's not just based on what you're writing
[23:14:13] <Dreamer3> Tom_itx:
http://fourwalledcubicle.com/XPLAIN.php
[23:14:14] <Dreamer3> excatly
[23:14:22] <Dreamer3> except they built it from the beginning to allow that
[23:14:23] <Tom_itx> yep
[23:14:49] <Dreamer3> so it has the SPCI header already patched into the AT90USB1287
[23:15:11] <Tom_itx> you jumper it
[23:15:13] <Dreamer3> oh wow.. AT90USB1287 is no slouch
[23:16:07] <Tom_itx> host
[23:16:55] <Dreamer3> yeah jumper whatever, but it's built into the board
[23:17:05] <Dreamer3> on a uno or such you'd have to hard-wire a few things ugly
[23:19:09] <Tom_itx> AVR230: DES Bootloader
[23:19:12] <Tom_itx> AVR231: AES Bootloader
[23:19:29] <Tom_itx> encryption
[23:21:23] <Dreamer3> damn i finally read everything i planned to read today