Back
[00:04:03] <ThersiT> Anyone here use Eclipse for AVR development who can help me get a library I downloaded off the net included in my project?
[00:06:53] <ThersiT> It's the u8glib graphic LCD library. I can't find much info about it on the net.
[00:22:08] <inflex> mog: get those LCDs going yet?
[00:36:51] <ThersiT> Or could anyone point me towards some further reading on the subject? I'm really stuck here.
[01:41:20] <mitsakos> hello, i'm trying to use a serial SPI ram with avr. The ram is the Slave and AVR the Master. What i can't understand is how the ram will get the clock to reply me the data i request with the read instruction i send to it.
[01:57:03] <Casper> the avr have no build in way to directly work with spi ram
[01:57:08] <Casper> so you need to do it in software
[01:57:37] <Casper> so you need to deal with it as any other spi device
[01:57:48] <Casper> just read both datasheet for the protocol
[02:02:51] <mitsakos> well my exact problem is that i have impliment it and it works correctly. What i do is read from uart and write to the serial ram. The problem comes when i read from ram and immediately after an uart receive interrupt occures and writes to ram. In this case the byte received before the write instruction is read from the AVR as 0xFF but on the bus is correctly (checked with logic analyzer)
[02:04:43] <mitsakos> The 0xFF depends if i have the pull up enabled or not. What means that the avr reads the value wrong like something losing the timing?
[02:07:16] <Casper> hmmm can'T say
[02:07:32] <Casper> are you doing some 16 bits stuff?
[02:08:19] <mitsakos> yes
[02:08:27] <mitsakos> the address of the ram is 16-bit
[02:08:46] <Casper> you might want to use the atomic functions
[02:08:46] <mitsakos> so i send first the 8 MSB's then the other 8
[02:08:58] <Casper> 16 bits can be screwed up sometime
[02:09:06] <mitsakos> atomic?
[02:09:08] <Casper> due to the interrupt...
[02:09:51] <mitsakos> to enable the interrupt and read inside the interrupt routine?
[02:09:56] <Casper> http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
[02:10:40] <Casper> basically, there is a possibility that the main code set the 16 bits register, but your interrupt routine screw it up
[02:11:19] <mitsakos> ah..
[02:11:30] <mitsakos> atomic is like something mutex lock in parallel programming?
[02:12:37] <Casper> it disable the interrupt for that block
[02:12:51] <Casper> ensuring that no interrupt fuck it up
[02:14:05] <mitsakos> something more the ram says that i have to send a 8 bit command (Read/Write) then 16-bit address (Where to Read/Write) and then it replys the data if it is read
[02:14:35] <mitsakos> how it is supposed to reply without clock?
[02:15:21] <mitsakos> what i do now for read is 8-bit command 16-bit address and 8-bit dummy byte to send a clock for the ram to reply me the requested data
[02:15:39] <mitsakos> is this the correct way?
[02:16:38] <Casper> dunnot
[02:16:46] <Casper> time to sleep for me
[02:16:46] <Casper> nite
[02:17:07] <mitsakos> thnx bbz
[05:56:23] <Metalsutton> Does anyone here know much about usb? Particularly, hubs?
[07:25:37] <theBear> yeah, they let you plug in more than one thing... ask a question
[07:28:11] <mog> inflex, actually i have been having problems with getting the cable pinned to something. did you ever get a connector or were you just hotbaring it to a pcb?
[07:30:50] <inflex> I bought an 8 x 1mm way FPC connector
[07:31:39] <inflex> http://nqrc.com/images/PLD-SCC1-layout.jpg
[09:12:07] <mog> inflex, thanks
[09:20:36] <inflex> np
[09:50:09] <jaeckel> how can I place a string into flash memory?
[09:51:00] * mrfrenzy photoshops a piece of cotton wire through a usb stick in his mind
[09:54:27] <jaeckel> ok, got it
[10:19:37] <krautguy> i bet u are all students ;) - or is there another reason to work with AVR?
[10:20:03] <jaeckel> sure
[10:20:06] <jaeckel> it's cheap
[10:21:07] <krautguy> so it really i used in real life / industry?
[10:21:14] <mrfrenzy> lots
[10:21:16] <krautguy> -i
[10:21:23] <mrfrenzy> you will find AVR and PIC chips in many commercial products
[10:21:24] <jaeckel> yeah it is
[10:21:25] <krautguy> okay.. so i was wrong, dont mind :)
[10:21:40] <jaeckel> even more than you think
[10:21:53] <mrfrenzy> you probably have atleast 2 in your house
[10:22:22] <nofxx> krautguy: if the comparison on your mind was arm, x86...something more elaborate, that's a ICBM to kill a bug.
[10:22:23] <jaeckel> you ever thought about how your window lift in your car (if you have one :D ) works?
[10:22:26] <krautguy> its just, i came directly from my course and i was a little bit confused.. :)
[10:22:53] <krautguy> but in fact you all are students, right? :p
[10:23:02] <mrfrenzy> I'm a teacher and IT consultant
[10:23:04] <jaeckel> replace are by were ;)
[10:23:07] <mrfrenzy> ten years since I was in school
[10:23:19] <nofxx> more like teatchers get in here to get help
[10:23:34] <krautguy> okay.. teacher is the same thing as as student.. you are a human in a school :-)
[10:25:19] <theBear> jeez, wanna be careful there kraut.... that kinda talk is offensive... i almost never been a student by choice, letalone in electronics... used a lot of micros professionally over the years tho
[10:25:24] <krautguy> my problem was just, that i thought, "okay i can learn now to write some stuff in assembler for AVR32.. but i'll never be able to use it again"..
[10:25:33] <krautguy> but now i know it better
[10:25:40] <theBear> i hope so
[10:26:03] <jaeckel> uhm
[10:26:08] <theBear> if ya wanna see a handful of avr's in a $30,000+ product lookup Martin Mac3k or so
[10:26:19] <theBear> might be mac2k, i'm outta touch
[10:26:29] <jaeckel> who of the other guys here writes his software in assembler?
[10:26:35] <jaeckel> parts of it, ok
[10:29:00] <theBear> only a fool writes everything in assembly these days for anything with a compiler available....
[10:30:04] <mrfrenzy> yes, you will be much more productive with C
[10:30:32] <mrfrenzy> assembler is useful if you are going to make a million very simple devices and want to buy an MCU with very low memory
[10:31:46] <theBear> but by the time your mcu is that small you probably won't find a compiler for it anyway, or at least not a practical one
[10:52:58] <jacekowski> mrfrenzy: or you want to make millions of devices
[10:53:31] <jacekowski> mrfrenzy: then increasing software cost by $1000 is nothing compared to savings on hardware
[10:53:39] <mrfrenzy> jacekowski: that's what I said
[11:06:29] <gkwhc> Hi, I am trying to select a 3v3 logic level MOSFET (
http://www.nxp.com/documents/data_sheet/NX3008NBK.pdf) so I can switch power to an SD card, other onboard ICs, with a MCU. My MCU's output high voltage is >2.3V, and the gate-source threshold voltage of the mosfet is 0.9V. I have examined the Rds(on) graphs, etc and seems like this mosfet is suitable. the datasheet also says when Vgs is 1.8V, Rds is 2ohms. Can somebody please kindly confirm this, as I am not ve
[11:08:07] <vanquish> gkwhc: what is your mcu voltage? 5V?
[11:08:20] <gkwhc> vanquish: it is operating at 3.3V
[11:09:51] <vanquish> *shrugs*
[11:09:56] <vanquish> looks good to me, i think
[11:10:09] <vanquish> might want to get one more opinion, though
[11:10:21] <vanquish> been a couple years since i've done anything similar
[11:10:23] <gkwhc> vanquish: okay. thank you so much!
[11:11:20] <vanquish> gkwhc: remember there is setup time for the sd card between turning this mosfet on and accessing the sd card
[11:11:33] <vanquish> have to clock it 100 times or so iirc
[11:12:04] <gkwhc> ok
[11:12:12] <Kevin`> gkwhc: why are you using an n-channel mosfet?
[11:12:34] <Kevin`> or are you actually going to switch the '0v' rail to the sd card
[11:13:31] <vanquish> Kevin`: ?
[11:13:59] <vanquish> Kevin`: i'm assuming he's switching low side
[11:14:04] <gkwhc> Kevin`: i thought high side side switching is the way to go. and since i want the default state to be off, i chose N-channel
[11:14:31] <vanquish> gkwhc: hrmmm
[11:14:42] <Kevin`> gkwhc: that's not what n/p channel means
[11:15:04] <vanquish> Kevin`: derp? explain.
[11:15:44] <Kevin`> an n-channel mosfet is switched by a voltage difference vs the low side. a p channel mosfet is switched by a voltage difference vs the high side
[11:17:23] <gkwhc> but if i apply 0V (default state) to the gate of the N-chan mosfet, it will be off
[11:17:37] <vanquish> hmm, in practice they are usually used like that
[11:17:38] <Kevin`> gkwhc: same with an enhancement-mode p-channel mosfet
[11:18:02] <vanquish> but it's really a matter of perspective - what you choose to be your reference
[11:18:02] <gkwhc> oh
[11:18:24] <gkwhc> so why cant i do high side switching with it?
[11:18:39] <gkwhc> because its n-chan?
[11:18:44] <Kevin`> anyway, the important point is that with an n mosfet, the voltage you are applying would be compared to the OUTPUT
[11:19:42] <Kevin`> so your resistance would depend on your output voltage
[11:19:53] <Kevin`> I don't personally think that's entirely sane to do
[11:20:09] <Kevin`> since you want it to just turn on or off depending on the gate voltage
[11:20:42] <gkwhc> yes
[11:22:18] * vanquish is a fan of the tittilation
[11:22:28] <vanquish> oops, wrong channel...
[11:23:20] <vanquish> oops, wrong channel...
[11:23:45] <vanquish> blah
[11:23:47] * vanquish learns to irssi
[11:24:17] <vanquish> hmm, seems like i'm missing a line in my split window...
[11:24:41] <vanquish> no, not really
[11:27:29] <gkwhc> Kevin`: hm are you saying that if i use the n-channel mosfet, the voltage at the gate will have to be higher that the drain for it to turn on?
[11:46:33] <theBear> indeed, but with a p that 'same' threshold is INSIDE of vcc, which you have available, as opposed to vcc + whatever that particular fet needs to turn on
[11:46:35] <cyanide> hello hello
[11:46:43] <theBear> yo yo
[12:57:30] <haydenmuhl> Hi, all. I'm getting the following error when trying to connect to my STK600 using avrdude: "avrdude: stk500v2_program_enable(): bad STK600 connection status: Target not detected (0x00)". Any clues on how to solve this?
[12:58:02] <haydenmuhl> avrdude 5.10 on Ubuntu, btw
[12:58:18] <RikusW> is your avr properly connected ?
[12:58:25] <RikusW> using jtag or isp ?
[12:59:20] <haydenmuhl> It is connected to the computer using the USB cable. Not sure about jtag or isp.
[12:59:42] <RikusW> how did you connect the target avr to it ?
[13:00:08] <haydenmuhl> I plugged in the usb cable to the board and my computer. I don't understand the question.
[13:00:46] <RikusW> seems you don't have any chip connected to program...
[13:00:57] <haydenmuhl> Oh, no. The chip is connected properly.
[13:01:19] <RikusW> sure ?
[13:01:22] <haydenmuhl> The board works with AVR Studio 4, but my Windows box is a clunker and I would rather not use it if I can help it.
[13:01:30] <RikusW> Target not detected (0x00) ---- means it isn't
[13:01:40] <RikusW> ah
[13:01:49] <RikusW> so as it is connected it works on windows ?
[13:01:53] <haydenmuhl> Yes
[13:02:10] <RikusW> what is the commandline you used ?
[13:02:41] <haydenmuhl> avrdude -p m2560 -c stk600 -v -t -P usb
[13:02:57] <haydenmuhl> It doesn't really matter what command I use. I get the same error every time.
[13:03:35] <haydenmuhl> Also, if I connect to the board with AVR Studio, then go back to avrdude, avrdude works better for a time, until I botch a command, then I start getting this error again.
[13:03:54] <haydenmuhl> I can link to the verbose output if that would be helpful.
[13:05:13] <RikusW> what command breaks it ?
[13:05:31] <RikusW> let me guess, setting the ISP clock maybe ?
[13:05:42] <haydenmuhl> I tried to load a .hex file without the ISP cable connected, I believe.
[13:06:26] <RikusW> sounds odd
[13:07:32] <RikusW> I've written Qt based programming software for atmel tools
[13:07:39] <RikusW> it works with stk500 and my dragon
[13:07:51] <RikusW> I think ISP mode with the stk600 should work
[13:08:08] <RikusW> since isp on the avrisp mkii works and its a similar protocol
[13:08:23] <RikusW> want to try it ?
[13:08:40] <haydenmuhl> Sure, but I don't have the board in front of me. I'm mostly looking for ideas.
[13:08:50] <haydenmuhl> I'll have to wait until I get home to do anything.
[13:09:35] <RikusW> http://sites.google.com/site/megau2s/home ---- go to software --- RavrProg
[13:09:35] <RikusW> you'll need the Qt dev files
[13:09:35] <RikusW> and libusb
[13:09:46] <RikusW> it compiles easily on linux
[13:09:53] <RikusW> just qmake and make
[13:10:17] <RikusW> and then put a symlink in /usr/lib to the dll
[13:10:39] <haydenmuhl> OK. I'm bookmarking this for when I get home.
[13:10:56] <RikusW> It might help a bit
[13:11:01] <haydenmuhl> Thanks.
[13:11:35] <RikusW> I didn't implement any of the stk600 specifics like routingboard or topboard stuff, neither did avrdude afaik
[13:11:55] <RikusW> do you have any other avr programmers ?
[13:13:25] <RikusW> just note, its alpha software ;)
[13:13:49] <asteve> i need to get a programmer
[13:14:37] <RikusW> asteve: you don't have any avr programmer ?!
[13:14:53] <asteve> RikusW: not at the moment, i haven't touched an AVR by itself in over a year
[13:15:58] <RikusW> I have a dragon, and then ofcourse my own programmer, about 100 of them ;)
[13:16:17] <asteve> send one my way? :)
[13:16:20] <asteve> i'd like a debugger with it
[13:16:25] <RikusW> basically a stk500 and jtagice mki
[13:16:52] <RikusW> I modified the jtagice a bit to support programming newer avr's too
[13:17:23] <RikusW> seems AS4 somehow supports it... but not debugging on the new ones (seems like a AS4 limit :(
[13:20:10] <RikusW> asteve: vectory bought one, on the link above you can see what it looks like
[13:20:49] <RikusW> tom's programmer got level translators builtin, mine don't
[13:21:04] <asteve> link above?
[13:21:21] <RikusW> http://sites.google.com/site/megau2s/home
[13:46:05] <abcminiuser> exDM69, you around?
[13:50:08] <RikusW> abcminiuser: that makes me think of a CDC problem I once had, I removed some of the CDC descriptors and it still worked on XP but no on Linux....
[13:50:26] <abcminiuser> RikusW, context?
[13:50:43] <RikusW> usb decriptors ;)
[13:51:23] <RikusW> documentation on how to properly do those is a bit sparse....
[13:51:30] <RikusW> especially HID
[13:51:52] <abcminiuser> Aj
[13:51:54] <abcminiuser> *Ah
[13:51:56] <RikusW> or maybe I just don't have the right books ? ;)
[13:51:56] <abcminiuser> Yes :P
[13:52:42] <RikusW> from usb.org specs alone its nearly impossible :( without some working example...
[13:53:53] <RikusW> I had a hard time getting the steering wheel HID descriptor right.....
[14:04:37] <Martyn> Hey all.
[14:04:56] <Martyn> I have 20,000 AVR AT90SC6464C chips
[14:05:16] <Martyn> which, naturally, I'd like to use... is there good, mature support for it in avr-gcc?
[14:06:33] <RikusW> sounds old
[14:06:40] <RikusW> how many pins ?
[14:06:40] <specing> 20000?
[14:06:43] <specing> you nuts?
[14:08:53] <Martyn> LQFP44
[14:09:06] <Casper> Martyn: I'm not sure, but I think it is not even supported
[14:09:20] <RikusW> AT90SC6464 series- Secure Microcontroller
[14:09:40] <Martyn> specing : Nuts? No. I just grab chips from surplus stacks, and recognized these as an AT90 ...
[14:09:44] <RikusW> how much ram and flash ?
[14:09:49] <Martyn> so, they are theoretically useful .. the full part number is :
[14:09:59] <Martyn> AT90SC6464C-USB-AL
[14:10:04] <Casper> btw, they are flash once devices
[14:10:26] <Martyn> They were made in 2007, all still under perfect vaccum seal, and all indicators still perfectly pink
[14:10:31] <j4cbo> "
[14:10:32] <j4cbo> Secure Microcontroller for Smart Cards"
[14:10:39] <Martyn> Sounds right.
[14:10:43] <Casper> Martyn: and still unsolderable
[14:10:52] <Martyn> Casper : Perfectly solderable.
[14:11:14] <Martyn> Casper : They just need a 24 hour bake, and then re-seal. No big deal at all.
[14:11:52] <Martyn> The real question for me is.. what kind of use can they be put to?
[14:11:56] <exDM69> abcminiuser: yea
[14:12:27] <exDM69> abcminiuser: just doing some LUFA hacking :)
[14:12:40] <RikusW> Martyn: you'll probably need a similar avr with flash to develop your code on, then put it on the OTP chips
[14:12:47] <Casper> Martyn: I hope you like to solder and desolder :D
[14:12:49] <abcminiuser> exDM69, got your email, just read through it
[14:12:51] <abcminiuser> Hrm
[14:13:04] <Casper> RikusW: afaik, there is none for those
[14:13:04] <abcminiuser> Got traces of the working + non-working versions after enumeration until the reset?
[14:13:18] <Casper> I think those were mainly used in xbox1 controllers
[14:13:31] <Martyn> Does "SC" always mean OTP?
[14:13:42] <RikusW> the C does afaik
[14:13:53] <Martyn> The datasheet seems to indicate 64K Flash
[14:14:01] <Martyn> No, the C indicates that it has a Crypto Accel
[14:14:16] <RikusW> even for PIC like PIC16C77 vs PIC16F877 which is flash based
[14:14:20] <Martyn> the question is does the S mean PROM, or "secure erase"?
[14:14:43] <exDM69> abcminiuser: not at hand but I can get them later
[14:14:53] <exDM69> abcminiuser: I have one failed trace
[14:14:53] <RikusW> does its datasheet say it is program once ?
[14:14:57] <abcminiuser> exDM69, no rush at all, I've got plenty to do :(
[14:15:02] <abcminiuser> exDM69, that'll do in the meantime
[14:15:15] <Casper> ah AH!
[14:15:19] <Casper> look like I was wrong
[14:15:20] <Martyn> RikusW : I can't even find the datasheet anymore on Atmel's site.. I'm searching the net for a cached copy of one
[14:15:26] <Casper> AT90SC6464C
[14:15:37] <Casper> Secure Microcontroller for Smart Cards
[14:15:53] <Martyn> "Smart Card. Plastic Package" .. that jibes with what's on the inventory sheet at least
[14:16:05] <Martyn> Casper : Do you know where the full datasheet is?
[14:16:13] <Casper> 64k eeprom 500k write cycles, 64k flash 10k write cycle, 3k ram
[14:16:32] <Martyn> Wow! That's a pretty decent little chip then.. and it's still an AVR
[14:16:52] <Martyn> but the AT90 isn't a mega... does that mean that the avr-gcc toolchain won't work?
[14:17:20] <Casper> there is no indication that avr-libc support it
[14:17:33] <Casper> couln't find any "6464" in the interrupt vector page
[14:17:44] <RikusW> you might get away with compiling for a similar AVR
[14:18:03] <exDM69> abcminiuser: sent it to you by e-mail
[14:18:11] <Casper> but can't seems to find the full datasheet
[14:18:15] <RikusW> in particular with the same supported instructions
[14:19:19] <Martyn> Given that this is supposed to be a "secure" chip, but now obsolete.. I wonder if I can get the datasheet from Atmel now
[14:19:47] <exDM69> abcminiuser: tell me whether you got it. I have to be going soon
[14:20:00] <RikusW> try avr@atmel.com ?
[14:20:33] <abcminiuser> exDM69, got it
[14:20:59] <abcminiuser> IIRC we don't make secure AVRs anymore
[14:21:41] <Martyn> abcminiuser : So I am gathering .. but is the full datasheet now/still available?
[14:21:55] <Martyn> Considering I have 20,000 of these chips.. might as well find something useful to do with them :)
[14:22:13] <Martyn> and it would be nice to know what limitations or cool abilities they have
[14:22:27] <abcminiuser> Martyn, I don't have a copy, but we can possibly source one for you
[14:22:36] <Martyn> that would be really good :)
[14:22:37] <abcminiuser> *Probably*, since they were under-NDA chips
[14:22:40] <exDM69> abcminiuser: great. I hope you can make some sense into it. My hunch is that it's something pretty simple
[14:24:17] <RikusW> Casper: what was the doc number on that at90sc datasheet of yours ?
[14:25:24] <Martyn> I found a summary datasheet for a similar part :
http://datasheet.seekic.com/PdfFile/AT9/AT90SC9618RT_AT90USB1287_AT90SC9608RC_AT.pdf
[14:26:08] <Martyn> I did figure out that the 64/64 denotes the ROM/EEPROM memory ..
[14:27:44] <Martyn> And the EEPROM has 128 bytes of OTP .. handy
[14:27:54] <Martyn> so they can be programmed with padded ID's..
[14:28:53] <Martyn> Definitely useful for what it was designed for -- to be a challenge/response USB key .. but if it has peripheral IO pins, it could also make for a nice little controller for other projects
[14:28:57] <abcminiuser> It's a chip normally/used to be under NDA
[14:29:03] <j4cbo> who at atmel could i ask for a datasheet clarification, anyway? avr@atmel.com?
[14:29:07] <abcminiuser> So I'm not sure if the datsheet is releasable
[14:29:21] <abcminiuser> j4cbo, yes, then we can escallate to the IC teams responsible for them
[14:29:38] <Martyn> abcminiuser : I'll sign an NDA if needed. Considering the quantity I've found, it would be a pity to just waste them
[14:30:04] <Martyn> It's not often that 20,000+ chips just drop into my lap :)
[14:30:04] <abcminiuser> Martyn, where the heck did you find a canoe full of them anyway?
[14:30:44] <Martyn> Guard ID used to make a product called the ID Vault. They stopped producing it, and were throwing the chips away .. I salvaged the surplus
[14:31:01] <Martyn> Because when I saw "AT90" I knew it was some kind of useful avr
[14:31:09] <RikusW> ask them for the datasheets ?
[14:31:32] <Martyn> Already did. The company was sold, but they didn't have any datasheets in the dock
[14:32:02] <tosmo> when extracting the high byte from a uint16_t like "uint8_t x = y >> 8", does avr-gcc just assign the high byte or will it actually generate clumsy 16bit shifting code?
[14:32:52] <RikusW> tosmo: check the generated asm ? optimization level will have an effect on this
[14:33:01] <Martyn> http://www.buildingon.com/Download/CryptoCombo/Technical%20datasheet%20CryptoCombo%202048%20BuildingOn.pdf (Yep! Look at the products made with this thing .. very cool!)
[14:34:11] <abcminiuser> Martyn, damn, if they gave the datasheet to you we could have sued them and raised our stock price (kidding)
[14:34:47] <RikusW> rue_house: all the datasheets moved to
http://www.atmel.com/Images/doc1187.pdf seems your page needs fixing ?
[14:35:44] <j4cbo> tosmo: last i checked, it would just assign the high byte
[14:36:49] <tosmo> thanks. anyway, how do i get the asm output from avr-gcc? i'll probably run into some more of such questions
[14:37:20] <abcminiuser> Tom_itx, it should just grab the upper byte if optimisation is enabled
[14:39:05] <RikusW> tosmo: gcc --help
[14:39:20] <RikusW> gcc -c
[14:39:31] <RikusW> or you can use avr-objdump
[14:40:21] <Martyn> Found the summary datasheet for the 6464C -- >
http://www.datasheetarchive.com/dl/Datasheets-5/DSA-80761.pdf
[14:40:28] <Martyn> Hard enough to find
[14:40:56] <RikusW> the official atmel one ?
[14:41:09] <RikusW> what is the number on the first page in the lower right corner ?
[14:41:20] <tosmo> just found avr-gcc -S
[14:42:43] <RikusW> Martyn ->
http://www.atmel.com/Images/docXXXX.pdf try placing that number without the S at the XXXX's
[14:42:52] <RikusW> maybe you might get lucky ;)
[14:53:54] <RikusW> fixed up my datasheet list :)
http://sites.google.com/site/megau2s/home/datasheets
[14:59:11] <izua> RikusW: do you have all those in a tar/zip?
[14:59:57] <RikusW> only the links to atmel.com
[15:00:19] <RikusW> fixed it
[15:00:26] <RikusW> atmel moved stuff around
[15:21:50] <Martyn> So, I managed to find the IDVault hardware, and thanks to it, I now have a partial pinout
[15:21:55] <Martyn> I found XTAL1/2
[15:22:04] <Martyn> I know where the ISP pins are
[15:22:11] <Martyn> and I think I found the IO pins
[15:22:30] <Martyn> I also know where the USB data pins are
[15:22:53] <Martyn> I'll need to desolder the chip to figure out VCC and GND
[15:23:12] <RikusW> hot air ?
[15:23:41] <RikusW> have a look at the mega32u4 pinout, maybe its the same ?
[15:24:13] <Martyn> For a TQFP44?
[15:24:23] <RikusW> the u4 got usb data on pins 3+4
[15:24:29] <RikusW> yes TQFP44
[15:24:30] <Martyn> Does Atmel generally go for full pin compatibility between AT90 and Mega32?
[15:24:48] <RikusW> you might be lucky
[15:25:05] <RikusW> XT2 - 16 and XT1 - 17
[15:25:38] <RikusW> so is it on the same pins over there ? ;)
[15:27:16] <Martyn> Nope
[15:27:35] <Martyn> it's on 25 and 27
[15:27:39] <Martyn> going by the corner mark
[15:28:28] <RikusW> beg atmel for the datasheet :-|
[15:28:50] <asteve> datasheet more like data cheat!
[16:54:41] <ThersiT> Does anyone here use Eclipse for AVR development?
[16:55:50] <ThersiT> I'm having a real hard time just trying to include a static library in my project.
[16:56:23] <OndraSter_> Eclipse :X
[16:56:44] <OndraSter_> the second worst programming "app", right after VIM
[16:56:47] <OndraSter_> (or just VI) :P
[16:57:04] <OndraSter_> static library is compiled or as source?
[16:57:34] <ThersiT> I downloaded source from the web
[16:57:54] <OndraSter_> C or ASM?
[16:58:00] <ThersiT> C
[16:58:06] <OndraSter_> (bad question.. I am the last person on the earth using assembler lol)
[16:58:53] <OndraSter_> can't you just include the header and add the lib file into the lib path of eclipse?
[16:59:06] <OndraSter_> I have got no idea how does Eclipse feel about AVR... luckily!
[16:59:11] <ThersiT> Is there a better IDE that runs on Linux. Eclipse is kinda getting on my nerves.
[16:59:30] <OndraSter_> vmware + windows 7 :P
[16:59:37] <OndraSter_> and avrstudio
[16:59:39] <ThersiT> heh heh
[17:00:30] <ThersiT> Yea that's what I tried first but it won't resolve any of the functions.
[17:01:01] <OndraSter_> during tool tipping or during compilation?
[17:03:37] <OndraSter_> anyway, it is late here, gotta run otherwise I won't get up
[17:03:38] <OndraSter_> gn
[17:04:01] <ThersiT> Thanx for trying.
[17:04:04] <ThersiT> gn
[21:43:25] <gkwhc> Hey guys, after a day long of research, I have finally found a p chan mosfet (
http://www.vishay.com/docs/74638/si1905bd.pdf) that seems suitable for switching SD card power in a 3v3 system. it seems like the mosfet will fully turn off whenever I apply 2.7V to the gate, and fully turn on when i apply 0.33v. can anyone please kindly confirm this, as i am new to choosing mosfets?
[21:44:01] <Valen> they generally have a linear region in between those
[21:44:15] <Valen> i havent read the datasheet though but it sounds in the ball park
[21:44:20] <Valen> if its a 3.3v fet
[21:46:21] <gkwhc> Valen: the front page says it turns on at -1.8V with 1.2ohms
[21:46:44] <gkwhc> which is even better when applied to 3.3v systems, i believe
[21:46:55] <Valen> 1.2 ohms is a fair bit
[21:47:04] <Valen> whats its rdson?
[21:47:47] <gkwhc> 1.2ohms at -1.8V
[21:49:17] <gkwhc> meaning if i apply anything that >(3.3v-1.8v) the pchan mosfet will turn off
[21:49:45] <gkwhc> right?
[21:51:18] <_0ddity> is this to protect the sd card?
[21:52:35] <gkwhc> _0ddity: its to switch power to the SD card
[22:01:07] <Casper> it's funny that on BJT pnp win, while on fet the N win..
[22:10:06] <ziph> gkwhc: Looks fine to me.
[22:10:13] <ziph> gkwhc: How much current will the SD card suck?
[22:19:41] <gkwhc> ziph: worst case scenario, 100mA
[22:21:17] <ziph> Any VGS above about 1.2V should be fine then.
[22:22:29] <gkwhc> ziph: i see. so then its correct that i was saying "if i apply anything that >(3.3v-1.8v) the pchan mosfet will turn off"?
[22:24:01] <ziph> If you're using it as a high side switch pulling it 1.2V below the rail will turn it on.
[22:24:18] <ziph> The more the better though.
[22:26:57] <gkwhc> i see
[22:27:17] <gkwhc> cool thanks!
[22:28:48] <gkwhc> ziph: by the way, voltage drop doesnt seem like that big of a problem, eh
[22:29:12] <ziph> Not at 100mA, no.
[22:29:38] <ziph> It's < 0.2V for almost any VGS
[22:30:51] <gkwhc> gotchya
[23:31:39] <ome> Can you have a class container that compiles under avr-gcc ?
[23:32:04] <ome> I mean, has someone been able to do ?
[23:39:21] <Casper> ome: I doubt you want to use class
[23:39:31] <Casper> class is C++, and that is not recommanded at all on avr
[23:39:43] <Casper> due to the restrictions of storage and ram
[23:40:43] <ome> Cheers Casper, but I think I have got something running at the moment and I will see how it goes.
[23:40:55] <ome> OccupyWallStreet: Cheers for the headups.
