avatar

funkathustra

Member Since: October 18, 2009

Country: United States

  • It’s Linux, so of course you could do that – but since it’s an embedded platform, you’d typically just compile your custom app on your big, fast computer and deploy it with scp/sftp, debugging with gdb. Most IDEs make this operation seamless.

  • All modern ICs are 1.8V compliant, and generally have lower power consumption when operated at that voltage. It’s time to throw away your 1980s CD-series logic chips and move into this century.

  • It’s not a matter of speed, it’s a matter of interfacing. The processor doesn’t have a serial or parallel camera interface block on the chip, so you can’t interface an image sensor to it without an external FPGA/CPLD.

  • I totally don’t see any advantage of an SD card form-factor versus this. It’s about the same size, and what’s the difference between putting an SD connector on a board or a 70-pin Hirose, other than the fact that you get a ton more I/O with this option?

    I’m really glad they ditched the SD form factor.

  • While LiPo batteries have a voltage of roughly 2.5 to 4.2V, they drop off fairly quickly after they hit 3.5V, which means using this part in a 3.3V project will run the converter in the extremely inefficient (~75%) step-down region for most of the time. Consequently, I wouldn’t recommend using this part for 3.3V projects that are LiPo-powered.

    Most designs I’ve seen actually just use a buck converter to step-down the voltage – when the battery voltage drops below 3.3V, the converter will track the input voltage. This may seem counter-intuitive, since you don’t “squeeze out” all the juice in the battery – however, the increased efficiency of the buck solution means you get longer battery life overall.

    One article I read indicates at 300 mA output current, a buck converter got 9 more minutes of battery life than a buck-boost converter of similar configuration: http://www.eetimes.com/document.asp?doc_id=1273123&page_number=3

    Obviously, if you’re building something with ultracaps or other low-voltage stuff with UVLO disabled, this is a great part to use. And it definitely shines at 5V output – I’d just stay away from using it in a 3.3V configuration with LiPo batteries.

  • While LiPo batteries have a voltage of roughly 2.5 to 4.2V, they drop off fairly quickly after they hit 3.5V, which means using this part in a 3.3V project will run the converter in the extremely inefficient (~75%) step-down region for most of the time. Consequently, I wouldn’t recommend using this part for 3.3V projects that are LiPo-powered.

    Most designs I’ve seen actually just use a buck converter to step-down the voltage – when the battery voltage drops below 3.3V, the converter will track the input voltage. This may seem counter-intuitive, since you don’t “squeeze out” all the juice in the battery – however, the increased efficiency of the buck solution means you get longer battery life overall.

    One article I read indicates at 300 mA output current, a buck converter got 9 more minutes of battery life than a buck-boost converter of similar configuration: http://www.eetimes.com/document.asp?doc_id=1273123&page_number=3

    Obviously, if you’re building something with ultracaps or other low-voltage stuff with UVLO disabled, this is a great part to use. And it definitely shines at 5V output – I’d just stay away from using it in a 3.3V configuration with LiPo batteries.

  • Yay! Only 50% more expensive than from DigiKey!

  • The clock signal is obviously constant, but it’d have to be synchronized by looking at the sync pulse embedded in the component video signal. You’d also have to do some math somewhere to convert the color space of the component video signal (which is YPbPr) to RGB. And you’d still have to generate the HSYNC/VSYNC signals based on the front/back porch of the display.

    That’s a lot of work to go through to end up with something that’s not going to work nearly as well as an off-the-shelf 4.3" monitor with an analog input (something you can most certainly buy off eBay).

  • Total lost cause. Just buy a 4.3" LCD monitor with a composite input off eBay. This product is just a “dumb” LCD. You’ll need a controller configured specifically to drive this display with the proper front/back porch timings, pixel clock, and obviously resolution.

  • I’m sorry, but I can’t take this blog post seriously. SFE is great at lots of stuff – but stocking components isn’t one of them. Just look at microcontrollers. SFE only carries 16 different MCUs. No, I don’t mean 16 different families – I mean 16 different chips. 7 AVRs and 9 Microchip PICs. Where are my MSP430s? Where are my HC08s? 8051s? And what about ARM microcontrollers (which are cheaper/faster/better than any 8-bit MCU they carry)? No STM32s, no Freescale Kinetis, no NXP LPCs – not even Atmel ARMs.

    And look at the microcontrollers they do carry: almost all of them are ANCIENT. They’re selling old PIC16F877s and 18F2520s, for example. Who would possibly use those in new designs? Where are the LF series? Where are the newer ones, (something like the highly-useful, and very cheap PIC16LF1825)? I would expect DigiKey/Newark/Mouser to stock old MCUs for old production designs, but why does SFE bother?

    SparkFun seems to be oblivious to the heavy-duty war raging on between the 8-bit proprietary designs and the 32-bit ARMs. Microchip is rushing to keep pumping out cheaper/better/faster 8-bit MCUs (none of which SFE carries) while the Cortex-M0 is taking over the entry-level market, while 72 MHz Cortex-M3s (again, not stocked by SFE) are cheaper/better than Atmel AVRs.

    SparkFun’s stock makes me feel like I’m living in 1998.

    Please stop bragging about your component stock, and instead, brag about stuff you’re actually good at – like your awesome community and open-source development boards.

No public wish lists :(