Back
[07:23:39] <inflex> Got a LUFA based AVRISPmkII by Tom_itx , and for some reason I keep getting an error on my system... (ubuntu 14.04) avrdude: Device signature = 0x58442c
[07:23:40] <inflex> avrdude: Expected signature for ATmega48 is 1E 92 05
[07:23:44] <inflex> and that's with nothing plugged in!
[07:23:50] <inflex> ( makes no difference I I plug in the AVR )
[07:24:18] <Tom_itx> that _is_ an odd one
[07:24:49] <inflex> avrdude: stk500v2_command(): command failed
[07:24:49] <inflex> avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Unknown status 0x00
[07:24:49] <inflex> avrdude: initialization failed, rc=-1
[07:25:00] <inflex> Been about 2 year since I used them
[07:25:07] <Tom_itx> it's not seeing the programmer
[07:25:10] <inflex> both give me the same report
[07:25:13] <Tom_itx> that last line says that
[07:25:21] <inflex> [1218745.517872] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[07:25:21] <inflex> [1218745.517877] usb 2-1.3: Product: LUFA AVRISP MkII Clone
[07:25:22] <inflex> [1218745.517881] usb 2-1.3: Manufacturer: Dean Camera
[07:25:22] <inflex> [1218745.517885] usb 2-1.3: SerialNumber: 0000A00128255
[07:25:54] <inflex> Hrmm.. wonder what's going on
[07:27:54] <ivanshmakov> inflex: Not the right /dev/ttyUSB filename?
[07:28:49] <Tom_itx> wait.. that last error says it sees the programmer but not the chip
[07:30:33] <Tom_itx> your line should look something like this:
[07:30:35] <Tom_itx> avrdude -c avrisp2 -p m328 -P usb -U flash:w:"/usr/local/avr/test.hex":a -e
[07:30:55] <Tom_itx> but you knew that...
[07:31:12] <inflex> ja, trying -t mode... with a board I know is working
[07:31:41] <Tom_itx> you could try flashing the firmware but i don't think that would make a difference
[07:31:47] <inflex> ja, thinking the same
[07:31:52] <inflex> weird.
[07:32:00] <inflex> ISP is the right header I should be in?
[07:32:03] <Tom_itx> check the cable just to be sure
[07:32:08] <Tom_itx> yes
[07:32:43] <inflex> See, this is why I shouldn't leave this stuff alone for so long :)
[07:32:58] <Tom_itx> http://tom-itx.ddns01.com:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[07:33:07] <Tom_itx> the firmware is there in case you decide to try it
[07:33:26] <Tom_itx> just use the studio version...
[07:33:32] <Tom_itx> it doesn't affect linux
[07:33:36] <inflex> [1219214.264240] usb 2-1.2: reset full-speed USB device number 19 using ehci-pci
[07:33:41] <inflex> I get that every time I try to program
[07:33:55] <Tom_itx> do you have permission to the device?
[07:34:06] <inflex> running as sudo O_
[07:34:13] <Tom_itx> try different cables / port
[07:34:22] <inflex> tried :(
[07:34:25] <inflex> 3 cables, 2 ports
[07:34:27] <Thrashbarg> "make me a sandwich" "no" "sudo make me a sandwich" "okay..."
[07:34:56] <Tom_itx> Thrashbarg, he knows what he's doing...
[07:35:53] <inflex> got me stumped for the moment... maybe the programming lead is dead...
[07:36:02] <Tom_itx> me too
[07:36:44] <Tom_itx> i gotta run here..
[07:37:43] <Tom_itx> is the switch the right way?
[07:38:11] <Tom_itx> USB <- is usb power -> is target
[07:38:16] <inflex> tried both bus and ext
[07:38:40] <inflex> on the working board, it powers up the unit - so I know the +/gnd are fine
[07:39:01] <Thrashbarg> Tom_itx: I didn't mean that :P
[07:39:06] <Tom_itx> and you've used it quite a bit...
[07:39:10] <Tom_itx> Thrashbarg i figured
[07:39:19] <Tom_itx> anyway.. i'm out the door
[07:39:34] <inflex> okay, np, tx Tom_itx
[08:03:55] <sabesto_> does avrdude work with stk600 in terminal mode?
[08:07:26] <sabesto> nvm, got it to work, apparently -t is not enough, you need -v aswell
[09:08:43] <RLa> i was yesterday inventing my own communication protocol
[09:08:53] <RLa> well, i decided to add checksum
[09:09:08] <RLa> which checksum algorithm i should look at
[09:09:15] <RLa> xor all bytes together?
[09:18:10] <ivanshmakov> RLa: Depends on the resources; I’d check if some low-width CRC would fit.
[09:18:59] <RLa> http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html
[09:19:15] <RLa> may i use iButton 8-bit CRC or is that patented?
[09:19:58] <RLa> would not like to use properietary algos but this one is conveniently implemented in stdlib
[09:20:35] <ivanshmakov> RLa: I doubt that anything patented or proprietary would last in AVR Libc for long.
[09:20:49] <RLa> good
[09:21:49] <ivanshmakov> RLa: Have you decided to use an ASCII-friendly algorithm yet?
[09:21:56] <ivanshmakov> (And if not, why?)
[09:23:55] * inflex really starts to wonder wth is going on with his AVRISP2
[09:27:40] <inflex> What's Tom_itx's website? Seems to be non-accessible atm
[09:28:56] <inflex> ah, got it
[09:31:29] <RLa> ivanshmakov, not ascii friendly yet :/
[09:34:15] <RLa> i just noticed big issue with my protocol
[09:34:57] <RLa> i cannot send byte 0 as value without it being mistaken for message terminator
[09:37:01] <RLa> damn it
[09:43:29] <RLa> ah, i can just add byte escaping
[09:43:46] <RLa> hm, i cant
[09:45:54] <RLa> hm, can i base64-encode messages
[09:46:25] <RLa> ivanshmakov, that's somewhere between ascii and binary :)
[09:48:16] <RLa> hm, hex encoding is easier
[09:48:29] <RLa> that would be base16, i guess :)
[09:57:58] <ivanshmakov> RLa: That’s what I use in the example I’ve referenced earlier: Base32.
[09:58:46] <ivanshmakov> RLa: However, it’s rather Base32/64, – it encodes 5 payload bits per byte /and/ also one “sync” bit, too.
[09:59:41] <ivanshmakov> Given that the samples are 10-bit wide themselves, using Base32 becomes surprisingly easy to implement.
[10:03:28] <RLa> hm, i have most data byte-aligned
[12:11:19] <RLa> is it possible to get USART receive interrupt before USART sent interrupt from previous sending is triggered?
[12:11:45] <learath> full duplex?
[12:11:50] <RLa> hm
[12:16:28] <RLa> damn, this usart state handling goes so complex
[12:21:49] <ivanshmakov> RLa: Aren’t transmit/receive USART operations (as implemented in AVRs) mostly independent?
[12:22:30] <RLa> yes, and i want to make sure i do not handle input when previous output has not been sent yet
[12:24:28] <N1njaneer> ivanshmakov: Yes, receive and transmit stages operate completely independently.
[12:24:37] <N1njaneer> Other than that they have to share the same baud rate.
[12:25:48] <RLa> i now have 4 buffers and quite many states
[12:26:01] <N1njaneer> Simplify it where possible.
[12:28:51] <RLa> damn, had one flag with wrong initial value
[12:31:16] <RLa> got echo working now
[12:31:24] <RLa> adding checksum as well
[12:31:54] <RLa> and i switched command termination to line ends from byte 0
[12:39:23] <RLa> hm, gotta implement that crc in js too
[13:01:09] <acecase> I'm setting up to learn mpu developement and I'm looking at the TL866. Primarily I will be working with atmega using atmel studio. I'm making the assumption that I will be able to write the .hex file that is created when I compile with default settings for my given atmega using the TL866. Can someone confirm? Not finding anything online.
[13:01:59] <acecase> That is to say flash my atmega with the created hex using the TL866
[13:02:26] <N1njaneer> What is the TL866?
[13:02:58] <acecase> It's a universal programmer. It isn't supported by atmel studio, but it can flash a mcu with a binary
[13:03:31] <ivanshmakov> acecase: What protocol does it speak?
[13:03:51] <acecase> I have confirmed that it will work with my atmegas, but I don't know that the .hex generated by atmel studio is a complete binary that will be runnable.
[13:04:05] <ivanshmakov> acecase: It should be.
[13:04:09] <acecase> ivanshmakov, I have no idea :)
[13:04:14] <acecase> Thank you
[13:04:23] <N1njaneer> Other than that part, you are pretty much spot on. The toolchain will spit out a .ELF or .HEX, and you load it with your programmer of choice. The official programmers from Atmel that will do ISP and JTAG for all AVR and ARM parts are less than $30 though, so I'm a big fan of going with the officially supported stuff. Not only do you get a validated solution, you also get full in-system debug and
[13:04:24] <N1njaneer> funtionality only accessible via JTAG
[13:05:12] <N1njaneer> acecase: Yes, the .HEX will be. Keep in mind there is a seperate .HEX for flash memory contents and for the eeprom, if you are using the latter and need to preload it. .ELF has the ability to concatenate all of those together.
[13:05:27] <acecase> The debugger is what has me leaning toward exactly that, but I love the idea of being able to flash just about anything I run into with the TL866
[13:05:55] <N1njaneer> Use the Atmel programmer for all the ATMEL stuff and use the TL866 for everything else.
[13:06:37] <N1njaneer> Honestly I've not seen much use for universal programmers, since most everything I need to do is either proprietary to the vendor, or is JTAG... which still makes it proprietary to the vendor. Though YMMV :)
[13:07:03] <Tom_garage> it is intel hex format
[13:07:04] <myself> Our TL866 has been handy when reverse-engineering old LED signs and stuff
[13:07:09] <N1njaneer> Though could be useful for reading/writing things like SPI flash memory chips and things I suppose.
[13:07:10] <acecase> That's probably what I will end up doing. I think I have been looking into all this so much that I'm losing sight of how little I would do anything other than atmegas. If I want to do pic I can get a pickit3 and the avrisp mkii for the price of this TL866
[13:07:23] <myself> "Why, yes, this is a font lookup table in EPROM whose data lines drive the segment latches directly"
[13:08:26] <N1njaneer> I honestly have the Atmel programmer, a Xilinx USB JTAG platform cable, and a Saleae Logic-16, and it pretty much covers all digital device programming and debugging for the last several years. But again, YMMV. :)
[13:09:14] <acecase> Thanks for the help. I think you make a good point. the avr-isp mkii is going to be worth the price even if I only ever used it for debugging. Especially concidering that I'm just going to start learning
[13:09:38] <N1njaneer> The Logic-16 is certainly invaluable for reverse engineering stuff. I DID hack together a parallel port thing for doing I2C flash read/writes a while ago with one of the free utilities out there, but that's because we had to dump an existing I2C flash on someone else's board.
[13:10:21] <N1njaneer> acecase: The MKII is actually being discontinued and replaced with a newer programmer - same cost but does ISP and JTAG for AVR, AVR32, XMEGA, and all the SAM ARM stuff.
[13:10:26] <myself> this is where it's nice to share a lab with a bunch of other nerds, because suddenly you can justify having all the cool tools
[13:11:20] <acecase> N1njaneer, of course it is. About the time I'm going to buy one :)
[13:11:49] <acecase> I assume this new programmer isn't available?
[13:11:56] <N1njaneer> Hold one
[13:14:26] <N1njaneer> (phonecall)
[13:16:50] <N1njaneer> acecase: Are you in the US?
[13:17:02] <acecase> I just read that the avrisp mkii doesn't do debugging
[13:17:05] <acecase> yes sir
[13:17:13] <N1njaneer> No, you need JTAG and/or OneWire
[13:17:39] <N1njaneer> Trying to find the part number for the new programmer on DigiKey/Mouser - the ones I have here I got for free from our local Atmel FAE
[13:17:56] <acecase> thank you
[13:17:59] <N1njaneer> The ISPMK2 is still a great programmer, but for just a bit more you get a ton more capability
[13:18:56] <acecase> "The Dragon" gets mixed reviews, so I appriciate it
[13:19:42] <N1njaneer> We have a dozen or so MK2's sitting all over the office here :D
[13:20:36] <N1njaneer> The only issue I have with them is that after 4-5 years they had a habit of just going belly-up, had probably 3 of them die on my over the years. Just refuse to communicate with the chips, but for $30 just pitch and buy another
[13:22:06] <N1njaneer> acecase: Oh, thanks Atmel. Part number is written right on the spiffy box!
[13:22:20] <N1njaneer> acecase: Search DigiKey for "ATATMEL-ICE"
[13:22:29] <acecase> great. thanks
[13:22:31] <N1njaneer> Basically you have three options --
[13:22:47] <N1njaneer> Raw PCB, PCB in enclosure, or PCB in enclosure with the cables.
[13:23:57] <N1njaneer> So technically in case it's about $10 more than an MK2 but you get full ISP, OneWire, and JTAG for AVR through SAM ARM. Basically the tool unifies everything. And when I started, the JTAG programmers for AVR were about $400 each, and didn't work with the ARM stuff. That was another $400 device :D
[13:24:11] <N1njaneer> Anyhow, hope that helps!
[13:24:31] <N1njaneer> Spend the little extra $$$ and get the only programmer you'll ever need for everything Atmel.
[13:24:38] <acecase> And only $35 it helps a lot. thanks
[13:26:12] <acecase> Actually, $93 so I don't have to worry about my cable work while learning. I'm glad I asked here. Thanks again
[13:27:12] <N1njaneer> Sure! Good luck!
[13:27:58] <acecase> Now back to pretending to work. Have a good one
[14:53:00] <ferdna> wow....
[14:53:07] <ferdna> http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages
[15:24:37] <Jordan_U> We just finished a product and I'd like to commit the binary in our git repository. Does it make sense to just commit the Release/foo.hex file that Atmel Studio creates? Are there any other files that I should probably commit?
[15:25:40] <jonored_> You'll probably want to set it as a binary, too, so you don't try to delta-compress it :)
[15:25:44] <N1njaneer> Unless you need specific fuse programmings or EEPROM contents the .hex file is a good simple way to go.
[15:26:42] <N1njaneer> I prefer having the .HEX file seperate, and a README file which has the fuse values to explicitly set. Things can get a bit... dangerous... if the fuses are in an .ELF file.
[15:28:27] <Tom_garage> it would be ok for producion programming
[15:29:43] <Jordan_U> I have one, not terribly important, 32 bit value stored in EEPROM.
[15:30:51] <N1njaneer> Tom: I find it more useful to write a script to do the fuses individually. Especially so I can blow the clock fuses, then change the ISP rate, then upload the program. So everything isn't loading in at 125Khz default rate :)
[15:31:37] <N1njaneer> Jordan_U: You can always do the trick where you read the EEPROM to see if the values are 0xFF, and if so, then do a first-time initialization of your value in to the EEPROM to set the initial sane value :)
[15:32:06] <N1njaneer> But really anything works
[15:32:23] <Jordan_U> N1njaneer: I'm already doing that, just because I want to sanity check the value for its own sake.
[15:32:35] <Jordan_U> Hence why it's not terribly important.
[15:32:40] <N1njaneer> Gotcha.
[15:41:01] * N1njaneer places a PCB order.
[15:42:40] <N1njaneer> Time to triple-check everything before this gets screwed up :)
[15:43:54] <N1njaneer> Tiny little oddly-shaped board 1.7" x 1.5" in size with 48 LEDs and 3 QFNs plus a bunch of 0402 passives and a few other chips.
[15:44:13] <N1njaneer> I like a good routing challenge.
[16:13:14] <Tom_itx> N1njaneer who you using for your PCB?
[16:20:44] <RLa> anyone used bytecode interpreter in avr to dynamically update running code?
[16:23:32] <Roklobsta> RLa what interpreter, what language?
[16:24:09] <RLa> some simple language, variables and conditionals only maybe
[16:25:56] <Roklobsta> it can be done, but you'd need to find an AVR with sufficient ram for useful code
[16:26:20] <Roklobsta> if it's variables and conditionals then it'd be C anyway.
[16:26:29] <RLa> it would only run the feedback system that turns continuous inputs to actions
[16:26:52] <Roklobsta> sounds like a job for runofthemill C.
[17:04:37] <jonored_> I think basic stamps are basically that...
[17:18:56] <RLa> will check them more closely
[17:24:20] <jonored_> I mean, I'm not convinced they are /good/, just that that's what they /are/.
[17:24:26] <jonored_> ...oh well.
[17:37:20] <Kev> $50 O_o
[17:38:19] <inflex> morn all
[18:12:22] <inflex> Tom_itx: I'll just try this on a completely separate machine, might be something with my personal install
[19:02:00] <Lambda_Aurigae> http://questionablecontent.net/comics/135.png
[19:28:35] <thekindlyone> connecting usbasp to a dev board's ISP, with an atmega32A , on running the avrdude command consecutively, I get random results. What could be the problem.?
http://pastie.org/9401320
[19:29:39] <learath> it looks like the first time work
[19:29:41] <Tom_itx> clock too fast?
[19:29:42] <learath> then it never worked again?
[19:29:54] <Tom_itx> try -B32
[19:31:36] <Tom_itx> inflex, if you had a scope you could probe the avr data pin against the pin on the far side of the buffer chip
[19:31:46] <Tom_itx> it's possible the buffer is bonkers
[19:32:16] <Lambda_Aurigae> yanno, I've never had any problem programming any chip at any speed from 1MHz to 20MHz with my old reliable parallel port stk200 clone programmer.
[19:32:29] <Tom_itx> tip: don't fly ukraine air
[19:32:42] <learath> 20mhz? Really?
[19:32:50] <Lambda_Aurigae> Tom_itx, yeah...or if you do, bring your own parachute and chaff
[19:33:05] <Tom_itx> wouldn't matter
[19:33:13] <Tom_itx> decomression would do you in anyway
[19:33:18] <Lambda_Aurigae> learath, yeah...atmega1284p with 20MHz crystal works just fine on a simple parallel port programmer.
[19:34:29] <learath> uh. you don't program at 20mhz with a 20mhz clock AVR :P
[19:35:00] <Tom_itx> no, the clock needs to be at least 4x the spi rate
[19:35:04] <Lambda_Aurigae> didn't mean I upload the program at 20MHz...just that the chip is clocked as such and it works fine.
[19:35:10] <thekindlyone> learath, were you responding to my query? I am confused.
[19:35:16] <Tom_itx> or you will lose data
[19:35:30] <Lambda_Aurigae> never had a problem programming any chips with the old reliable like people have with those usbasp things.
[19:35:44] <Tom_itx> i don't use those crappy things
[19:35:55] <Lambda_Aurigae> me either.
[19:36:08] <Tom_itx> i've used parport but prefer my usb one now
[19:36:24] <Lambda_Aurigae> mostly I use my parallel port 74ls244 based stk200ish programmer or the one I got from you if I'm not in my dungeon lab.
[19:38:03] <Tom_itx> figured out why my saleae software doesn't work on linux...
[19:38:10] <Lambda_Aurigae> oh?
[19:38:11] <Tom_itx> they switched to gcc 4.7
[19:38:19] <Lambda_Aurigae> time to update the kernel?
[19:38:21] <Tom_itx> instead of 4.1 or 4.4
[19:38:29] <Tom_itx> can't
[19:38:34] <Tom_itx> i use it for linuxcnc
[19:38:41] <Tom_itx> RTAI
[19:38:46] <Lambda_Aurigae> RTAI?
[19:38:53] <Tom_itx> realtime
[19:39:05] <Lambda_Aurigae> aahh.
[19:39:28] <Tom_itx> the older version still works
[19:39:43] <Tom_itx> i just wanted to see the new functionality they added
[19:39:50] <Tom_itx> i could try it on windows i suppose
[19:39:51] <Lambda_Aurigae> time to move one or the other to a different computer.
[19:40:33] <inflex> Tom_itx: unlikely on *both* :(
[19:42:00] <SilverB36> Speaking of programmers, out of curiosity, what kind of hardware do you need to do HVSP or HVPP?
[19:42:05] <Tom_itx> no reason it should be if you haven't been using it
[19:42:15] <Tom_itx> SilverB36, Dragon will do that
[19:42:20] <Tom_itx> $50
[19:42:39] <Lambda_Aurigae> SilverB36, you need something to pull the reset to +12V and some i/o pins to connect to the programming pins....the datasheet tells all about it.
[19:43:04] <Lambda_Aurigae> if you have hosed the fuses, google search for fuse doctor
[19:43:08] <Tom_itx> the ISP protocol is different or i'd try it on my programmer
[19:43:17] <Tom_itx> TPI is the same...
[19:43:25] <Tom_itx> i have a 12v HV thingie for it
[19:43:54] <Lambda_Aurigae> I built a fuse doctor last week just for the fun of it..works rather well.
[19:44:39] * Tom_itx goes to kick back a while
[19:44:42] <SilverB36> Applying 12V to reset isn't too difficult. Could you use ISP to program the avr this way?
[19:44:50] <Lambda_Aurigae> no
[19:44:57] <Lambda_Aurigae> HVSP is not the same as ISP
[19:44:57] <Tom_itx> i just said the protocol is different
[19:45:03] <Lambda_Aurigae> and HVPP is even more different.
[19:45:07] <Tom_itx> way
[19:45:10] <SilverB36> hmm
[19:45:12] <Lambda_Aurigae> datasheet, read
[19:45:31] <Tom_itx> the dragon help in studio will show the pinouts you need for HVPP
[19:45:50] <Tom_itx> uses damn near half the pins
[19:45:54] <SilverB36> Luckilly I don't have to use it. I haven't botched the fuses yet, it was more out of curiosity =)
[19:46:09] <Tom_itx> well just don't botch them
[19:46:16] <Duality> does anyone know a dip flash chip ? like i have static ram. 32K x 8 but then instead flash.
[19:46:23] <Lambda_Aurigae> you can look at the source code for the fuse doctor...and the hardware too for that matter.
[19:46:40] <Tom_itx> Duality there's serial flash
[19:47:02] <Duality> i want no serial
[19:47:10] <Duality> i want it all nice and parallel :)
[19:47:26] <Lambda_Aurigae> at28c256
[19:47:50] <Duality> it's for a avr project. but nice to know for my future diy computer related projects
[19:48:02] <Lambda_Aurigae> http://pdf.datasheetcatalog.com/datasheet/atmel/DOC0046.PDF
[19:48:11] <Lambda_Aurigae> probably not made anymore though.
[19:49:59] <Lambda_Aurigae> http://ww1.microchip.com/downloads/en/DeviceDoc/25022B.pdf
[19:50:15] <Lambda_Aurigae> not 32k*8 though..much larger.
[19:50:40] <Lambda_Aurigae> http://www.microchip.com/wwwproducts/Devices.aspx?product=SST39SF010A
[19:50:52] <Lambda_Aurigae> sample time!
[19:51:45] <Duality> nice that at29c256 is really niced documented in contrast to the static ram i got working :)
[19:52:12] <Lambda_Aurigae> it's atmel, of course it is.
[19:52:19] <Duality> :)
[19:52:24] <Lambda_Aurigae> unfortunately, it appears to not be in production anymore.
[19:55:13] <Duality> i actually don't need that much flash
[19:55:37] <Lambda_Aurigae> I have a use for it...just ordered some from microchip.
[19:55:47] <Lambda_Aurigae> samples are awesome.
[19:56:16] <Lambda_Aurigae> add program storage to my 8052 computer system.
[19:56:47] <Duality> nice
[19:56:54] <Duality> build it yourself :)?
[19:57:02] <Lambda_Aurigae> building, yeah.
[19:57:34] <Lambda_Aurigae> nice thing about the 8052 is being able to run code from external parallel memory.
[19:57:49] <Lambda_Aurigae> I already have some 128K*8bit nvsram on it.
[19:58:30] <Lambda_Aurigae> 2 of them, bank switchable in 32K banks...one for program and one for data space.
[19:59:20] <Lambda_Aurigae> working on a commodore-64 type OS for it.
[19:59:43] <Duality> put it online somewhere :)?
[19:59:49] <Lambda_Aurigae> eventually.
[20:00:00] <Lambda_Aurigae> building bits and pieces here and there.
[20:00:59] <Lambda_Aurigae> kinda switched modes recently and built a second one with a pic32 for the main processor but that can't run program from external memory so stuck with interpreted language.
[20:01:19] <Duality> i was wondering if you already had done that :)
[20:02:22] <Lambda_Aurigae> the interpreted on the pic32 is around the same as native code on the 8052 chip I'm using.
[20:03:04] <Lambda_Aurigae> one of the things I'm working on for it is an 800x600 VGA video generator.
[20:04:01] <Duality> Lambda_Aurigae: actually was going to sleep. but now i am doing research on the 8052 :)
[20:04:12] <Lambda_Aurigae> I use a rather expensive one.
[20:04:18] <Lambda_Aurigae> the ds89c450 from maxim-ic.com
[20:04:49] <Lambda_Aurigae> 32MHz single cycle core so it's dang fast when running from internal flash.
[20:10:10] <Duality> is 8052 avr ?
[20:10:16] <Lambda_Aurigae> no.
[20:10:26] <Lambda_Aurigae> atmel makes some 8052 chips though.
[20:10:53] <Lambda_Aurigae> 8052 is an update to the venerable 8051, perhaps the most used microcontroller in history.
[20:11:14] <Lambda_Aurigae> this project does use AVRs though, for the video and audio generation.
[20:13:42] <Duality> i gues i can just as wel get me some spi flash/eeprom
[20:13:51] <Duality> now i think about it anyway
[20:13:57] <Lambda_Aurigae> http://www.atmel.com/devices/AT28C64B.aspx
[20:14:09] <Lambda_Aurigae> atmel parallel eeprom.
[20:14:13] <Lambda_Aurigae> not flash, but,
[20:14:29] <Duality> but ?
[20:14:38] <Lambda_Aurigae> but it works.
[20:14:43] <Duality> ah i see :)
[20:14:43] <Lambda_Aurigae> depending on what you want to do with it.
[20:14:48] <Duality> store things
[20:14:57] <Lambda_Aurigae> I like nvsram myself.
[20:15:06] <Lambda_Aurigae> but that can get pricy.
[20:17:16] <Lambda_Aurigae> nice part of that eeprom is it is accessed just like sram...for read and write.
[20:17:26] <Lambda_Aurigae> flash takes special commands and sequences to write to it usually.
[20:18:28] <Duality> hmm another consideration that makes me lean towards eeprom :)
[20:21:38] <Lambda_Aurigae> http://www.maximintegrated.com/en/products/digital/memory-products/DS1230W.html
[20:21:41] <Lambda_Aurigae> these are neat.
[20:21:48] <Lambda_Aurigae> sram with battery backup onboard.
[20:22:13] <Lambda_Aurigae> just like the old 386 and 486 computers used to store the system settings.
[20:22:51] <Lambda_Aurigae> low power CMOS technology...hence the name CMOS settings...
[20:23:00] <Duality> hmm
[20:23:13] <Lambda_Aurigae> use it just like sram...
[20:23:15] <Duality> why do i think of gameboy game cardridges
[20:23:33] <Lambda_Aurigae> only thing is, if the power is below tolerance it disables write.
[20:23:50] <Lambda_Aurigae> and if the power drops too low the onboard lithium battery maintains the memory.
[20:24:01] <Duality> nice
[20:24:18] <Duality> but the battery is in the chip ?
[20:24:19] <Lambda_Aurigae> comes in an EDIP and powercap package.
[20:24:25] <Lambda_Aurigae> yeah..it's like half an inch thick.
[20:24:30] <Lambda_Aurigae> on the EDIP.
[20:25:08] <Lambda_Aurigae> encapsulated dip...basically, ram, nvram controller, and battery are encased in epoxy.
[20:25:38] <Lambda_Aurigae> but pricy compared to eeprom or flash.
[20:26:49] <Lambda_Aurigae> but, maxim is almost as good as microchip for samples.
[20:27:13] <Lambda_Aurigae> don't know how they do to the NL though.
[20:27:17] <Lambda_Aurigae> anyhow, bedtime here.
[20:27:34] <Duality> have nice dreams. and thanks for helping me out :) !
[20:50:28] <Valen> battery built into chip does limit the product lifespan
[20:50:57] <jacekowski> they are rated for 15 years
