Back
[00:31:50] <rue_portable> nobody into the 0-5V -> hobby servo or knock code detection code?
[00:32:14] <rue_portable> oooh I could get ttris for this thing
[00:32:23] <N2TOH> can the knock code be adapted to decypher hand keyed CW?
[00:50:08] <rue_portable> Prrobably by the character anyhow
[00:50:23] <N2TOH> interesting
[00:51:54] <rue_portable> I rewrote the source I got it from to be able to identify multiple characters
[00:52:41] <N2TOH> sounds like you have everything you need
[00:53:30] <rue_portable> saying I should use it for character communication?
[00:53:56] <N2TOH> or a better CW keyer
[00:54:51] <N2TOH> I have had a project on the back burner for awhile now, the plan was to convert two padle CW into USB keyboard HID
[00:55:13] <rue_portable> haha
[00:55:17] <rue_portable> love it
[00:56:04] <N2TOH> http://www.hamradio.com/detail.cfm?pid=H0-010225
[00:56:38] <DarkSector> Shit. I can't believe my board works on the first attempt
[00:56:38] <rue_portable> how far did you get?
[00:56:38] <N2TOH> http://www.cwtouchkeyer.com/P3W.htm
[00:56:44] <DarkSector> Jeez
[00:57:12] <N2TOH> I bought the paddel key, and started messing with the USB code.
[00:58:26] <rue_portable> you should be able to use the example hid keybaord in the lufa source?
[01:00:15] <rue_portable> atmega32ux boards are found everywhere these days
[01:01:18] <rue_portable> have you loked at the lufa stuff?
[01:01:40] <N2TOH> um no?
[01:01:51] <rue_portable> kmm knock sequence to usb keybaord word generator might be interesting
[01:02:11] <rue_portable> there are great examples in the lufa source, I verrymuch encourage you to take a look
[01:03:22] <N2TOH> http://www.pbs.org/wgbh/amex/honor/sfeature/sf_tap.html
[01:23:23] <N2TOH> I was initially encouraged by the fact the touch keyer uses out outputs
[01:23:37] <N2TOH> one for the DIT and another for the DAH
[01:24:20] <N2TOH> the automatic keyer does two things, one it debounces the inputs, and two it regulates the speed
[01:25:27] <N2TOH> I figured there would be a way to populate an 8 bit byte with not too much trouble
[03:32:19] <megal0maniac_afk> Hmmm. I have discovered that one should add solder before desoldering chinese stuff with a heat gun. This RoHS crap has a high melting temp
[03:32:31] <megal0maniac_afk> I may have cooked an IC
[03:33:08] <megal0maniac_afk> But if I haven't, then I now have an 8MBit SPI flash to play with :D Off a motherboard, so I suspect it contains a BIOS
[03:33:41] <lxsameer> Hi, I know that it is a dumb question but is there any solution for multithread in atmega8 ?
[03:34:43] <megal0maniac_afk> lxsameer: Well, how many cores does an atmega8 have?
[03:35:18] <megal0maniac_afk> Simulate hyperthreading, perhaps. Multithread, no.
[03:36:10] <lxsameer> megal0maniac_afk: thanks
[03:42:20] <blathijs> megal0maniac_afk: Huh? Multi-threading is essentially just running multiple tasks one by one on a single core, right? We've had multithreading long before mult-core was common
[03:44:12] <blathijs> lxsameer: Normaly OS's take care of running multiple processes or threads one by one, using timer interrupts or other mechanisms. But, at least on a single core, there's never things running at the same time, only quickly switching between tasks. On an AVR without an OS, you'll have to implement this stuff yourself, but it's usually sufficient if you make sure that each task does a small piece of work, returns and waits to be called again to the ...
[03:44:18] <blathijs> ... next small piece of work
[03:44:37] <blathijs> lxsameer: Alternatively, you can look at some OS for AVR, IIRC FreeRTOS offers stuff like this
[03:45:19] <lxsameer> blathijs: thanks buddy.
[03:45:24] <blathijs> lxsameer: there's also an Arduino library that handles multiple tasks:
http://www.kwartzlab.ca/2010/09/arduino-multi-threading-librar/
[03:45:44] <lxsameer> blathijs: great
[03:57:47] <inflex> wow, they put MP in to Arduino... must resist talking about C and ASM
[05:01:17] <inflex> What avrdude programmer type do I use for Tom_itx 's AVRISP MkII clone?
[05:01:20] <inflex> (linux)
[05:01:23] <inflex> I seem to ahve forgotten :(
[05:04:32] <inflex> ah, did' have the -P usb bit
[08:34:22] <Epsilon-Auriga_> N2TOH: you still wanting a programmer that can do fuse bits?
[08:37:46] <Epsilon-Auriga_> inflex:
[08:37:51] <Epsilon-Auriga_> The USBTiny MkII uses libusb to communicate with avrdude.
[08:37:51] <Epsilon-Auriga_> To download a program to your target device use the following line adjusting it for your target chip.
[08:37:51] <Epsilon-Auriga_> avrdude -c avrisp2 -P usb -p t26 -U flash:w:main.hex:i
[08:37:51] <Epsilon-Auriga_> where -p is the part number.. t26 is tiny26, t10 is tiny10, m644 is mega644 etc.
[08:38:22] <Epsilon-Auriga_> http://tom-itx.dyndns.org:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_User_manual_index.php
[08:56:26] <Tom_itx> inflex, avrisp2
[11:35:56] <ambro718> I'm wondering how people usually drive those standard character LCDs. Does it make sense to do it with timer interrupts to avoid blocking waits in main?
[11:37:33] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/mega128/lcdtest/
[11:37:36] <Tom_itx> that's how i do it
[11:38:54] <ambro718> so how long does lcd_waitbusy take
[11:39:28] <Epsilon-Auriga_> depends on how long it takes for your lcd to update and respond.
[11:39:46] <Epsilon-Auriga_> after all, it is waiting while the lcd is busy...
[11:40:02] <Tom_itx> i think interrupts would have priority over that anyway
[11:40:07] <ambro718> your answer doesn't answer my question at all?
[11:40:20] <ambro718> "how long does it take?" "as long as it takes"
[11:40:21] <Tom_itx> lcds are typically slow devices
[11:40:31] <Tom_itx> i wouldn't use an int for one
[11:40:43] <Epsilon-Auriga_> different LCDs take different amounts of time to update and be ready for more data.
[11:40:52] <Epsilon-Auriga_> hence the wait while it updates.
[11:41:18] <ambro718> Tom_itx: that's exactly why I *would* use an int for one
[11:41:52] <ambro718> I can't afford to lose too much cpu time in the main loop, got other things to do
[11:42:28] <ambro718> (unless you're suggesting I poll it from the main loop)
[11:42:36] <Epsilon-Auriga_> that works too.
[11:42:52] <ambro718> like, not block but keep doing my stuff and occasionally check when it's ready
[11:43:03] <Epsilon-Auriga_> yup.
[11:43:15] <Epsilon-Auriga_> or you can poll it in a timer interrupt.
[11:43:48] <Epsilon-Auriga_> but that is a waste of resources in my opinion.
[11:44:08] <ambro718> yes I think so too, and it could mess up my real time
[11:44:17] <Tom_itx> no matter how you do it, it will take X amount of time to write to an lcd
[11:44:36] <Epsilon-Auriga_> if you check the specs for your LCD and just guarantee you wait for whatever it's max update time is.
[11:44:52] <Tom_itx> some lcds don't reply to a wait busy anyway
[11:45:54] <ambro718> I think I'll start with main loop polling, thanks
[11:54:30] <tzanger> ambro718: I drive them in my main code, no interrupts
[11:54:54] <ambro718> tzanger: blocking or non-blocking polling?
[11:55:31] <tzanger> ambro718: the datasheet says how long it takes on average and at maximum, then add a good 25% for margin and if you can't wait that long then you need to implement a polling mechanism , but I've never had that issue since my lcd updates all take place in a 100ms loop that doesn't mind if it takes longer (i.e. it skips a tick)
[11:56:04] <ambro718> as in, "while (lcd busy); write();" or "main() { if(!lcd busy) { write(); } other; stuff; }"
[11:56:13] <ambro718> *add main loop
[11:56:41] <ambro718> ah I see, well, I can't affor to wait 100ms
[11:57:09] <tzanger> ambro718: then what the hell are you doing writing to an LCD in a loop that has tight requirements?
[11:57:18] <tzanger> the LCDs are slow as molasses in January to start with
[11:57:30] <tzanger> even 100ms update is pushing it
[11:57:33] <ambro718> I'm not doing that. I'm not even driving an lcd yet.
[11:57:50] <ambro718> I think I'll be doing it in a non-blocking way from the main loop
[11:58:09] <tzanger> I'd just take a snapshot of the data you want to display every half second or so and write to the LCD at that reate
[11:58:10] <ambro718> main() { while (1) { if(!lcd busy) { write_one_byte(); } other; stuff; } }
[11:58:13] <tzanger> rate
[11:58:21] <tzanger> it's not like you'll be able to really see faster updates anyway
[11:58:54] <ambro718> yes I also don't see a need for anything more complicated
[11:58:58] <antto> if (xmas) { ho(); ho(); ho(); }
[11:59:46] <ambro718> don't even need a snapshot, just an array that you write to
[12:00:16] <ambro718> i.e. there's no need that what you see on the lcd at one moment was actually a consistent state in your program at any time
[12:00:42] <ambro718> and you can just cycle through all the chars at a constant rate
[12:00:54] <ambro718> pushing them to the lcd
[12:01:02] <ambro718> like a CRT
[12:01:13] <antto> CRT \o/
[12:02:12] <ambro718> the LCD won't display any temporary artifacts if you overwrite a char with the same value right?
[12:02:42] <Epsilon-Auriga_> not that most human eyes can pick out.
[12:03:19] <tzanger> ambro718: depends on the LCD. what I usually find with the HD77whatever LCD controllers is that they are pretty nice unless you try to clear the screen for every update, at which point they do flicker
[12:03:30] <tzanger> but updating by overwriting is fine
[12:03:36] <ambro718> that's good
[12:04:17] <antto> tzanger like clear each char at one go, then set the values at another go?
[12:04:36] <ambro718> I think he means the clear command
[12:04:48] <antto> oh, there's a dedicated command
[12:05:04] <ambro718> it will actually clear the lcd, and it takes some time until your code gets to writing the new chars
[12:05:13] <ambro718> hence the flicker
[12:05:17] <antto> yeah
[12:05:39] <antto> better simply spit the whole thing at once
[18:41:31] <kdehl_> Huh.
[18:45:43] <kdehl_> Aren't there any 16-bit parallel EEPROMs?
[18:45:52] <kdehl> I can't seem to find any...
[18:46:53] <kdehl> EEPROMs with 16 data pins, that is.
[18:47:02] <kdehl> Or, even better, 32.
[18:48:22] <Epsilon-Auriga_> prolly not
[18:50:57] <kdehl> Okay.
[18:51:34] <N2TOH> nah, just use 2 or more EEPROMS to get the data bits you need
[19:09:39] <kdehl> N2TOH: Yeah, that's what I hoped to avoid. But I guess not.
[19:19:32] <N2TOH> what do you need it for?
[19:26:34] <TLoFP> Oh Hi people :D didn't know there was an avr chat
[19:26:45] <Epsilon-Auriga_> there's an avr chat?
[19:26:54] <TLoFP> :P
[19:27:09] <TLoFP> hey what does _SFR_BYTE stand for?
[19:27:19] <TLoFP> I am learning AtmelStudio, comeing form arduino
[19:27:35] <TLoFP> and I am used to doing this: PORTD = 0xFF; but that aparently doesn't work in atmelstudio
[19:28:08] <N2TOH> TLoFP, have you checked out the AVRFreaks site, and AVR-GCC?
[19:28:31] <TLoFP> N2TOH: I tried googling it, maybe it is too basic but couldn't find anything
[19:28:50] <N2TOH> AVR-GCC is "C" for the AVR
[19:29:26] <N2TOH> AtmelStudio is for assempler code, and read/write of the flash and other memeries
[19:29:48] <kdehl> N2TOH: For a BIOS. But it's alright, I can use several chips.
[19:30:02] <Epsilon-Auriga_> _sfr_byte is used internally in avr/sfr_defs
[19:30:19] <Epsilon-Auriga_> I got 5 good hits with google on it right off.
[19:30:21] <TLoFP> what does sfr stand for?
[19:30:29] <Epsilon-Auriga_> status function register
[19:30:32] <TLoFP> oh ok
[19:30:43] <TLoFP> thanks, I knew what the code does but I wanted to know what it means
[19:30:46] <Epsilon-Auriga_> http://www.nongnu.org/avr-libc/user-manual/group__avr__sfr.html
[19:30:49] <TLoFP> :D thanks!
[19:31:25] <Epsilon-Auriga_> oops
[19:31:29] <Epsilon-Auriga_> special function register
[19:31:31] <Epsilon-Auriga_> not status.
[19:31:37] <Epsilon-Auriga_> it's been a long day.
[19:31:55] <Epsilon-Auriga_> sitting here doing absolutely nothing but watching movies and eating.
[19:32:03] <TLoFP> yay, that sounds fun :D
[19:32:27] <TLoFP> I just got done with a day of the most mundane/boring work, i am so excited to be coding my ATMega328P again :)
[19:32:29] <Epsilon-Auriga_> it's hebrew in a hog trough day so no stores are open.
[19:33:40] <Epsilon-Auriga_> no work for me today,,but I get paid for doing nothing so it's not all bad.
[19:33:58] <TLoFP> can you explain this?
[19:34:19] <TLoFP> I am flipping PORTD up and down so I expect a 8 MHz output (SysCLK is 16 MHz)
[19:34:37] <TLoFP> I didn't expect so much overhead from the while loop though, that is the gap that you see in the picture
[19:34:48] <TLoFP> is there any way to reduce the overhead of the while loop?
[19:34:50] <Epsilon-Auriga_> I don't see a picture.
[19:35:00] <TLoFP> http://imgur.com/X7EREvH
[19:35:05] <Epsilon-Auriga_> a while loop is 100% function..
[19:35:08] <TLoFP> mhh... I thought I pasted it lol
[19:36:01] <TLoFP> and a function call is a two cycle instruction?
[19:36:25] <Epsilon-Auriga_> you would have to look in the instruction set docs to find out...
[19:36:44] <Epsilon-Auriga_> if you are looping then you are sucking all the processor time.
[19:36:46] <TLoFP> is it different for every processor?
[19:37:45] <Epsilon-Auriga_> look at the assembly listing put out from gcc...you should be able to break down your code and see what is taking your time.
[19:38:00] <TLoFP> great idea, thanks
[19:38:09] <Epsilon-Auriga_> all AVRs will have the same number of clock cycles for the same instruction.
[19:38:23] <Epsilon-Auriga_> well, atmega and attiny will...atxmega will be different.
[19:39:46] <TLoFP> you mentioned looping like it is bad practice, isn't a loop of some sort necessary for every program?
[19:40:06] <Epsilon-Auriga_> good luck getting 8MHz output from an i/o port without using hardware pwm.
[19:40:17] <Epsilon-Auriga_> I didn't say it was bad practice...
[19:40:27] <TLoFP> oh, sorry I misunderstood :)
[19:41:13] <TLoFP> don't worry this is just for testing purposes. Arduino no longer suits my requirements as its loop has a .875 micro second over head
[19:41:42] <Epsilon-Auriga_> ardweeny libraries have a lot of overhead.
[19:43:04] <Epsilon-Auriga_> if you need stable constant pulses then I suggest using the hardware pwm on a timer.
[19:44:39] <TLoFP> ofcourse
[19:46:49] <TLoFP> all I want to do though is the following: download data from two ADCs (4 bytes per sample at 6.25kHz each), over SPI running at 8MHz, everytime the 328P receives an interupt, then encode that data and shoot it off via async serial to USB.
[19:46:52] <TLoFP> sounds easy enough :D
[19:47:32] <Epsilon-Auriga_> use hardware spi.
[19:48:14] <Epsilon-Auriga_> I suspect an AVR at 16MHz is not going to sustain 8MHz over SPI though.
[19:48:55] <TLoFP> yea it is capable of 8MHz if the double speed bit is set
[19:49:09] <Epsilon-Auriga_> but that's for one byte burst.
[19:49:19] <TLoFP> ?
[19:49:26] <Epsilon-Auriga_> not sustained throughput.
[19:49:35] <TLoFP> oh yes
[20:05:37] <TLoFP> is it possible to not define a loop at all and just use interupts to fire off functions?
[20:06:37] <Epsilon-Auriga_> it is.
[20:08:55] <Epsilon-Auriga_> very much depends on what all you are doing.
[20:10:01] <Epsilon-Auriga_> but remember that interrupt routines can't run at the same time. One at a time even though the interrupts might trigger at the same time.
[20:10:26] <TLoFP> if I define an ISR for INT0 and INT1
[20:10:43] <TLoFP> INT0 fires and then INT1 is received before INT0 ISR finishes
[20:10:49] <TLoFP> is the INT1 interupt lost?
[20:10:57] <Epsilon-Auriga_> I think it will stack but not sure.
[20:11:18] <Epsilon-Auriga_> might should read the datasheet on interrupts...it will tell you all about them and how that works.
[20:21:21] <inflex> yaaaay, for months I had a whole box of 16x2 LCDs that kept getting in my way, that I kept shifting around... and now I want one, I can't find the box
[20:21:52] <Epsilon-Auriga_> hehe.
[20:25:16] <twnqx> TLoFP: just be aware that the prologue and epilogue for register saving will alone take more cycles than the space between two SPI data bytes at 8MHz :P
[20:27:28] <Roklobsta> inflex: drown your sorrows in more beer
[22:12:20] <TLoFP> hi guys/girls, I am a bit confused and would like to ask for a senity check: in AVR-GCC is the following legal: PORTNAME = 0xFF;
[22:12:39] <TLoFP> or do I have to do _SFR_BYTE(PORTNAME) = 0xFF; ?
[22:14:39] <Tom_itx> PORTD = 0xFF; is fine
[22:14:50] <Tom_itx> but you might want a bit mask instead
[22:15:53] <TLoFP> ugh... thanks
[22:15:55] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/c_bits/bits_index.php
[22:15:58] <Tom_itx> have a read.
[22:16:20] <TLoFP> I am so lost right now, my code won't work right if I trigger my interup on a falling edge, but it works just fine if I trigger on a low lvl
[22:16:51] <Tom_itx> maybe you need a pullup on the pin
[22:17:17] <TLoFP> mhh
[22:17:22] <TLoFP> thats a thought
[22:18:02] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/atmega328/PCINT0/quadrature/
[22:18:11] <Tom_itx> that demonstrates rising and falling edge trigger
[22:19:07] <TLoFP> that doesn't make sense though
[22:19:23] <TLoFP> because when I trigger of the low value it triggers as expected at a rate of 12 Hz
[22:19:25] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/atmega328/INT0/
[22:19:32] <Tom_itx> that demonstrates external int use
[22:19:39] <TLoFP> if it were a pull up issue then it would trigger iradically
[22:20:14] <TLoFP> grrr hexchat crashed
[22:20:22] <TLoFP> can you link me to INT0 example again
[22:20:31] <Tom_itx> zlog_
[22:21:14] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/atmega328/INT0/
[22:23:07] <TLoFP> Tom_itx, is it important to place sei() after you setup interupts?
[22:25:57] <TLoFP> Tom_itx, my code is setup exactly as yours
[22:26:02] <TLoFP> this puzzels me
[22:32:51] <inflex> huzzuah, finally got things working
[22:32:53] <inflex> hello Tom_itx
[22:38:55] <Tom_itx> TLoFP, yes it enables them
[22:38:59] <Tom_itx> hey inflex
[22:39:26] <Guest72378> Hey guys I was just given an AVR dragon this christmas :D and went to just try the ISP out on a attiny45 and have been running into some issues I am running the command "sudo avrdude -p t45 -c dragon_isp -P usb -e -B 10 -U flash:w:demo.hex" and all I get is
http://pastebin.com/vaVr5fM9 any ideas on what I should try?
[22:41:07] <Tom_itx> the isp on the dragon doesn't provide power, it comes from a separate power header on the dragon
[22:41:19] <Tom_itx> in case you're trying to power the target with the dragon
[22:42:45] <Tom_itx> as far as the avrdude cmd line: avrdude -c avrisp2 -p m328 -P usb -U flash:w:"/usr/local/avr/test.hex":a -e
[22:42:48] <Tom_itx> is one i use
[22:42:53] <Tom_itx> sub the target programmer
[22:44:00] <Guest72378> seriously? I thought
http://orbisvitae.com/ubbthreads/ubbthreads.php?ubb=download&Number=1817&filename=IO%20Pins,%20ISP%20Pinout.jpg showed Vcc for power to the chip
[22:44:47] <Guest72378> Tom_itx: ^
[22:45:15] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/dragon/dragon3a.jpg
[22:45:19] <Tom_itx> mine is a bit older
[22:45:24] <Tom_itx> but that's the pinout
[22:46:19] <Tom_itx> put a meter on the pins
[22:46:33] <Tom_itx> unless they've changed it there will be no 5v there
[22:47:09] <Tom_itx> the early ones didn't
[22:48:03] <Guest72378> Alright I will check real quick
[22:49:15] <Guest72378> I am reading 4.17Volts
[22:50:44] <Tom_itx> is mosi miso backwards?
[22:50:59] <Guest72378> let me double check
[22:51:50] <Tom_itx> seems the problem is with linux seeing the dragon, not so much the target
[22:51:52] <TLoFP> Guest72378, turn down the program frequency of your ISP device
[22:51:59] <Tom_itx> maybe try a different cable or port
[22:52:06] <Tom_itx> default is 125khz
[22:52:13] <Tom_itx> slow enough for just about anything
[22:52:21] <TLoFP> oh
[22:52:32] <TLoFP> mine was at 2MHz, I didn't realize that wasn't default :)
[22:53:00] <Tom_itx> however it should be 1/4 the clock freq
[22:53:06] <Tom_itx> ( or less )
[22:53:20] <Guest72378> Tom_itx: just checked MOSI and MISO are correct
[22:53:42] <Tom_itx> <Tom_itx> seems the problem is with linux seeing the dragon, not so much the target
[22:53:42] <Tom_itx> <Tom_itx> maybe try a different cable or port
[22:54:08] <Guest72378> really? dmesg reported i
[22:54:13] <Guest72378> s/i/it/
[22:54:20] <Guest72378> yea let me try
[22:54:25] <Guest72378> problem is I am on a chromebook
[22:54:29] <Guest72378> its all I got right now
[22:54:30] <Guest72378> >.>
[22:54:31] <Tom_itx> avrdude: failed to sync with the AVR Dragon in ISP mode
[22:54:38] <Guest72378> so I am working on limited hardware
[22:55:06] <Tom_itx> i'm out.
[22:55:50] <Guest72378> just tried another port no luck ;_;
[22:57:03] <Guest72378> well thanks for trying
[23:01:12] <Guest72378> will try something brb
[23:08:44] <jeff26> yea did not work, still not working
[23:17:25] <abcminiuser_> Anyone here with AS6 installed?
[23:18:27] <Roklobsta> yes
[23:19:01] <Roklobsta> <abcminiuser_> Anyone here apart from Roklobsta with AS6 installed?
[23:19:02] <abcminiuser_> Got 5 mins to test something?
[23:19:10] <abcminiuser_> :P
[23:19:12] <Roklobsta> sure
[23:19:26] <abcminiuser_> http://fourwalledcubicle.com/files/vsix/HEXClassifier.vsix
[23:19:31] <abcminiuser_> http://fourwalledcubicle.com/files/vsix/DataSizeViewer.vsix
[23:19:37] <abcminiuser_> Can you install those, then start AS6?
[23:19:50] <Roklobsta> yep
[23:20:04] <abcminiuser_> Then compile any project
[23:20:24] <abcminiuser_> And a) see if opening the Output Files->HEX and Output Files->SREC files shows them with colours
[23:20:36] <Roklobsta> hang 2
[23:20:48] <abcminiuser_> And b) If View->ELF Symbol Sizes shows up correctly with populated data
[23:20:51] <abcminiuser_> Sure cheers
[23:20:58] <Roklobsta> even with SSD AS6 takes ages to load
[23:23:05] <Roklobsta> View-ELF looks OK
[23:23:10] <Roklobsta> where is outputfiles?
[23:23:20] <abcminiuser_> Solution explorer
[23:23:29] <abcminiuser_> Neat, I'll upload that one to the gallery then
[23:24:01] <jeff26> Alright so I just got access to another computer with linux ran avrdude on the dragon and got the exact same output as before...
[23:24:19] <Roklobsta> .hex has colours. my project doesn't make srec
[23:25:07] <abcminiuser_> Wunderbar, I'll upload that one too
[23:25:09] <abcminiuser_> Thanks!
[23:25:17] <Roklobsta> elf is nifty
[23:28:43] <abcminiuser_> I was going for nifty...
[23:30:46] <Roklobsta> does norway do boxing day?
[23:31:55] <Roklobsta> i was having a quick peek at LUFA earlier. Is there a minimum FLASH/RAM for it to be used effectively?
[23:32:15] <abcminiuser_> Back in Aus now, but I presume so
[23:32:16] <abcminiuser_> Err
[23:32:28] <Roklobsta> it'
[23:32:31] <abcminiuser_> Flash about 2KB for AVR8, 4KB for XMEGA
[23:32:37] <abcminiuser_> SRAM, depends on the class
[23:32:45] <Roklobsta> i just want serial
[23:32:59] <Roklobsta> so i can chat to the avr with putty
[23:33:28] <Roklobsta> back for the so called summer or forever?
[23:35:28] <N2TOH> ATmega1284p has 16KB of SRAM
[23:35:39] <Roklobsta> yes it does
[23:36:08] <Roklobsta> any idea when the next update for as6 is?
[23:36:45] <N2TOH> you could almost run a real operating system in 16MB
[23:36:46] <N2TOH> err 16KB
[23:37:07] <abcminiuser_> No good for LUFA, needs a USB AVR8
[23:38:54] <Roklobsta> almost i have made a preemptive scheduler.
[23:39:22] <N2TOH> http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX
[23:42:02] <Roklobsta> hmmm, history is littered with the carcasses of NIH OS's
[23:42:25] <N2TOH> NIH?
[23:42:33] <Roklobsta> not invented here
[23:42:42] <N2TOH> LOL DEC joke!
[23:43:29] <Roklobsta> like mine. I wanted a preemptive scheduler with yielding and instead of just using someone elses i did my own which made me learn a thing or 2
[23:44:01] <Roklobsta> i should make it available so it can sit atop the heap of said carcasses.
[23:44:13] <N2TOH> I find the novelty of porting an OS older then me to current hardware amusing
[23:44:45] <Roklobsta> well you will learn a thing or 2 n the process
[23:45:06] <Roklobsta> embedded systems AFAIK kicked off with the Apollo computer systems
[23:45:38] <Roklobsta> Apollo as in moon landing not the funky old UNIXy boxes
[23:45:55] <N2TOH> I have seen such hardware at the info age computer meusaume in Wall twp NJ
[23:46:27] <N2TOH> I have also seen the LOL memory for sale @ the Dayton Hamvention years ago
[23:47:09] <Roklobsta> if you start to look under the bonnet of modern languages you realise the lovely abstractions like closures and things are garbage collection are like a ducks feet paddling madly under the surface of the IDE.
[23:47:41] <Roklobsta> ugh too beery, can't grammar cohrerentluy
[23:47:50] <N2TOH> you know the read only core memory
[23:48:00] <Roklobsta> yes
[23:48:30] <Roklobsta> look on you tube and you can see the ladies sewing the core ROM together for the Apollo program. They had to sew the program.
[23:49:39] <Roklobsta> watch this
http://www.youtube.com/watch?v=vU5G9VsoER8
[23:50:47] <Roklobsta> the Moon Machines series is unreal
[23:51:58] <Roklobsta> here are the ladies weaving software
http://www.youtube.com/watch?feature=player_detailpage&v=vU5G9VsoER8#t=1339
