#avr | Logs for 2012-01-19

Back
[00:08:17] <inflex> yay, GP PCBs arrived
[00:25:22] * inflex wiats for the stencil to cut
[00:35:07] <litropy> Roklobsta (Dum dum dum da da DADADADA!) Do you think the mkii-cn is a good long-term investment? Can you point me to a basic(ish) CRO?
[00:39:14] <litropy> I'm also seeing non-cathode ray oscilloscopes for much cheaper. Think I really need to shell out for the CRs these days?
[00:44:13] <litropy> Or I could just ... you know: http://www.amazon.com/AGILENT-MSO6032A-300MHz-16CH-OSCILLOSCOPE/dp/B0065WHES8/ref=sr_1_61?s=electronics&ie=UTF8&qid=1326954883&sr=1-61
[00:44:22] <litropy> lol
[00:51:28] <rue_house> odd
[00:51:44] <rue_house> I think return 0; is a performance hit
[00:55:48] <Valen> litropy: what do you want to do?
[00:56:17] <litropy> Well, compare two signals at once, firstly.
[00:56:35] <litropy> Valen, I'm actually finding some decent deals on used ones over here.
[00:56:41] <litropy> CROs
[00:56:46] <litropy> non-digital
[01:00:10] <rue_house> !assist avr
[01:00:11] <tobbor> Possibly http://eds.dyndns.org/~ircjunk/avr
[01:00:51] <inflex> Right, time to go see if the stencil actually matches the PCB :\
[01:01:06] <rue_house> !assist tutorials
[01:01:07] <tobbor> Possibly http://eds.dyndns.org/~ircjunk/tutorials
[01:09:08] <rue_house> http://ideone.com/0nS9c
[01:09:24] <rue_house> anyone see a reason for the complier to keep restoring r24 before the next compare?
[01:12:46] <rue_house> there is no reason for that...
[01:13:37] <rue_house> ah, -O1 cleaned it up good
[01:14:31] <rue_house> http://ideone.com/ryeus
[01:14:39] <rue_house> thats more like Iwould write it
[01:15:45] <rue_house> ok I deem this code microcontroller friendly, NEXT
[01:17:39] <_abc_> Hi guys
[01:17:50] <_abc_> Since you are going on about assembly optimization:
[01:18:22] <rue_house> I'm optimizing my C by looking at the way the compiler turns it into assembler
[01:18:23] <_abc_> Any idea why there may be a serious diffrence between 4.5.1 output binary size on windows and on linux?
[01:18:42] <_abc_> rue_house: yeah that is the way to go but very tedious and time consuming
[01:18:51] <rue_house> with which one using what optimization level?
[01:18:58] <rue_house> hell no
[01:19:15] <_abc_> rue_house: Also with -Os and loop unwinding finding the assembly in the listing becomes a special way to go mad
[01:19:25] <rue_house> I can immediatly tell how to mod the C to get the compiler to do what I want if it didn't work it out right away
[01:19:58] <_abc_> rue_house: hint: I salt my code with things like tmp = 0xDEADBEEF; and tmp = 0xC0FFE; which is valid hex and easy to find
[01:20:16] <_abc_> *C0FFEE
[01:20:27] <rue_house> for example if (a & b ) return; is done badly by the compiler, better to do if (a) if (b) return;
[01:20:40] <_abc_> rue_house: well I can't immediately tell and in fact I seldomly have the time to do that
[01:21:05] <rue_house> I dont to it to all my code, I'm just interested in this particular bit
[01:21:08] <Roklobsta> litropy: rigol 1052e CRO. Now USD329 jadew got on eht eother day and he loves it
[01:21:30] <rue_house> I dont write bits of my programs in assembler, I make the C compiler build it the way I'd do it in assembler.
[01:22:17] <litropy> Roklobsta, that thing looks beautiful.
[01:22:49] <rue_house> http://ideone.com/ryeus <-- thats from gcc, I couldn't do better
[01:23:07] <rue_house> less adding comments, but thats not my point
[01:23:24] <litropy> Roklobsta, peeps: what do you think about logic analyzers instead? http://www.sparkfun.com/products/8938
[01:25:10] <litropy> Litropy's Rigol 1052e Fund is up! send payments to justkidding@gmail.com
[01:26:36] <rue_bed> wasn't beef the entry point for the motorola monitor rom on the hc11?
[01:28:07] <_abc_> rue_house: maybe, I never used that at that level
[01:28:54] <rue_bed> so, it seems nobody has ever made an avr bootloader you just send .hex files to...
[01:29:08] <_abc_> heh wait a few days...
[01:29:20] <rue_bed> I'm just working on it now
[01:29:31] <_abc_> anyway I think I picked up the deadfeef and so on in Byte or DrDobbs many many years ago
[01:29:38] <rue_bed> not for a bootloader but for making a chip programmer
[01:29:44] <_abc_> (reading an archive of magazines)
[01:30:07] <_abc_> rue_house: several chip programmers use hex files
[01:30:37] <_abc_> rue_house: also consider a hex file rewriter running on the host, hashed hex record addresses in the download can lead to problems
[01:30:43] <rue_bed> over a serial link with no uploader hardware or software?
[01:30:48] <_abc_> hashed means non sequential address increase by line number
[01:30:52] <_abc_> rue_house: yes
[01:31:06] <_abc_> rue_house: monitor menu and one command is upload
[01:31:14] <_abc_> rue_house: done for 8051s too
[01:31:22] <_abc_> but the overhead for hex is too large
[01:31:28] <_abc_> 2x +
[01:31:45] <rue_bed> yea, I'm playing with an nxp 8051 that has a bootloader that takes ihex files
[01:31:55] * rue_bed covers his mouth
[01:31:56] <_abc_> it is much cheaper to send bytes and use escapes for 'dangerous' bytes, this is the way I am doing it now
[01:31:57] <rue_bed> ...
[01:32:08] <rue_bed> no I'm talking ascii
[01:32:19] <_abc_> rue_house: yes 8051 monitors had that feature. See if Paulmon also has it maybe you can look at code.
[01:32:25] <rue_bed> you just send the hex file to the chip via a text serial link
[01:32:29] <_abc_> yes
[01:32:37] <rue_bed> k
[01:32:48] <rue_bed> I wna tto make a bios eeprom programmer
[01:33:04] <_abc_> but do mind sequentially increasing addresses ONLY hex files and also handshaking. You can easily overrun the device like that
[01:33:12] <_abc_> rue_house: my device is a universal programmer
[01:33:47] <rue_bed> does it require special software on the pc?
[01:34:08] <_abc_> well not special, but some older compilers spit out gobs of hex which is all over the place.
[01:34:19] <_abc_> You need to sort the lines in ascending address order at the very least
[01:34:36] <rue_bed> why :) you can write to a chip in random order
[01:34:39] <_abc_> can be done with a simple awk script
[01:34:49] <_abc_> rue_house: no you can't, think of page fills in flash
[01:35:21] <_abc_> also many chips are programmed based on an internal address counter which is clocked to increment
[01:35:32] <_abc_> you can't simply jump around in the programming address space
[01:35:41] <rue_bed> hrm, I cant remmeber now if the bios eeproms require a whole page at once
[01:36:00] <_abc_> rue_house: I don't rememeber that either but in general flash is internally paged on write
[01:36:14] <_abc_> and pages can get quite large so maintaining buffers in the mcu gets hard
[01:36:41] <_abc_> then you have to have the incoming hex arranged so addresses always increment and you write directly into the chip
[01:37:25] <pingec> damn, I tried to debug via debugwire in avr studio 5 and something went wrong and now even ISP programming isn't working anymore :/
[01:37:47] <pingec> Could it be something with fuses?
[01:37:50] <_abc_> rue_house: what is ideone.com?
[01:38:17] <rue_bed> my current woking paste site
[01:38:24] <_abc_> pingec: yes. Did you botch the fuses, especially SPI prog? Also do you have an external clock source attached?
[01:38:33] <rue_bed> they seem to go down on a rotational basis, so I just jump around
[01:38:38] <_abc_> rue_house: heh
[01:38:49] <_abc_> rue_house: pastebin.ca works fine I have a bash script for it
[01:39:00] <_abc_> rue_house: also ompldr
[01:39:12] <rue_bed> yea, the link I have to ideone says pastebin
[01:40:11] <pingec> _abc_ no i did nothing with the fuses but avr studio probably did? I dont have an external clock source
[01:40:54] <pingec> can i fix this vith HVPP ?
[01:41:47] <rue_bed> if you set it to extenal clock, you HAVE to give it an external clock to get it back
[01:43:05] <pingec> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=838661
[01:43:14] <pingec> This is exactly what i did
[01:43:18] <pingec> will try to read the topic
[01:47:10] <pingec> damn my curiosity
[01:54:58] <rue_bed> pingec, do you need an external clock?
[02:13:57] <raek> pingec: yes, you should be able to fix it with HVPP
[02:16:14] <pingec> I don't know what I need
[02:16:26] <pingec> I need a guide on how to restore the fuses with the dragon
[02:16:58] <raek> pingec: did you touch the PRR register in your code?
[02:17:17] <pingec> no
[02:17:24] <pingec> My code was a blinking led
[02:17:54] <pingec> But I wanted to try debuggign via debugwire
[02:18:17] <pingec> and just followed the instructions from avr studio 5
[02:19:00] <jadew> I think avrdude can restore the fuses while using the dragon, if DWEN is set
[02:19:27] <jadew> otherwise (I don't have the dragon) but I suppose you can do a high voltage programming with it
[02:20:04] <pingec> Note that PP/HVSP (Parallel and High Voltage Serial Programming) is not recommended to
[02:20:04] <pingec> use off board the AVR Dragon. PP/HVSP signals are not level converted on the AVR
[02:20:04] <pingec> Dragon.
[02:20:09] <pingec> What does that mean for me?
[02:20:42] <jadew> I have no clue, you should deffinitely try to use avrdude
[02:21:07] <jadew> a guy in here made a patch for avrdude, that disables debugWire before starting ISP
[02:21:31] <raek> pages 19 and forward shows how to connect the dragon in HVPP mode: http://people.ece.cornell.edu/land/courses/ece4760/AtmelStuff/dragon.pdf
[02:22:12] <pingec> will read thanks
[02:22:44] <raek> it only lists the connections for a few of the µCs
[02:23:11] <pingec> actually
[02:23:14] <pingec> I connected mine
[02:23:21] <pingec> following that same guide
[02:23:27] <raek> so you might need to look up the HVPP pinout of the dragon connector and of your µC (should be in the data sgeet)
[02:23:55] <pingec> I did it as it shows for my ATmega168A
[02:23:56] <raek> (if it's not listed in that pdf)
[02:24:25] <jadew> ah, pingec, don't you have a disalbe debug wire option in avrstudio?
[02:24:28] <raek> pingec: ah, at page 23?
[02:25:01] <raek> (I haven't used debug wire, but I have resurrected AVRs using HVPP and the dragon)
[02:25:12] <pingec> yes that page
[02:25:27] <pingec> jadew dont know
[02:25:31] <pingec> where should i look for it?
[02:25:39] <jadew> "Then when debugging has started a new menu item is added to the bottom of the Debug menu, AVR Dragon Options.
[02:25:39] <jadew> Select the new menu item Debug -> AVR Dragon Options. This brings up the following dialog "
[02:25:44] <jadew> http://forward.com.au/uCLedDriver/exitDebugWire.png
[02:25:52] <grummund> jadew: the problem is once it's stuck in dW it needs HVPP or JTAG to recover.
[02:26:17] <jadew> grummund, you can turn dW off until the next power down
[02:26:17] <raek> ouch
[02:26:26] <jadew> and then you can reprogram the fuses with ISP
[02:26:50] <jadew> I think the option in avr studio might actually do the whole thing for you
[02:27:07] <raek> btw, is it possible to debug with dW from the AVR eclipse plugin?
[02:27:13] <jadew> pingec, got that text and image from here: http://forward.com.au/uCLedDriver/build_basic_uC_led_driver.html
[02:28:01] <pingec> hmm
[02:28:12] <jadew> let me know if it works, I'm kinda curious
[02:29:05] <grummund> It should be possible, but Atmel's own advice is to use HVPP or JTAG to recover.
[02:31:51] <pingec> I have avr studio 5
[02:31:54] <pingec> its different
[02:32:10] <pingec> Anyways I think it programmed the fuse via spi
[02:32:18] <pingec> but then failed to start the debug session
[02:32:22] <pingec> and now its stuck
[02:32:34] <pingec> would be nice to get it debugging right
[02:32:47] <jadew> ah, then you can't do it like that and it's probably stuck because you don't use a crystal
[02:32:52] <jadew> are you using one?
[02:33:32] <pingec> no
[02:33:34] <pingec> do i need one?
[02:33:37] <jadew> yeah
[02:33:42] <pingec> for debugwire?
[02:33:45] <jadew> dW needs a really good clock
[02:33:52] <pingec> i see
[02:33:58] <jadew> otherwise the communication becomes unreliable
[02:34:01] <pingec> any frequency will do?
[02:34:22] <jadew> not sure, I managed to communicate with dW using a 16Mhz crystal
[02:34:32] <grummund> it still needs to be unbricked first
[02:34:33] <pingec> but hey i still need to program fuses right?
[02:34:36] <jadew> might work with different ones too, especially since you're using a good programmer
[02:34:37] <pingec> yeah
[02:34:41] <pingec> thought so
[02:34:59] <jadew> well, that's what I'm saying, if you're using the clock, you can get dW working again
[02:35:06] <pingec> So I need to figure out this HVPP
[02:35:14] <jadew> if you get dW working again, you can disable it trough dW
[02:35:19] <jadew> and then write it by ISP
[02:35:34] <jadew> anyway, since you have a dragon, you should really get HVPP working
[02:35:38] <jadew> it's a good thing to have
[02:35:51] <pingec> I have no clue on how to do that
[02:36:20] <grummund> google dragon hvpp atmega
[02:36:38] <grummund> all you need is the connection details
[02:36:39] <raek> pingec: HVPP will always work, even without an external clock or crystal, but it's a mess to connect all those wires... if you have a crystal, try that first
[02:37:00] <pingec> yes but dont i need to program fuses
[02:37:05] <pingec> for the crystal to work... ?
[02:37:13] <grummund> raek: and how would he set the fuses to use an external crystal?
[02:37:27] <jadew> I guess that's true
[02:37:27] <pingec> hmm need to google now
[02:37:33] <raek> pingec: just connect a wire from A to A, from B to B, etc following the schematic on page 23
[02:37:59] <pingec> oh really?
[02:38:00] <pingec> cool
[02:38:00] <raek> grummund: I was under the impression that when setting DWEN, the AVR starts to use the external crystal
[02:38:40] <raek> and if pingec connects, he/she should be able to use dw to disable dw, as jadew said
[02:38:43] <pingec> I see there are many topics about avr studio5 + dragon + debugwire = bricked chip
[02:38:48] <grummund> raek: do you think so? i wasn't ware of that.
[02:39:04] <pingec> well if I find 2 caps
[02:39:06] <pingec> I can try that
[02:39:08] <pingec> and see
[02:39:24] <raek> grummund: I'm not sure at all. but it would explain it.
[02:39:38] <pingec> but my led is blinking
[02:39:49] <pingec> so it's using the internal oscillator... right?
[02:40:03] <pingec> I just cant program it
[02:40:31] <pingec> bah, brb need to connect this
[02:41:12] <raek> pingec: do you have a capacitor connecteed to the RESET pin?
[02:41:33] <pingec> no
[02:41:59] <pingec> All I have is the dragon wired to the chip according to that pdf above
[02:42:02] <pingec> and a led
[02:42:13] <raek> ("Capacitors connected to the RESET pin must be disconnected when using debugWire")
[02:42:24] <pingec> Ah I see
[02:42:46] <raek> pingec: it's probably best to disconnect everything from the AVR while you're doing HVPP
[02:46:08] <raek> including the power supply
[02:46:59] <grummund> pingec: http://nuxx.net/gallery/d/81976-1/IMG_3393.jpg
[02:47:21] <pingec> ok will do
[02:47:23] <pingec> thanks
[02:47:40] <pingec> im jsut trying to find additional wires
[02:58:17] <grummund> http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon.htm
[02:58:20] <grummund> http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_PP_Description.htm
[02:59:02] <grummund> damn that took a while to track down
[03:01:41] <grummund> http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/SCKT3200A2.htm
[03:01:51] <grummund> pingec: mega168 is there ^^
[03:02:19] <pingec> hehe thanks a lot
[03:03:16] <pingec> its the same as in that pdf
[03:03:20] <pingec> only with colors
[03:06:19] <inflex> *sigh* I really wish AVRs would not work 99.9% of the time without their RST line tied high
[03:06:46] * inflex has some designs using the T10...and I haven't (yet) bothered to pull the RST line high, or blow the RST fuse ... but it still works :p
[03:21:15] * Roklobsta always ties his resets.
[03:22:37] <inflex> yeah, I do too... but it was amusing to see it working "fine"
[03:23:14] <inflex> the RST resistor is on the other side of the PCB, so I don't get to do it in the single-reflow operation... instead I think I'll just blow the RST fuse when I burn the chip - easy since I have Tom_itx 's programmer + HV adapter
[03:25:49] * Roklobsta blows his AVR fuses with stripped lamp cord and 240VAC.
[03:54:36] <inflex> heh
[03:54:45] <inflex> Some would use a butterfly.
[03:55:21] <ziph> Monarch?
[03:56:05] <inflex> I prefer to use the Dunk Island one... better with higher energyparticles
[03:57:03] <ziph> Ohh, nice, why don't you move there? :)
[03:58:15] <inflex> well, I was referring to the butterfly alone ... while the actual Dunk Is is nice, it's not for me
[03:59:15] <ziph> You don't like heat or humidity?
[04:08:23] <inflex> heat.
[04:08:47] <inflex> or rather, I dislike being at over 28'C for more than 3/4 of the year :(
[04:09:11] <scuzzy> inflex: what's the temp there?
[04:11:34] <inflex> we spendmost of the time over 30... frequently over 35
[04:12:09] <inflex> and a smattering of a week or three over 40
[04:14:19] <ziph> inflex: What's stopping you from moving?
[04:18:18] <scuzzy> inflex: been around 38 here recently
[04:18:21] <scuzzy> so, I know how you feel dude
[04:21:34] <inflex> ziph: genuinely too broke atm
[04:21:58] <inflex> Anyhow,there was a small glimmer of happy today when the new boards from GP worked fine.
[04:22:56] <inflex> scuzzy: ja, it decimates me - I find it utterly impossible to achieve any real work during the day. Not until ~midnight is it cool enough to get started... and then it's too late.
[04:23:18] <scuzzy> yeah
[04:23:20] <scuzzy> I know how you feel
[04:23:26] <inflex> Still, did some different work last night, worked on revamping my wife's novel cover, giveit a bit more zing
[04:23:27] <scuzzy> my brain gets pretty sluggish
[04:23:42] <ziph> inflex: What does it look like now?
[04:23:53] <ziph> Is it on Amazon Kindle?
[04:24:03] <inflex> http://dxp.me/i/gc-tweak4.png
[04:24:06] <inflex> yeah, we do Amazon
[04:24:10] <inflex> (kindle)
[04:24:31] * inflex needs to do a few more covers as well
[04:24:47] <inflex> but right now, I have to improve the blurb for the book, it's just awful
[04:24:58] <ziph> Where's the photo from? :)
[04:25:08] <inflex> stock phot
[04:25:25] <ziph> Where's your wife from? I haven't heard the name Elita before. :)
[04:25:40] <inflex> She's Australian... but I think the name has a French backgruond or something
[04:25:46] <ziph> Ahh. :)
[04:26:13] <inflex> http://www.amazon.com/gp/product/B004UVZXMA
[04:26:16] <inflex> That's the Amazon link
[04:27:49] <inflex> Waiting for Amazon to update the cover picture for their site.... takes 12~36hrs
[04:28:00] <scuzzy> who's on the cover?
[04:28:04] <scuzzy> your wife?
[04:28:28] <ziph> It's stock photography scuzzy, he said that before. :)
[04:28:31] <inflex> nah - it's a picture we purchased at a stock site
[04:28:46] <scuzzy> sorry
[04:28:59] * inflex then composites the cover using Inkscape and sometimes a bit of GIMP on the images
[04:29:00] <scuzzy> lots of window switching going on now
[04:29:39] <ziph> Is she writing another?
[04:29:52] <inflex> I'm fearing what it'll come out like on a CMYK process... because rarely do these stock images work too well
[04:30:17] <inflex> ziph: she's written several books, but right now we only have the two actually published/out-there with another two soon to follow.
[04:32:01] <scuzzy> "By Stacey - See all my reviews
[04:32:01] <scuzzy> This review is from: Guardian (Kindle Edition)
[04:32:01] <scuzzy> I was so excited when i was asked to review this book, gotta love the book covers! *winks* "
[04:32:03] <scuzzy> hur hur
[04:32:39] <ziph> Pity there's some self masturbatory negative review at the top of tree of life when the rest are good and the average is 4.
[04:32:40] <scuzzy> at least someone appreciates your handy work inflex
[04:32:52] <inflex> ziph: ah yes, the big looooong one
[04:33:09] <inflex> ziph: what amuses me about that 1.9 star review was that the review in itself was precisely what he was deriding
[04:33:25] <inflex> ziph: we actually know the guy... he's not very popular with many people at all.
[04:34:09] <inflex> ziph: Anyhow, ToL was deliberately written in the long-style / archaic manner, and as such, yes, a lot of people don't like it if they're not ready for it.
[04:35:07] <inflex> scuzzy: heh, it is nice when the cover does its job and pulls people in... but that's where our weakness is then exposed, the "blurb", between myself and Elita, we just can't seem to write one to save our lives... and it's costing us a LOT of sales opportunities.
[04:35:42] <ziph> inflex: Steal some outlines from the good reviews of it. ;)
[04:36:11] <inflex> ziph: nice point, thanks.
[04:36:35] <ziph> "new refreshing twist to life as a vampire"
[04:36:58] <inflex> Almost makes it sound like a Lemon-twist with sparkling water :p
[04:37:05] <ziph> The one from Stacey has some choice bits in it. :)
[04:37:20] <ziph> Yeah, not so much the wording, but the aspects of the book that they're emphasizing. :)
[04:38:05] <inflex> Indeed. I think I'll go take a shower, put on the coffee... and start trying to write a blurb for Guardian... then I can get out and push it again... sold a few hundred on the first month we released it, but you have to keep pumping this stuff else you just fall into the void
[04:38:17] <ziph> Yeap.
[04:38:18] <inflex> The next book "My boyfriend is a Zombie" is already a hit and we've not even released it yet O_o
[04:38:26] <ziph> Heh. :)
[04:38:40] <inflex> http://elitadaniels.com/images/zombie-cover.jpg <=- cover I did for it
[04:38:47] <ziph> I actually read that as "My boyfriend is a vampire" because every second TV show is that. :)
[04:38:53] <ziph> Zombie is different though. :)
[04:38:57] <theBear> heh, i'm a hit and I haven't even been locked up yet <grin>
[04:39:19] <ziph> inflex: Is there a paperback version on Amazon?
[04:39:26] <inflex> heya theBear ... got any Marantz CD63/4/7 sleds?
[04:39:52] <inflex> ziph: only for ToL atm... I've not submitted a paperback for production of "Guardian" - but I will be soon, because now I can get them done here in Australia via Lightning Source
[04:40:07] <ziph> They're on-demand?
[04:40:20] <inflex> theBear: repaired my CD63 but alas, it seems the laser is dead/dying now :(
[04:40:40] <inflex> ziph: to Amazon and such, yes... but I also buy boxes of the books for promo tours etc
[04:45:12] <theBear> i got no sleds anymore, hopefully i'll never have to touch one again :) i like cheap mass produced 'cdrom drives' and digital extraction
[04:46:13] <inflex> oh well, I'll probably grab one for about $40... I do love the sound from the CD-63, at least when it was matched up with the PM-57 driving a pair of KEF Q30s
[04:46:20] <inflex> (for the music I listen to)
[04:46:31] <inflex> but, I'm honestly just tring to fix it up to sell it
[04:47:30] <inflex> After one of the Q30s died, I lost my spirit
[04:47:49] <inflex> (yea, they aren't godly speakers by any measure, but they were nice for me)
[05:03:18] <Bushman> ave
[05:06:17] <Bushman> i'm doing this micro http server with enc28j60 ethernet module
[05:06:28] <Bushman> things, as always, got complicated.
[05:07:28] <Bushman> i was able to use an example to display some simple site with one form input and right now it only works on old Internet Explorer ;/
[05:07:45] <Bushman> something is terribly borked
[05:08:13] <Bushman> (where borked is a synonym for "f***ed up")
[05:11:31] <karlp> how many tcp connections do you support?
[05:11:38] <karlp> browsers like to use quite a few these days.
[05:11:52] <Bushman> o_O
[05:12:08] <Bushman> no idea... i just connect once
[05:12:15] <pingec> shouldnt they be smart enough to fallback to only one?
[05:12:35] <karlp> pingec: sure, if your tcp library knows how to properly refuse and so on.
[05:12:55] <pingec> ahh :D
[05:13:00] <pingec> but still...
[05:13:06] <Bushman> i mean... i use some lib, i don't know what it supports and what not :P
[05:13:12] <karlp> what lib?
[05:13:44] <Bushman> karlp: the one for enc28j60 which is avilable online
[05:13:47] <Bushman> :P
[05:14:31] <pingec> grummund jadew raek thanks for the help, I have HVPP working now and will clear the DWEN fuse. http://shrani.si/f/2D/Eg/2PUsvdiw/capture.png
[05:14:41] <pingec> then i'll try again with an external crystal
[05:15:18] <pingec> Bushman are you on windows?
[05:15:19] <Bushman> anyway... it's all working in IE. in FireFox i get the expected result but for example when i print out the buffer of first client query it doesn't look "whole and compleet"
[05:15:26] <pingec> oh wait... ie
[05:15:27] <pingec> lol
[05:15:32] <pingec> try running fiddler
[05:15:36] <Bushman> pingec: window, linux, symbian. take your pick :P
[05:15:54] <pingec> or is fiddler not enough low level
[05:16:12] <Bushman> i'm on linux now, i only do the coding on someone else PC with windows
[05:16:56] <pingec> try using wireshark
[05:17:01] <pingec> to see whats going one
[05:17:03] <pingec> *on
[05:17:08] <pingec> with the connections
[05:17:52] <Bushman> probably i will have to eventually :P
[05:18:30] <Bushman> but right now i think it's just a problem with buffer being not read to the end or something :P
[05:20:28] <pingec> maybe try playing with these settings http://www.speedguide.net/articles/firefox-ie-browser-tweaks-2448
[05:20:35] <RikusW> pingec: what tool are you using ? the dragon ?
[05:20:41] <pingec> RikusW yes
[05:20:52] <jadew> Bushman, you said it's working on older IE?
[05:20:56] <RikusW> dragon can disable DWEN without using HVPP
[05:21:03] <pingec> RikusW how?
[05:21:03] <RikusW> pingec: as4 or as5 ?
[05:21:15] <pingec> hmm, what is that?
[05:21:20] <pingec> oh
[05:21:21] <RikusW> you're using as4 ?
[05:21:21] <pingec> as5
[05:21:35] <RikusW> as4 have a nice commandline tool for doing that
[05:21:48] <RikusW> in as5 you probably have to be in debug mode to do it
[05:22:10] <pingec> But I could not go in debug mode
[05:22:17] <RikusW> the will be a disable dW button somewhere while debugging, probably in the dragon options dialog
[05:22:31] <RikusW> get as4 too ?
[05:22:40] <pingec> Well I can install it
[05:22:47] <RikusW> there is a commandline tool for the dragon
[05:22:58] <pingec> ok
[05:23:04] <RikusW> the avr does need a clock for dW to work...
[05:23:15] <RikusW> no clock, no dW
[05:23:21] <RikusW> then you need HVPP
[05:23:24] <pingec> so the source of my problems was not having an external crystal?
[05:23:40] <RikusW> whats your fuse settings ? and what avr ?
[05:23:54] <RikusW> hex values ?
[05:23:59] <pingec> http://shrani.si/f/2D/Eg/2PUsvdiw/capture.png
[05:24:25] <pingec> what do you mean by hex values?
[05:24:47] <RikusW> like 0xFF
[05:24:56] <jadew> RikusW, I'm glad you're around, I've read most of your discussions in the past year (from the log) about dW and I've read that document you wrote, I have a question tho, any idea if dW will work at 125kbps by default if I use a crystal different than 16mhz? I suppose it wouldn't since, the controller won't be able to tell its own frequency, correct? does that mean that in order to connect to dW, the master device (not the target) will have to try to figure out th
[05:25:27] <RikusW> dW default bitrate == clock / 128
[05:25:30] <pingec> yes but hex values of what :/
[05:25:38] <pingec> forgive me, I'm new to this
[05:25:43] <RikusW> but you can change the divider
[05:25:49] <RikusW> pingec: the fuses
[05:26:01] <jadew> yeah, but in order to do so, you need to know the baud rate it's opperating at first
[05:26:17] <RikusW> so you need baud detection
[05:26:29] <jadew> which means that's the only way to connect to an unknown device with dW, you have to send 55 over different baud rates till you get a reply
[05:26:31] <jadew> yeah
[05:26:38] <pingec> RikusW you mean these values: http://shrani.si/f/2D/Eg/2PUsvdiw/capture.png
[05:26:39] <Bushman> jadew: yes, on ie, seems not only older cause it also works on other PC with newer IE and also in FF but still seems borked. things still aren't how they should be
[05:26:39] <pingec> ?
[05:26:42] <Bushman> :P
[05:27:04] <RikusW> pingec: yes
[05:27:06] <jadew> Bushman, are you sure it's not just a case of broken HTML?
[05:27:19] <pingec> well those are the actual ones...
[05:27:27] <RikusW> jadew: you don't send 55 you receive it
[05:27:35] <pingec> I think they are ok (except for DW fuse)
[05:27:40] <RikusW> after reset goes high
[05:28:01] <jadew> I see, in my tests I noticed that the target device echoes back everything
[05:28:10] <jadew> and 55 means pretty much nothing
[05:28:17] <jadew> so it can be used for that
[05:28:23] <jadew> basically pinging
[05:28:25] <RikusW> using the circuit I gave ?
[05:28:32] <RikusW> that one echos everything
[05:28:49] <jadew> ah
[05:29:05] <RikusW> but giving some commands give a reply
[05:29:10] <RikusW> in addition to the echo
[05:29:45] <jadew> yeah, but what could you give to get a constant response across all AVRs?
[05:30:03] <RikusW> 0xF3 gives the signature
[05:30:12] <RikusW> without the atmel id
[05:30:15] <RikusW> so 2 bytes
[05:30:45] <jadew> is dragon doing the detection automatically?
[05:30:52] <RikusW> yes
[05:31:01] <RikusW> in software
[05:31:17] <jadew> I see, so it sets different baud rates and sends something
[05:31:32] <amee2k> iirc the reason 0x55 is used is because it is an alternating 01 bit pattern, no?
[05:31:39] <jadew> yes
[05:31:54] <RikusW> so you need a soft autobauding uart from 1kbps to 156kbps
[05:32:02] <amee2k> which makes recovering an unknown clock much easier than from an arbitrary (non-repeating) pattern
[05:32:13] <pingec> ok, got 7.372Jb, 18.43JT1, 11.05JY and a 14.74Je crystal, any advice on which to use with ATmega168A ?
[05:32:30] <RikusW> jadew: it pulls reset low, releases it and wait for the 0x55 to detect the baud
[05:32:41] <jadew> ah ha
[05:32:47] <jadew> interresting
[05:33:13] <pingec> if it matters at all?
[05:33:17] <RikusW> pingec: you're going to use UART ?
[05:33:24] <pingec> yes
[05:33:39] <RikusW> all of those should work
[05:33:53] <RikusW> it depends on how much speed you want/need
[05:34:00] <pingec> Is it safer for any reason to go with the lowest freq?
[05:34:09] <pingec> I think all are good
[05:34:10] <RikusW> not really
[05:34:16] <RikusW> m168 can do 20MHz iirc
[05:34:19] <pingec> yes
[05:34:39] <RikusW> you have 18pF caps ?
[05:34:40] <amee2k> i tend to think of higher frequencies as safer since it makes timing in software somewhat less critical
[05:34:47] <pingec> no, need to buy some
[05:34:54] <pingec> 18pG is what i need?
[05:34:57] <pingec> *pF
[05:35:08] <RikusW> without 2 of those it will fail to oscillate
[05:35:19] <RikusW> xt1/xt2 -> gnd
[05:35:26] <amee2k> i've never used any loading caps on solderless boards. the contacts seem to have suitable parasitic capacitance as they are :)
[05:35:28] <RikusW> you probably know that ?
[05:35:41] <pingec> yes it's in the datasheet
[05:35:47] <Steffanx> Same here amee2k
[05:36:00] <amee2k> hehe
[05:36:25] <RikusW> jadew: I'll probably start working on autobaud firmware sometime...
[05:36:41] <pingec> http://shrani.si/f/3P/11c/3AS68ttc/capture.png
[05:36:43] <jadew> RikusW, I'll be doing the same thing, probably starting next week
[05:36:44] <pingec> like this, right?
[05:36:44] <Steffanx> Just implement it on a AVR32 or ARM .. that's easier RikusW :)
[05:36:54] <RikusW> jadew: but I expect the pc side software to be much more complicated... it wont work with as4/as5....
[05:36:57] <Bushman> jadew: no. HTML is broken FOR SURE
[05:36:59] <grummund> pingec: i didn't read the full scroll back, but well done :D
[05:37:05] <jadew> RikusW, I'm trying to get an emulator working with AVR Studio
[05:37:11] <Bushman> the problem is with client headers
[05:37:26] <RikusW> jadew: you don't have a dragon ?
[05:37:27] <pingec> grummund just wanted to say that it worked
[05:37:29] <pingec> so thanks
[05:37:30] <grummund> pingec: so now you might want to go back to using avrstudio 4 :P
[05:37:35] <pingec> lol
[05:37:36] <jadew> RikusW, no, just a usbtiny
[05:37:36] <pingec> :D
[05:37:38] <Bushman> i don't get consistent results
[05:37:40] <pingec> yes i guess
[05:38:01] <jadew> RikusW, haven't looked into what it will take to build the emulator, but it can't be that bad
[05:38:49] <jadew> and I actually think usbtiny could be made to support it, with an additional uC for dW communication
[05:39:04] <RikusW> jadew: if you want it to work with as5 you'll need to implement the jtagice mkii protocol....
[05:39:31] <jadew> RikusW, sounds decent
[05:39:59] <jadew> IIRC, the protocol is somewhere around the net
[05:40:09] <RikusW> jadew: its complicated and resource hungry for the ice itself...
[05:40:24] <RikusW> you'll need 2 avr's and 64kb ram
[05:40:38] <jadew> why 64k of ram?
[05:40:39] <RikusW> and not entirely documented either
[05:40:50] <Steffanx> That's why you should not use an AVR32 or ARM RikusW
[05:41:01] <RikusW> because all breakpoints are handled on the ice...
[05:41:30] <RikusW> Steffanx: like my uc3a3256 ? and clone jtag3 ? :-P
[05:41:43] <Steffanx> Whatever you want
[05:42:16] <RikusW> jtag3 protocol isn't documented.... unless its the same as mkii
[05:42:42] <jadew> RikusW, when a breakpoint occurs, the data can just be sent to the PC, no need to hold stuff in the AVR's memory
[05:42:58] <jadew> only the data it gets from dW, for the time it takes to forward it to the PC
[05:43:12] <jadew> well, it's going to be avr => avr => pc
[05:43:12] <RikusW> jadew: actually the mkii protocol required the ice to handle all breakpoints...
[05:43:20] <jadew> since one of the avr will deal with dW exclusively
[05:43:36] <jadew> RikusW, that doesn't mean you can't emulate that from software :)
[05:44:06] <jadew> AVR Studio won't know where the data is handled anyway, from its point of view, it communicates with mkii
[05:44:28] <RikusW> so you're going to create a virtual mkii on the pc ?
[05:44:39] <jadew> I guess that would be one option
[05:44:52] <RikusW> using a virtual serial port..
[05:44:54] <jadew> I haven't looked into that too much yet, but it's not excluded
[05:45:09] <RikusW> that would be easiest
[05:45:21] <RikusW> than you only need 1 avr for autobauding
[05:45:40] <jadew> it would, I figured a t45 + 2313 should get usbtiny dW capabilities
[05:46:24] <RikusW> 2313 got an uart
[05:46:25] <jadew> I tried to have dW working with V-USB on the same chip, but it's not gonna happen
[05:46:36] <RikusW> nah...
[05:46:57] <jadew> yeah, but if you're using an interrupt, it still gets screwed up by v-usb and if you're doing it in a loop the usbPoll might make you lose some bytes
[05:47:09] <RikusW> you don't have a good old serial port on the pc anymore ?
[05:47:17] <jadew> nope
[05:47:29] <RikusW> too bad :(
[05:47:52] <RikusW> using 14.745MHz gives a nice 115200bps
[05:48:11] <RikusW> making it very easy to connect to the avr's dW pin
[05:48:12] <Steffanx> Who needs that? USB-serial converter and you're done
[05:48:15] <jadew> I used 125kbps, it worked fine
[05:48:43] <jadew> I didn't use a converter either, I was comunicating with dW with the usart from 2313
[05:48:51] <jadew> and relying the info back to the pc via usb
[05:49:37] <jadew> which revealed the possible issues I'd have to deal with if I want to build it on top of usbtiny
[05:50:09] <RikusW> isn't V-USB somewhat slow ?
[05:50:25] <jadew> it is, but it's faster than serial communications
[05:50:42] <RikusW> latency is worse I guess...
[05:50:48] <jadew> yeah, that's the big issue
[05:51:06] <RikusW> even fullspeed got latency issues
[05:51:31] <RikusW> I guess its better with high or super speed
[05:51:54] <jadew> the thing about speed is that, it might be necesary to set the speed on dW a bit lower than 125
[05:52:18] <jadew> with v-usb I got at most 20k/s and that was with a big buffer
[05:52:23] <jadew> about 80 bytes
[05:52:39] <jadew> when using it on top of usbtiny, I think the buffer will be a lot smaller
[05:52:49] <jadew> so the speed will decrease as well
[05:53:39] <jadew> so setting the dW speed to something a bit slower would be a good idea, but I'm not entirely sure that's possible
[05:53:54] <RikusW> I'm going to be using a mega32u2
[05:54:03] <jadew> from the documentation you provided, it appears you can't set anythinig lower than clock / 128
[05:54:16] <RikusW> don't think it is, you can only increase it
[05:54:21] <jadew> yeah
[05:54:36] <RikusW> http://sites.google.com/site/megau2s/home
[05:54:47] <RikusW> using the m32u2 on my board
[05:55:54] <jadew> looks nice
[05:56:05] <RikusW> thank
[05:56:06] <RikusW> s
[05:56:37] <RikusW> fixed the jtag mki clone to be able to program any avr last month
[05:57:00] <RikusW> it can do debugging too on the older avr's
[05:57:21] <RikusW> just because as4 don't want to support newer ones...
[05:58:56] <jadew> it's doing it over dW?
[05:59:03] <jadew> or JTAG?
[05:59:22] <jadew> haven't looked into JTAG at all
[05:59:48] <RikusW> jtag
[06:00:33] <RikusW> you can build my jtag mki clone if you want
[06:00:37] <RikusW> its on that sige
[06:00:39] <RikusW> site
[06:00:48] <RikusW> you'll need a m328 of m168
[06:00:50] <RikusW> of m8
[06:00:55] <RikusW> or m8
[06:01:10] <RikusW> and AS4
[06:01:20] <jadew> I saw it, but I don't see tiny's in the supported list
[06:01:33] <RikusW> and the older mki supported avr's
[06:01:58] <RikusW> it supports m16 162 32 64 128
[06:02:19] <RikusW> and probably the a versions too since its about the same
[06:02:34] <jadew> I only have tiny versions around here
[06:03:07] <jadew> don't really see the use of the mega ones for the stuff I'm currently doing
[06:04:27] <RikusW> getting the ice to work will require that you use some raw avr machine code too ;)
[06:04:45] <RikusW> sending hex instructions to the avr...
[06:04:53] <jadew> shouldn't be an issue
[06:05:07] <RikusW> both jtag and dW work by executing instructions on the avr itself
[06:05:34] <jadew> I guess the list of instructions is fairly small
[06:05:40] <jadew> the ones they're using
[06:05:53] <RikusW> all supported avr asm ones
[06:06:14] <jadew> hmm
[06:06:55] <RikusW> iirc on dW you use F2 xx xx to send the instruction and then another code to execute it
[06:07:11] <jadew> probably 20
[06:07:11] <RikusW> ldi gets used a lot
[06:07:53] <jadew> anyway, I have to get back to work, thanks a lot for the info, will keep you posted on my progress
[06:08:15] <RikusW> good luck with that
[06:08:30] <jadew> will probably start playing with this next week so I'll let you know then what I found out about emulating it
[06:08:47] <jadew> thanks
[06:08:49] <RikusW> pingec: I see you have CKDIV8 enabled
[06:09:06] <pingec> yes it was like that when i got it
[06:09:17] <pingec> it divides the 8mhz clock by 8 right?
[06:09:22] <RikusW> yes
[06:09:33] <pingec> why would I want that?
[06:09:33] <RikusW> you can use CLKPR to change it in fw
[06:09:46] <RikusW> or change the fuse itself
[06:10:21] <RikusW> its for low voltage operation when the clock might be too high
[06:13:10] <pingec> so... if I use CLKPR the fuse will stay the same but I can still change the clock?
[06:14:37] <pingec> ah ill just look it up in the datasheet
[06:22:46] <RikusW> yes
[06:23:59] <RikusW> CLKPR = (1<<CLKPCE); CLKPR = u;
[06:24:49] <RikusW> When using interrupts use: u8 t = SREG; cli(); CLKPR = (1<<CLKPCE); CLKPR = u; SREG = t;
[06:36:01] <Bushman> hmm... for unknown to me reason i don't get the whole http header in my program ;/
[06:37:10] <Bushman> apparently the program gets it all but does not re-write it completly to send it back or does not get it as a whole at all
[06:48:58] <karlp> Bushman: are you sure you're waiting for it all to be sent?
[06:49:14] <karlp> there's no guarantee that it will all arrive in one constant stream.
[06:49:27] <karlp> reading until there's no bytes left and calling it done will NOT work.
[06:49:42] <karlp> it could be in dozens of separate tcp packets if it wants.
[06:50:15] <RikusW> and out of order too ?
[07:01:55] <karlp> I don't even know what tcp code he's using, he just talks about, "the code on the internet for this module"
[07:08:22] <Bushman> hmm...
[07:08:38] <Bushman> that makes sense
[07:09:06] <Bushman> if it's in more than one packet and the TCP stack does not work like it should...
[07:10:47] <Bushman> here's the title part of C file, the authors are there http://pastebin.com/v0MTnNic
[07:12:20] <Bushman> but i think i'll just start over with some other lib and some other example whith "POST" already implemented
[07:13:06] <karlp> I seriously recommend not getting involved in anything that involves http on a device with less than say, 32k ram.
[07:16:26] <Bushman> karlp: i use 644 atm
[07:17:31] <Bushman> it has 64kb i believe?
[07:22:46] <RikusW> no
[07:23:00] <RikusW> 64k flash not ram
[07:25:40] <Bushman> ugh >_<'
[07:25:48] <Bushman> silly me :P
[07:26:35] <Bushman> anyway... other people are doing it succefully
[07:27:23] <Bushman> i've just downloaded the lib from http://tuxgraphics.org/common/src2/article09051/ in latest version. maybe i'll find some examples for 644 where i could go from there
[07:40:34] <RikusW> how about UIP ?
[08:51:32] <Bushman> what did he mean by UIP?
[08:52:26] <Bushman> also... i was able to succefully compile the examples. now i would need someone to help me implement POST into those examples
[08:53:06] <Bushman> to be more precise: to the main.c in http://tuxgraphics.org/common/src2/article09051/eth_tcp_client_server-4.5.tar.gz
[08:53:58] <Bushman> i was trying to do it based on my previous bugy code but i was unsuccesfull
[09:01:32] <Steffanx> uIP Bushman
[09:07:17] <Bushman> µIP?
[09:08:27] <Bushman> still don't understand the question...
[09:08:32] <Bushman> how bout what about it?
[09:08:42] <Bushman> how bout i use it?
[09:09:33] <Bushman> i'm not sure if my current knowledge would alow me to implement it on to of my eth chip ENC28J60
[09:15:26] <rue_house> funny how gcc avoids using the processors registers so much
[09:17:26] <amee2k> hmm it does?
[09:17:55] <amee2k> my money would be on x86 not having many and it being written with that arch in mind?
[09:18:14] <rue_house> x86 has lots of registers
[09:18:48] <amee2k> maybe since x64 but from what i know before that it only had like 5 real general purpose registers
[09:19:36] <rue_house> http://i.cmpnet.com/embedded/gifs/2004/0404/0404sbfig1.gif
[09:19:42] <rue_house> each register splits,
[09:19:44] <amee2k> never did much protected mode assembler though... only enough until i could use a compiler again >_>
[09:20:08] <rue_house> for 8 bit stuff (all that I'm doin here) you have AL AH BL BH CL CH DL DH
[09:20:25] <rue_house> motorola has A, if your lucky, you get a B
[09:20:39] <amee2k> rue_house: err, it has lots of register *names* but i don't count the overlapping ones as actual registers since using one means you lose at least one other
[09:20:51] <rue_house> no you dont
[09:21:00] <rue_house> you can work AH and AL seperatly
[09:21:04] <amee2k> yes i do
[09:21:10] <rue_house> it goes by instruction
[09:21:41] <amee2k> if i use, say EAX for some variable i can't use AX for another one without scrambling my first value
[09:21:48] <rue_house> correct
[09:22:21] <rue_house> bu I'm only doing 8 bit, (which I am)
[09:22:35] <amee2k> so with the exception of a few special cases where you can use that to optimize away a shift and AND to mask out the relevant part, i've lost the other registers
[09:22:41] <rue_house> I dont need a 128 bit computer to test if c is != ';'
[09:22:41] <amee2k> hmm okay
[09:22:54] <amee2k> intel says you do *nod*
[09:22:58] * amee2k runs and hides behind the sofa
[09:23:39] <rue_house> my pint, is that I'm not really impressed with how gcc is handling my C code on x86
[09:24:05] <amee2k> when i was hot into x86 assembly i wasn't impressed with x86 >_>
[09:24:48] <rue_house> I thought it was fine, the mmx instructions are just stupid tho
[09:24:50] <amee2k> i just used it because i had it available
[09:25:20] <rue_house> I helped the world persue the fastest pupixel and drawline routines in the world
[09:26:23] <amee2k> i was writing a small RPN style calculator in real mode that i could have ported to an embedded x86 system. never finished it because in the middle i realized if i ever did that as a project i'd be switching to an AVR or ARM based platform anyway
[09:27:31] * rue_house slaps amee2k 'RPN IS STUPID'
[09:28:31] <rue_house> nobody says 4 5 8 + / = I MEAN REALLY!!!
[09:29:22] <tomatto_> hello
[09:29:30] <Steffanx> hi
[09:32:11] <amee2k> lol
[09:32:55] <amee2k> it was part of my os deving phase, really. i got as far as a boot loader plus protected mode kernel with keyboard and text mode video drivers and a debugging shell that used them
[09:32:59] <tomatto_> please, do someone use sensor for light intensivity?
[09:34:42] <amee2k> then i figured this would be a neat exercise but not go anywhere in the long run and changed the focus to that embedded calculator app. i'd like to think that i made some pretty neat use of the funny segmented memory model though
[09:36:33] <amee2k> to manage the stack... i made every stack entry err 16 bytes big or what the granularity of the segment registers was again so i could rotate the stack by changing the segment register and copying one entry only
[09:37:20] <amee2k> with a wrap-around (with full copy) after rotating through half the stack in either direction, which was neat since i didn't need to handle copy with overlapping buffers
[09:38:18] <amee2k> tomatto_: not with an AVR but a photodiode + opamp should work with an ADC channel
[09:38:48] <amee2k> can't find it right now, but there was an appnote that compared several common photodiode citcuits quite nicely
[09:39:23] <tomatto_> amee2k: have you got some materials, schematic or something for it please?
[09:41:51] * amee2k . o O ( maybe someone can chime in with the link to that appnote plz :) )
[09:42:48] <Bushman> someone sugested that TCP packets might be shorter than the http heared...
[09:42:55] <Bushman> i don't think that's the case
[09:43:02] <Bushman> see for yourself:
[09:43:07] <Bushman> http://nycz.bytom.pl:88
[09:43:28] <amee2k> http://physlab.lums.edu.pk/images/1/10/Photodiode_circuit.pdf << not the one i had in mind, but check out the circuit on page 3, figure 6
[09:44:05] <Bushman> if the post succed it still dind't print out the whole buffer even tho it FOUND the string it was looking for
[09:44:37] <Bushman> the string is on the very end of the http header
[09:46:06] <amee2k> rue_house: well, it looks pretty horrible but i find it rather intuitive to enter into a calculator
[09:46:16] <karlp> buffer overflow?
[09:46:42] <amee2k> at least if it isn't the kind of calculator that shows you the entered line on a small dot matrix display
[09:47:13] <amee2k> i used to have an RPN calc app for my PDA back in school
[09:48:54] <Bushman> karlp: nowai
[09:49:14] <Bushman> both buffers have the same size
[09:49:36] <amee2k> out of memory?
[09:49:37] <amee2k> >_>
[09:49:42] <Bushman> hmm...
[09:49:51] <Bushman> woun't that crash the whole program?
[09:50:03] <amee2k> not neccessarily
[09:50:29] <amee2k> sometimes it just results on stuffs ending up on each other and the program doing weird things
[09:51:19] <Bushman> hmm... fact, it odes weird things... but why does it do weird things in such inconsistent way
[09:51:32] <Bushman> depending on the browser asking
[09:51:33] <Bushman> :D
[09:51:41] <Bushman> lol, i
[09:51:49] <Bushman> 'm so confised right now
[09:52:23] <amee2k> because things like your stack growing all over your heap would be rather undefined behaviour >_>
[09:52:55] <Bushman> XD
[09:53:03] * Bushman takes notes: coding is hard
[09:55:00] <amee2k> when assessing memory requirements make sure you account for instantaneous usage, not idle or average
[09:56:30] <Bushman> hmm... what if the buffers are defined static?
[09:56:35] <Bushman> does that help?
[09:57:39] <amee2k> somewhat
[09:57:51] <amee2k> but you still need to leave enough room to fit your worst case stack
[09:58:03] <amee2k> including spontaneous growth by possible interrupts
[10:00:57] <Bushman> hmm...
[10:12:01] <OndraSter> eya
[10:12:03] <OndraSter> Eagle has gone nuts
[10:12:15] <OndraSter> he connected 3V3 to Vcc (yet there is no connection in the schematics)
[10:12:20] <OndraSter> he hasn't connected 7 out of 8 pins on one IC...
[10:12:25] <OndraSter> (in the board layout)
[10:13:22] <Steffanx> You did that
[10:13:29] <OndraSter> I did not
[10:13:32] <OndraSter> when I click on name vcc net
[10:13:36] <OndraSter> the 3V3 doesn't light up
[10:14:05] <Steffanx> "he connected 3V3 to Vcc" as in .. you used the auto-router?
[10:15:31] <OndraSter> no
[10:15:43] <OndraSter> the "unconnected" lines
[10:16:02] <OndraSter> hmm
[10:16:07] <OndraSter> restarting eagle fixed it partially
[10:16:10] <OndraSter> now it points to the right pin
[10:16:15] <OndraSter> but all the 7 remainings pin are not connected
[10:16:57] <OndraSter> http://clip2net.com/s/1v7ws
[10:22:19] <Steffanx> OndraSter .. i know what the problem is
[10:22:32] <Steffanx> The pins in the schematic aren't connected
[10:22:35] <Steffanx> Move the part and you'll see
[10:23:27] <Steffanx> http://www.naffets.nl/share/a-20120119-171405.png .. that dark-ish line shouldn't be there
[10:30:45] <OndraSter> uh
[10:30:48] <OndraSter> how could I miss that
[10:30:48] <OndraSter> thanks
[10:31:04] <OndraSter> hmm I know why
[10:31:15] <OndraSter> I changed the grid size
[12:03:53] <spow> Hey. Is this correct ? static int counter=0; ISR(INT0_vect) counter++; and sei(); in main loop ? I managed this in assembly but for some reason it doesn't work in C (prob a stupid mistake from me though)
[12:21:11] <magnus_> spow, did you also enable the INT0 interrupt?
[12:21:20] <magnus_> sei() will only enable the global interrupt flag
[12:21:34] <spow> magnus_: aaaah, thanks ! will try this in a min
[12:21:39] <spow> was driving me nuts
[12:23:07] <magnus_> though, you would have to do the same initialization in assembly..
[12:25:08] <spow> did it a while back so I don't remember well, and I did so little assembly (my first prog actually) that it's hard to re-read
[12:30:31] <Bushman> i've gone back to GET method. Looks like it does in fact runs out of some memory or buffer somewhere but i'm to small of a coder to really try to find it. here's the LED swithc http://nycz.bytom.pl:88/asd/
[12:32:52] <Bushman> i would probably had to set up a webcam so you could see it'a actually switching :P
[12:33:07] <Bushman> but i believe that your imagination will sufice
[12:33:10] <Bushman> :P
[12:33:41] <Bushman> *blink* *blink* *blink*
[12:33:43] <Bushman> :P
[12:34:23] <Bushman> *blink* *blink* *blink* some more
[12:37:45] <Bushman> hehe, so many bored people on the internet XD
[12:38:04] <Bushman> i really need to implement some counter
[12:38:43] <spow> who keeps switching it on ?
[12:38:55] <Bushman> anyone can give me a tip for a int to decima string converter?
[12:39:13] <Steffanx> itoa ?
[12:39:13] <Bushman> spow: i don't know and i don't care :P
[12:39:28] <Bushman> i just know it bliks :P
[12:39:33] <Bushman> *blinks
[12:39:58] <RikusW> printf ?
[12:40:15] <Bushman> it would be to much trouble to log all the IPs and decode who's who on the net
[12:40:47] <Bushman> RikusW: no, that won't work, the stdout is not connected
[12:40:53] <Steffanx> sprintf
[12:40:56] <Steffanx> but use itoa :P
[12:40:59] <Bushman> also i want to put it on the page
[12:47:41] * amee2k . o O ( why do my designs always need weird component values like 470mR or random shit like that... )
[12:47:56] <Steffanx> Why not?
[12:48:54] <amee2k> because they're weird values that i don't have in my junk box?
[12:48:56] <amee2k> >_>
[12:50:09] <amee2k> the only passives this auxiliary supply needs are 3.3kR, 1kR, 150R, and 100nF
[12:50:35] <Sgt_Lemming> https://picasaweb.google.com/115277388924201849210/PCBS?authkey=Gv1sRgCK73t-Cw3pmLmwE#5699414678428520482
[12:50:43] <amee2k> and one each of 47/2.7k/2.2k/470m resistors and a 1.5nF cap >_<
[12:52:10] <amee2k> Sgt_Lemming: what is that?
[12:52:40] <Sgt_Lemming> amee2k, RFID powertool lockout controller
[12:53:01] <amee2k> o.O
[12:53:06] <amee2k> sounds kinky
[12:53:35] <Sgt_Lemming> ethernet enabled as well
[12:53:59] <Sgt_Lemming> it's designed to tie in with our RFID entry system for the hackerspace
[12:54:16] <amee2k> uh lol
[12:54:21] <amee2k> like rfid controlled power outlet?
[12:54:40] <Sgt_Lemming> kind of
[12:55:07] <Sgt_Lemming> but it's designed to be installed on the power cable, fixed in place.
[12:55:21] <Sgt_Lemming> so people can't just unplug it and plug into the power point
[12:56:28] <amee2k> i don't think having to cut off the cord and fit a new plug would prevent many people from stealing the tools
[12:56:48] <amee2k> chances are someone who would steal a tool also has the skills to remove the protection device
[12:57:03] <mrfrenzy> well not really
[12:57:07] <amee2k> or just open the box and solder a wire jumper over the relay >_>
[12:57:09] <mrfrenzy> but their dealer might
[12:57:12] <mrfrenzy> then they will get paid less
[12:57:40] <amee2k> lol
[12:57:55] <Sgt_Lemming> amee2k, this is to prevent people who haven't been inducted from using tools in a hackerspace
[12:58:07] <mrfrenzy> and if their dealer is a regular crackhead they will just refuse such loot
[12:58:12] <amee2k> eww
[12:58:34] <amee2k> big momma < big brother < * >_<
[12:58:55] <amee2k> mrfrenzy: then there always is ebay
[12:59:03] <amee2k> or crooklist
[13:02:52] <Bushman> what's the include name for sprintf?
[13:07:43] <RikusW> stdio.h
[13:07:50] <RikusW> man sprintf....
[13:08:14] <Sgt_Lemming> amee2k, it's largely to cover our asses for insurance purposes
[13:08:22] <Bushman> then why does he tell me i have inplicit declaration ;/
[13:08:36] <Bushman> i have stdio included
[13:09:06] <Sgt_Lemming> also means people have to ask to be shown how to use the tools, rather than just use em and potentially break things and/or themselves
[13:09:12] <Bushman> lol
[13:09:20] <Bushman> it wasn't included
[13:09:26] <Bushman> i mean WTF? :P
[13:11:05] <Sgt_Lemming> oh, and I did look for a different micro to use on that board
[13:11:12] <amee2k> Sgt_Lemming: hmm i see :/
[13:11:37] <amee2k> you should ask the insurance how much discount they'll give in exchange for your adding the RFID lock-out
[13:11:42] <Sgt_Lemming> but the only other ones were 22 pin anyway
[13:12:07] <amee2k> i'd just have used a keylock switch and one of these power outlets with a lockable cover
[13:12:11] <Sgt_Lemming> amee2k, none, because we already have the induction policy in place, this is just a way of enforcing
[13:12:26] <Sgt_Lemming> amee2k, we already use RFID cards for entry into the space
[13:12:33] <Sgt_Lemming> all members have 24/7 entry
[13:12:44] <keenerd> What about non-ferrous people? Does induction still work for them?
[13:12:56] <amee2k> if it is just for insurance i'd use the most straightforward solution that doesn't get into people's way
[13:13:25] <Sgt_Lemming> amee2k, people in the space are already going to have their RFID card on them, there will be a reader module at each machine
[13:13:36] <Sgt_Lemming> walk up to use machine, put card on reader, start using
[13:13:42] <Sgt_Lemming> not exactly a hard process
[13:14:40] <karlp> also, someone got to play with rfid, which was probably half the reason :)
[13:15:35] <Sgt_Lemming> karlp, we already have an established RFID system
[13:16:20] <Sgt_Lemming> basically the same system, but it runs off an arduino mega so it can run 2 RFID readers + USB interface simultaneously
[13:16:31] <Sgt_Lemming> also has two doors hanging off it
[13:16:41] <spow> hum ... can I disable interrupts while in an interrupt ?
[13:17:43] <Sgt_Lemming> https://picasaweb.google.com/115277388924201849210/PCBS?authkey=Gv1sRgCK73t-Cw3pmLmwE#5696350186092590866 <--- the pcb for the droo controller, runs as an arduino mega shielf
[13:17:46] <Sgt_Lemming> shield*
[13:18:01] <amee2k> hmm
[13:18:19] <amee2k> is there any significant deployment of wishbone as a bus standard?
[13:18:33] <Sgt_Lemming> never even heard of it
[13:18:45] <amee2k> neither did i until like 5 minutes ago
[13:19:20] <RikusW> spow: yes
[13:19:34] <spow> ty
[13:20:02] <RikusW> spow: like the interrupt itself or the sreg bit ?
[13:20:16] <RikusW> iirc reti sets the I bit again
[13:20:37] <RikusW> but you can disable the specific irq bit
[13:20:42] <spow> I'm using sei/cli here
[13:21:26] <RikusW> isn't it disabled while in an interrupt ?
[13:21:44] <RikusW> check the ds, but I think it is
[13:22:21] <spow> will try it see what happens
[13:43:52] <Bushman> can anyone give me a really quick interactive tutorial on PM about how to use sprintf [C[C?
[13:44:21] <Bushman> cause i'm by no means a coder so i've got a littel bit lost here
[13:44:34] <Bushman> *little
[13:54:29] <Bushman> i have no idea how to use this sprintf ;/
[13:54:33] <Bushman> http://pastebin.com/GXSfRqmS
[13:54:54] <Bushman> here. have a laugh at me but after that, please help me
[14:02:22] <Steffanx> Why not go for itoa .. avr-libc has that
[14:02:58] <Steffanx> Your buffer is too small Bushman
[14:03:27] <Steffanx> And there is no need to use fill_tcp_data_p .. as the buffer isn't in progmem
[14:13:09] <Bushman> erm... huh?
[14:14:02] <Bushman> if not fill_tcp_data_p then what should i use?
[14:14:37] <Bushman> Steffanx: btw, the buffer size is increased to 25 now
[14:14:48] <Bushman> i also comented out the sprintf
[14:14:52] <Bushman> http://pastebin.com/jN9bNTjP
[14:15:02] <Bushman> that does not work either
[14:15:23] <Bushman> so it's not the sprintf what's not working here :(
[14:15:27] <Steffanx> counter[25]="1234567890123456789012345"; <= .. no space for the \0 ?
[14:18:25] <Steffanx> And i think you shouldn't use fill_tcp_data_p .. can you remove that p?
[14:18:29] <Steffanx> *_p
[14:18:57] <Steffanx> and use char counter[]="1234567890123456789012345"; to test it
[14:19:47] <Bushman> hmm...
[14:20:28] <Bushman> hmm...
[14:20:31] <Bushman> it works
[14:21:43] <Bushman> thanks Steffanx, looks like you solved it ;]
[14:28:22] <Bushman> fixed :D
[14:28:23] <Bushman> http://nycz.bytom.pl:88/asd/
[14:33:55] <Steffanx> Sorry i had to press f5 for a while
[14:34:42] <Steffanx> At least you can press reset
[14:35:00] <Bushman> heh, i was wondering whowas that
[14:35:01] <Bushman> XD
[14:35:08] <Bushman> also, i can't
[14:35:17] <Bushman> i was so cheap i didn't solder one in
[14:35:19] <Bushman> :D
[14:46:58] <powderhound> Anyone feel like speculating why moving a variable declaration from a .h file (which I know is a bad idea) to a .c file would compile, but just not work?
[14:47:43] <Bushman> hmm...
[14:47:54] <Bushman> maybe the .h is included somewhere else?
[14:48:11] <Bushman> no, that would yeald undefinded
[14:48:28] <Bushman> hmm...
[14:48:30] <powderhound> It is definitely included in multiple places
[14:48:40] <powderhound> Which is why I was trying to move the variable to the .c file
[14:50:06] <Bushman> maybe you somehow automagically managed to convince the complier tha the variable(s) are not seen from one file to the other but in fact they somehow compile they end up being the same?
[14:50:10] <Bushman> just guessing
[14:50:11] <Bushman> :P
[14:50:37] <powderhound> Hm... yeah, I'm pretty lost on this one.
[14:51:29] <Bushman> why don't you just use another variable?
[14:51:40] <Bushman> just change the name
[14:51:58] <powderhound> Somehow, I hadn't thought about that haha
[14:53:29] <powderhound> Hmm, yeah, no change there
[14:53:52] <powderhound> It doesn't appear to be linked to the name
[14:54:10] <powderhound> The actual variable is an array of structs
[14:55:14] <Bushman> why do you need to take it out of .h?
[14:55:26] <Bushman> or what are you actually trying to do?
[14:55:55] <powderhound> So I thought I had tracked down another bug to being caused by that particular variable, now I'm not sure
[14:56:18] <powderhound> Basically, if I declare another global variable (outside a function) in another .c file, the program completely stops working (it still compiles)
[14:56:47] <powderhound> I can't figure out what's going on, but the behavior is exactly the same when I declare an additional variable as when I move this one to the .c file
[14:57:12] <powderhound> I was thinking it was something along the lines of a heap/stack collision, but I have no experience with that
[14:57:58] <powderhound> Granted, this is being run on the new Xmega32A4U, so it could easily be a hardware problem in the USB module as well
[15:04:12] <Bushman> so if you define new variable in this .c file it stops working even if you don't use it?
[15:05:06] <powderhound> yeah
[15:05:51] <powderhound> So at the top of this .c file, I define three variables. If I add a fourth, it doesn't work. If I then add a fifth, it works (they're all one byte)
[15:06:56] <Bushman> lol
[15:07:07] <powderhound> I'm so confused now, I have no idea what's going on hahaha
[15:07:17] <Bushman> you mean you add ON TOP OF THAT another one and it starts working again?
[15:08:03] <powderhound> Actually, if I declare another one on top of the fourth, it works, but not if I initialize it to a value
[15:08:51] <powderhound> I'm using AVR Studio 5, with everything updated I believe... maybe there are ghosts :)
[15:08:55] <Bushman> dude :D i'm sorry for you but it looks like your GCC is cheating on you with /dev/random
[15:08:57] <Bushman> :D
[15:09:24] <powderhound> Haha sounds like it to me
[15:10:21] <RikusW> use extern int i;
[15:10:33] <powderhound> in the header or .c file?
[15:10:36] <RikusW> in the header
[15:10:45] <RikusW> and int i; in ONE c file
[15:11:04] <powderhound> Still nope
[15:13:04] <powderhound> I'm going to go bang my head on my keyboard for a bit, I'll be back in a few minutes.
[15:15:05] <Steffanx> Have fun
[15:31:21] <Bushman> no more LED for today :(
[15:31:26] <Bushman> power off
[15:59:52] <OndraSter> hehe LED
[16:00:08] <OndraSter> I was drawing the power part of the board
[16:00:09] <OndraSter> well
[16:00:10] <OndraSter> designing
[16:00:19] <OndraSter> I will be calling it the "analog part" of the board lol
[16:00:27] <OndraSter> or more like "switched part of the board"
[16:00:30] <OndraSter> SMPSed!
[16:13:41] <Bushman> i split boards
[16:13:58] <Bushman> digital goes this way, analogue this way and power that way
[16:15:27] <dofidum> can i leave aref/avcc disconnected if i am not planning on using adc?
[16:19:06] <amee2k> i usually connect avcc to regular vcc and leave aref floating in that case
[16:20:20] <amee2k> i vaguely recall reading somewhere that vcc and avcc must be within a diode drop of each other, which suggests some kind of protection structure
[16:21:05] <amee2k> so my money is on chances are you can get away with avcc floating because the protection diode will provide enough bias current, but i wouldn't bet the money for a board run on it
[16:21:14] <keenerd> Though once I grounded avcc by accident, and everything was mostly okay.
[16:22:33] <amee2k> hmm interresting
[16:22:34] <dofidum> amee2k, thanks
[16:23:18] <amee2k> you're welcome :)
[16:26:53] <amee2k> if you don't use the adc anyway, you don't care about noise on avcc either, so you can run the trace for it all across the board and back if you have to
[16:39:41] <jadew> I'm experiencing a very strange issue, maybe someone has an idea: LPT => AVR => USB, main loop here: http://pastebin.com/Rps7BhSX
[16:40:43] <jadew> the block between line 48 and 62, works perfectly fine, that's the part that handles the data transfer from LPT to AVR
[16:40:55] <Casper> maybe if you would say what the issue is and what you expect
[16:41:02] <Casper> that it would help
[16:41:05] <Casper> and what part you use
[16:41:06] <jadew> let me finish
[16:41:44] <jadew> after a packet has been sent I trigger a signal USB => AVR and only the first part of the if / else statement gets run while the signal is processed
[16:42:13] <jadew> on the LPT PC, if I don't fire STROBE (line 27), the process doesn't advance (desired behaviour)
[16:42:29] <jadew> everything works fine while I have it on the target board
[16:42:51] <jadew> but when I put it on its own pcb (with a new LPT connector) only the transfer works
[16:43:47] <jadew> and when I trigger the signal, it goes trough the entire switch / case like STROBE is both set and unset (even tho I don't set it from the LPT pc, just so I can see it getting stuck at line 27 - which doesn't happen)
[16:44:25] <jadew> that's the problem
[16:44:43] <jadew> which is very weird, since I'm relying on STROBE in the transfer part and that works fine
[16:45:38] <jadew> seems like a hardware issue, so any ideas on what I might be doing right on target board?
[19:27:09] <jimi_hendrix> i have a somewhat silly question about how transferring code to an avr works: when i send code from my computer to the avr, the RESET pin goes low, and then my computer just sends the binary to one of the pins?
[19:27:33] <inflex> yes - but it does need the other pins as well
[19:27:33] <jimi_hendrix> or is there something else involved in there
[19:27:40] <jimi_hendrix> inflex, right ok
[19:27:56] <inflex> MOSI and MISO are both used during the programming, as is SCK
[19:29:21] <jimi_hendrix> inflex, is there a nice article that explains all that, or do i need to dig through the manual
[19:30:08] <inflex> The datasheet does have the details in it for things like the ATTiny and ATMega chips
[19:30:20] <jimi_hendrix> inflex, alright, thanks
[19:36:18] <rue_house> jimmy! we all thoguht you were dead!
[19:38:33] <inflex> There, see...there was no reason to fret ;)
[20:28:40] <Sgt_Lemming> off out, later all
[20:32:12] <zzing> When digikey says a program files size is "192KB (96K x 16)" what precisely are they describing here? My best guess is 192kilobytes of actual flash, but 96k segments of 16 bit access. Would that be about right?
[20:52:06] <WormFood> zzing, yeah, you're right...96k words, or 192k bytes
[21:00:40] <zzing> Are there any 8/16 bit avr chips that can take external ram?
[21:01:47] <Tom_itx> for storage?
[21:03:21] <zzing> For program execution
[21:03:36] <Tom_itx> no
[21:05:06] <zzing> A crazy idea, some people make replicas of something like the TRS80, well, I want to entertain the idea of making a smallish computer of the same vein but can do different sizes of ram (at least 64k, preferably more). I am doing some research with C++11 and some things are interesting on 8bit small micros, but a larger beast would not be a bad thing to look at too.
[21:05:40] <keenerd> You could use external ram for programs if you took the performance hit of something like interpreted forth.
[21:05:54] <zzing> The only 'condition' is basically binutils/gcc support for the platform, which avr does. I suppose avr32 is possible, but it is a bit bigger.
[21:06:27] <zzing> keenerd: Have to do something with c++. It is my area of research.
[21:06:53] <keenerd> You can write forth in any language ;-)
[21:07:27] <zzing> haha
[21:41:24] <WormFood> forth has a bizarre notion of how to store files (your source code)...I could never get over that, but I did check out forth back in the 1980s
[21:57:48] <keenerd> It has come a long way. I can't wait to get hacking on my 144 core Green Arrays chip :-)
[21:59:19] <zzing> keenerd: I think it is an odd curiosity, not much more :P
[21:59:27] <WormFood> I remember that it uses RPN, which I always thought was kinda weird
[21:59:46] <zzing> Tom_itx: It appears the ATmega128 has support for external ram as evidenced by this board: http://www.bdmicro.com/mavric-ib/
[22:00:03] <WormFood> I remember there were some cool programs written in forth, for my computer system way back in the 1980s...but few (I can't remember what they are now)
[22:00:16] <WormFood> yes, it does support external ram
[22:00:20] <WormFood> didn't you read the datasheet?
[22:00:26] <Tom_itx> zzing yeah i know but it's not for code execution
[22:00:42] <Tom_itx> at least gcc doesn't support it
[22:00:45] <WormFood> you can't run atmel code from ram
[22:00:53] <zzing> oh my mistake then :-(
[22:00:59] <WormFood> I mean, the avr won't run code from ram
[22:01:06] <WormFood> I've already looked into that
[22:01:23] <WormFood> the best thing you can do, is program it into flash, on the fly, and execute it from flash.
[22:01:37] <WormFood> really, really shitty way to handle it....but, it should work
[22:02:31] <zzing> If I wanted to program something like 'dos' for an exercise on a small machine with decent ram (64k) are there any inexpensive boards (<$100) that would work and programmable / communicatable via usb? (think like how the arduino programs and recieves output back over the usb)
[22:03:02] <zzing> I have considered the beagle board, which would fit the price and have lots of ram, but it might be on the 'huge' side of hardware and that might be more difficult.
[22:03:19] <WormFood> I wrote a telnet client, and a crude CLI....you can include commands in rom, but not able to load from ram and run
[22:03:30] <Essobi> neat
[22:03:57] <WormFood> sadly, my telnet client and cli are locked up on a computer I haven't set eyes on in over 4 years, AND is on the other side of the world from me :(
[22:03:59] <zzing> WormFood: That is something like what I want to do, but I don't want to compromise the future capabilities too much by using an atmel chip that is not suitable to it.
[22:04:24] <Essobi> zzing: that's why they call it R&D. :D
[22:04:48] <zzing> I
[22:05:07] <zzing> Has anyone ever made an AVR32 'arduino' kind of thing that might work?
[22:06:39] <Essobi> I have no idea wtf you're doing so... *shrug*
[22:07:06] <zzing> Essobi: Are you familiar with the projects that recreate old style machines like the TRS80, C64, etc?
[22:07:33] <zzing> I want to have something in that class, but programmable via USB, and can expand ram (or have decent ram already)
[22:07:34] <Essobi> Ah, I've seen'm.
[22:07:38] <WormFood> zzing, you can use anything 68xx/68xxx based for your project (I'm personally fond of those systems, since I have dealt with them a lot in the past)
[22:07:51] <zzing> Also, it must be a gcc target too.
[22:08:05] <Essobi> WormFood: FPGA? :D
[22:08:07] <WormFood> Someone has a trs80 coco (color computer) emulator for the gameboy, which is ARM based
[22:08:23] <zzing> This would be nice: http://www.coridiumcorp.com/ARMduino.php But the ram is too small
[22:08:40] <WormFood> no, not fpga...old computers....I used to program smart cards a lot, which were 6805 based (and later, st7/st19)
[22:08:51] <zzing> This one does even better ram: http://www.coridiumcorp.com/SuperPRO.php but even still too small
[22:08:55] <Essobi> I was teasing. I know.
[22:09:21] <WormFood> and I have a 68000 system that I built from a kit (bare circuit board)...I wrote a desktop animator .fli (flicker) video viewer for it, in 1/2 C and 1/2 68000 assembly language
[22:09:30] <Essobi> Nice man.
[22:09:46] <Essobi> I've been reading up on OpenCL this week. :D
[22:10:00] <WormFood> I go to the computer shows, and the booth where they're selling the computer I have...and every single one of their computers is running my video viewer :D
[22:10:59] <zzing> My main area of research is application of C++ to lower end machines using tricks like template metaprogramming to do compile time algorithm generation.
[22:11:52] <Essobi> WormFood: :D that's awesome.
[22:12:53] <WormFood> my interest in old machines is very narrow. I had the tandy color computer (aka coco), back in the 1980s. That uses the very powerful motorola 6809 CPU....and I'm still somewhat involved with that group (I had some slick hacks for it way back when)...if you want, you can join the #coco_chat channel here, on freenode, and chat with them, they are some really smart guys, doing some really cool stuff with these "ancient" computers.
[22:12:57] <Essobi> zzing: similar to the JIT in openCL ya?
[22:13:03] <Essobi> ]/13
[22:13:25] <zzing> JIT in opencl?
[22:13:46] <zzing> OpenCL doesn't use JIT afaik, it uses compiled shaders
[22:14:27] <Essobi> well, online or offline compiling.. but you can have it build the source-code for the kernel and upload it all during execution time
[22:15:08] <Essobi> So the host program could potentially alter the source of the kernel before handing it to the GPU
[22:16:00] <zzing> Essobi: Ever made a program that needed a look up table that could be generated by an algorithm?
[22:16:41] <Essobi> Fair enough.
[22:17:00] <zzing> I remember back in gw-basic making a sin() look up table :P
[22:17:30] <Essobi> Heh.
[22:17:54] <Essobi> I program mostly for fun now, not for work.
[22:18:33] <WormFood> most lookup tables are generated by an algorithm
[22:18:48] <WormFood> the reason you use a lookup table is for speed
[22:19:00] <Essobi> Cache
[22:19:23] <WormFood> and I wrote programs that could have used an algorithm, but chose a lookup table, because of it's incredible speed
[22:19:37] <WormFood> and I had gobs of space to spare, even on the smallest AVR
[22:20:07] <Essobi> Ya?
[22:22:06] <zzing> WormFood: The idea is that the compiler can execute the algorithm for you instead of you either generating it at runtime or manually having to enter it in.
[22:23:11] <WormFood> huh? compilers don't compile anymore? They execute now?
[22:23:45] <WormFood> execute = generate?
[22:24:33] <WormFood> lunch time
[22:25:47] <zzing> WormFood: The joys of template metaprogramming
[22:26:18] <zzing> Now this looks nice: http://leaflabs.com/docs/hardware/maple-native-beta.html
[22:30:42] <zzing> What does XTAL mean when applied to a frequency?
[22:30:47] <Essobi> WormFood: yup, that's pretty much what it does.
[22:31:35] <Essobi> There's a few commercial GPU compilers that will convert algs to parallel for gpus/fpus/cells/apus
[22:32:24] <zzing> Essobi: Autovectorization is something gcc has been doing, and it is possible to have that be done for the gpu
[22:32:35] <Essobi> I guess that's the next obvious evolution for compilers. Fix shit their programmers don't understand without telling them.
[22:32:38] <zzing> fpu generally isn't parallel (that I have seen)
[22:32:52] <Essobi> zzing: yea, that's part of it.. autovzing
[22:33:54] <zzing> Sweet: http://embeddedartists.com/products/displays
[22:39:48] <WormFood> zzing, xtal = crystal
[22:40:06] <zzing> ok, I knew I recognized the name, just wasn't sure...
[22:40:28] <WormFood> I don't remember if I learned why it is called "xtal"
[22:41:43] <WormFood> near where I lived in Florida, there is a place called "crystal river", and when they had a hamfest there, and they drew a map, they labeled it as "xtal river"...of course, because hams are geeks, everyone going understood it.
[22:42:47] <zzing> Could be the cut
[22:45:24] <zzing> I wish jtag debuggers were cheaper
[22:47:20] <WormFood> everyone not selling them, wishes that too
[22:50:19] <WormFood> http://en.wikipedia.org/wiki/Crystal_oscillator this is cool. I never knew the crystals used in watches were cut in a shape like a tuning fork, but the shape of the xtal case makes sense.
[22:51:57] <zzing> http://www.stackfoundry.com/hardware/copper-avr32/
[22:52:00] <zzing> This thing looks nice
[22:52:06] <zzing> I wonder if there are any others like this
[22:52:19] <zzing> I think the avr32 can use external ram for execution
[22:52:49] <WormFood> perhaps, but I know the traditional AVRs have not been able to in the past (of course, things can change)
[22:53:07] <WormFood> I haven't checked the datasheets on the avr32, but that is what I strongly suggest you do, if you really want to know if it can or not.
[22:54:12] <zzing> I am looking up some data now
[22:54:21] <zzing> The web isn't too fast for me tonight
[22:54:49] <WormFood> you should be lucky you don't have Chinese Internet...talk about slow
[22:57:38] <Essobi> I bet
[22:57:56] <Essobi> I knew a guy in malaysia, and he said it wasn't great either.
[22:58:30] <WormFood> On electrical schematic diagrams, crystals are designated with the class letter Y (Y1, Y2, etc.) Oscillators, whether they are crystal oscillators or other, are designated with the class letter G (G1, G2, etc.) (See IEEE Std 315-1975, or ANSI Y32.2-1975.) On occasion, one may see a crystal designated on a schematic with X or XTAL, or a crystal oscillator with XO, but these forms are deprecated.
[22:59:17] <WormFood> I didn't know that. I learned electronics back in the 1980s. I stopped working on electronics professionally in the mid 1990s....guess a lot of things changed since then
[23:02:04] <zzing> WormFood: Understate ment of the decade :P
[23:02:48] <WormFood> the electronics are still 95% the same as it was back then...they're just combining them in different combinations and patterns than they were in the past.
[23:50:41] <Roklobsta> zzing: avr dragon is $49 that's cheap
[23:53:04] <zzing> Roklobsta: Good point
[23:53:25] <Roklobsta> zzing: mkII-cn from mcuzone in china is $80
[23:53:42] <Roklobsta> i have both and for avr they seem to be exactly the same.
[23:53:48] <Roklobsta> functioanlly
[23:54:16] <zzing> It is looking like my fortunes are favouring the beagle bone for what i want to do ultimately
[23:54:54] <Roklobsta> omap? what do you want to do with it?
[23:56:09] <Roklobsta> have a look at this arm board. http://www.cnx-software.com/2011/10/28/st-micro-15-usd-stm32f4-discovery-cortex-m-development-kit/
[23:58:07] <zzing> Roklobsta: nice board, little ram
[23:58:30] <Roklobsta> i am just looking at it now - you may be able to add your own ram
[23:58:42] <zzing> I will be looking closely :P
[23:59:37] <zzing> Roklobsta: My basic idea is to have a machine that can implement something akin to MS-DOS - so think C64 class hardware. This board would work for basic stuff sure. Which is why I would look at it.