|
the new XMEGA avrs are starting to be stocked on digikey 
|
#
?
Aug 31, 2009 15:44
|
|
|
|
| # ? May 22, 2024 06:47 |
|
|
Oh cool so Atmel finally caught up to the PIC24/dsPIC series.
|
|
#
?
Aug 31, 2009 17:03
|
|
|
I don't think they're trying to compete with DSP-MCU hybrids like the dspics. Most people who are serious about DSP would just go for an FPGA or blackfin anyways. I'm excited about it because it has incredible potential for use in system control and monitoring. The combination of dual 2msps ADCs, dual 1msps DACs, four comparators, the ridiculous waveform synthesis hardware, and the event channel system means that it will be able to react to analog stimulus incredibly fast in ways that are pretty much unprecedented. The only thing it really lacks is a true 16 bit architecture.
|
|
#
?
Aug 31, 2009 17:53
|
|
|
I was just making a jab at the fact that the XMEGA's feature list looks pretty much exactly like the list of features for the PIC24 and its derivatives. I wasn't really trying to start an argument or be offensive though. I don't think that the dsPICs are intended to compete with more powerful dedicated DSPs, they're meant for applications that you would normally use microcontrollers for but would benefit from the DSP core and analog peripherals. For example Microchip provides, among others, libraries for speech recognition, sound codecs and software modems. Maybe you want a control system that can take voice commands, or play sounds, or communicate via a phone line. Why use a proper DSP or extra hardware for that when you can use a cheap all-in-one microcontroller for it? Edit: I'm working on a PCM WAV sound player that uses a dsPIC33FJ128GP802 (holy poo poo that's a mouthful, why did they abandon the PICxxAxxxx naming scheme?) which has a built-in 16-bit 100kHz dual-channel audio DAC. This is my first foray into anything DSP related but I imagine that the DSP core will help when I get around to writing the code to upsample lower quality sound to the 48kHz that I am running the DAC at. The cool thing is that everything the design needs is built right into the microcontroller except the SD card, audio amplifier, and the DAC crystal. If I used SMT components the design could be amazingly tiny but I'm not that good yet. BattleMaster fucked around with this message at 18:55 on Aug 31, 2009 |
|
#
?
Aug 31, 2009 18:19
|
|
|
BattleMaster posted:The cool thing is that everything the design needs is built right into the microcontroller except the SD card, audio amplifier, and the DAC crystal. If I used SMT components the design could be amazingly tiny but I'm not that good yet. SMT is easy. Tin pads beforehand. Discrete components: Hold down with tweezers, solder the 2 or 3 terminals in succession. QFP/TSSOP: Hold down with tweezers, tack down opposing corners so it stays lined up, solder the rest of the pins. Edit: you can often do several pins at once, especially if you are using solder paste. TQFN and the like are a bit trickier but can be handled with solder paste and a skillet or hotplate or some very careful hand-soldering (like above, but more careful). Test with multimeter if there is any doubt about open connections, remove shorts with solder braid and/or dental pick. People are much more afraid of SMT than they need to be. Mill Town fucked around with this message at 20:47 on Aug 31, 2009 |
|
#
?
Aug 31, 2009 20:45
|
|
|
I just won an auction for 18 pristine Russian nixie tubes for only $34 shipped. These are the type that face upward from their socket, rather than at a right angle, so I'll be mounting them in a panel to make a nixie clock.  Updates and pictures hopefully to follow soon...although I do have to wait on them to get here from Russia, bummer.
|
|
#
?
Aug 31, 2009 21:43
|
|
|
The DSPIC math libraries are loving terrible. The actual DSP ones are fine (though missing some functionality), but the fixed point math ones are broken as hell and they don't even care. Come to think of it the PID algorithm in the DSP library is also broken.
|
|
#
?
Sep 1, 2009 04:04
|
|
|
After some poking around and looking at various designs, I think I'm going to go with this solution for my clock: http://www.allspectrum.com/store/pr...IXIE-CLOCK-CHIP It's a pre-programmed microcontroller; just add the driver chips and not too many other parts besides, and you have a clock! I wonder how long it's going to take for those tubes to get here from Russia...
|
|
#
?
Sep 2, 2009 13:53
|
|
|
Hey I've got a question for you guys, I've got some solar panels that are supposed to be used for a car battery, 12V. Now what I'd like to do it attach them to my electric bike. The power adapter for it says it outputs +24Vs whatever that means. Could I just hook them up to my battery? Or would there be a problem with the voltage difference? I was thinking about getting another pair of solar panels and hooking them up in series or am I totally misunderstanding how this all works?
|
|
#
?
Sep 2, 2009 20:10
|
|
|
Shazzner posted:Hey I've got a question for you guys, I've got some solar panels that are supposed to be used for a car battery, 12V. There would be a problem. Your battery is probably 24V. Two panels in series would probably work OK.
|
|
#
?
Sep 3, 2009 02:35
|
|
|
Shazzner posted:Hey I've got a question for you guys, I've got some solar panels that are supposed to be used for a car battery, 12V. It would work to go in series (24 Volts to 24 Volts). Solar panels are kinda weird though, you generally have to match them to get good power output. Putting them in series would give you more power, but perhaps not double the power. You have the right idea, and the voltage would work out, but don't expect half the charge time. To do that you'll need strange mystical devices like SMPS.
|
|
#
?
Sep 14, 2009 03:02
|
|
|
In an obsessive rampage I've rigged up an opamp-based headphone amp, but I'm a little less than happy with the results. It hums a lot, and has problems with filtering and some distortion issues even (ARGH!). So I'm going back to the drawing board a bit. One thing I'm going to do is treat inputs from RCA jacks as if they are differential inputs (I know they are not, but I think it will help with some of these darn ground loop issues). Anyone see issues here? Only thing I can think of is common-mode issues. I'd like to DC couple this thing to the input source though. Putting caps between the two means I either need big old caps (3uF and above...I'm a little sketched out using such large caps) or larger resistors (more noise). I want to reach for 90 or 100 dB SNR just as a personal goal, so I want to avoid large value resistors if possible. Another issue is grounding in general. I would like to be able to use a ground and a single voltage for power (like from a battery or a cheap power supply), so that necessitates the use of virtual grounds. I've been using the cheap resistor/capacitor divider network like the Chu Moy uses, but I don't really like it much, it gets thrown off too easy and seems to not like high currents. My options are: 7805/7905 combo network, resistor voltage divider into an opamp or buffer, or TLE2426 into an opamp or buffer. I'm using some pretty beefy high-current output opamps that pack some serious grunt (~280ma RMS), so I don't think I'll be reaching for buffers anytime soon. What types of solutions should I be reaching for here? My goals are small size, 18V power, and really good sound. Battery power is ideal, but not really a primary goal.
|
|
#
?
Sep 14, 2009 03:16
|
|
|
I'm totally new to this whole electronics thing, but I'd really like to get into it. I've taken only a single EE class at my university, so I'm on the level of v=ir, and that's about it. To educate myself. I've got a project in mind, but my research so far has shown that it's going to be pretty difficult... which says to me that by the time I'm done with the project, I'll know a lot  I'm planning on breaking it up into parts though to learn each individual piece well before integrating it into the next piece.What I would eventually like to have is an RC boat with a camera dangling off the bottom, and I'd like to be able to control this/view the camera's output with my laptop from the shore. I'm not going to be any more than, say, 10 meters away from my boat, and I'll have line of sight to it. The idea is to be able to see the bottom of this really disgusting, somewhat shallow pond that frisbee golf disks fall into. It sounded like a simple process, but my research so far has shown that I'm a goddamn idiot for thinking that. That doesn't deter me though, and I want to learn this stuff. To break this up, I've ordered an Arduino so I can just begin messing around with microcontrollers. Depending on what I get out of that first part, I'll likely try to integrate the Arduino into an RC car (which, if I end up anywhere near my final idea, is pretty much what I'll have to do anyway). The next two parts are where I'll need some serious guidance: the wireless transmission and the video feed. From my research, it looks like I'm going to have a hell of a time transmitting video wirelessly, let alone getting it into a computer. From what I can tell, the serial interface on the Arduino maxes out at 115200 baud. If I'm using a 0.3MP CMOS camera, I'd be hard pressed to get any sort of framerate out of that connection (~2Mbit/frame... 640x480x8bit monochrome). Even at the lovely resolution of 176x144 that my cellphone camera produces for video, I'd be looking at less than a frame per second. So, if I break that part of the project down, I'm just looking to create my own live-video webcam. How would you even handle the datarate issue there? Compression? Is there some way to get a wider pipe out of the Arduino? Will I need a beefier setup for what I'm thinking about?
|
|
#
?
Sep 14, 2009 21:28
|
|
|
Arduinos board have a 16MHz crystal in them when you buy them, and they're only rated to about 20MHz. There are way faster microcontrollers out there. Here's a handy guide, if you don't mind using PICs. If you use an external clock, you can go up to 120MHz. Atmel doesn't have a comprehensive list like that, unfortunately, but I think they're generally limited to 32MHz.
|
|
#
?
Sep 15, 2009 04:11
|
|
|
There are some ready-made solutions, but they tend to be expensive or bulky. How big is this RC boat? A really, really easy solution might be to use a Netbook (Nano-ITX board might work too) and a Webcam, and beam the signal over 802.11. Heck, hook up the netbook to an Arduino and write a nice control program. Going much smaller will be hard, but it's not impossible, especially if you don't mind craptacular image quality. You can even beam the video signal as analog, which might be much easier (don't quote me on that).
|
|
#
?
Sep 15, 2009 06:10
|
|
|
ante posted:Arduinos board have a 16MHz crystal in them when you buy them, and they're only rated to about 20MHz. Would a faster clock be enough to produce a faster serial connection? Or is there some limitation imposed on the computer's end for receiving serial data? Since I'm looking at using my laptop, I'd be using some sort of USB->RS232 thing. clredwolf posted:There are some ready-made solutions, but they tend to be expensive or bulky. How big is this RC boat? I haven't gotten as far as the boat yet, but probably not too large. I'm thinking the stereotypical RC boat, but I haven't looked into it yet. I thought about that laptop solution, but my goal is more learning electronics rather than actually looking at the bottom of the pond  though it does make a nice goal.I've thought about beaming it as analog and then using some sort of analog->digital converter thing, but the big issue I've bumped up against was connecting into the computer to deliver the video. If a faster clock takes care of that data rate and exceeds the Arduino's serial rate restriction, then that helps to clear that issue up. If anyone has any good resources on beaming analog video between devices, that would be really helpful, too.
|
|
#
?
Sep 15, 2009 07:25
|
|
|
You probably want a separate 900 MHz/2.4 Ghz analogue video transmitter, like these http://www.microcameras.com/2400_video_transmitters.htm If you have to go digital, bluetooth is technically feasible (version 2.0 can theoretically get 3 Mbit/s), but honestly video streaming is a bitch.
|
|
#
?
Sep 15, 2009 09:20
|
|
|
Exitlights posted:Would a faster clock be enough to produce a faster serial connection? Or is there some limitation imposed on the computer's end for receiving serial data? Since I'm looking at using my laptop, I'd be using some sort of USB->RS232 thing. The original RS232 standard had an upper limit of around 20 kbps, but that little dongle you're using should go up to 1.2Mbps, according to a datasheet I found. (  )clredwolf posted:There are some ready-made solutions, but they tend to be expensive or bulky. How big is this RC boat? If you're using 802.11 with Arduino, you'll probably be using the XBee module, which is pretty slow, I hear.
|
|
#
?
Sep 16, 2009 01:12
|
|
|
ante posted:You might have to write your own handshake protocol, but serial connections are very simple. Yeah, I was thinking that I might just have to do that. How easy would it be to take advantage of full speed USB and transmit the data over that, sans serial converter? That little dongle turns it into a serial connection, but could I just make my own USB connection and wire the data that way? I can't imagine how much of a pain in the rear end it would be to communicate over USB, but that would give me a lot of speed. ante posted:If you're using 802.11 with Arduino, you'll probably be using the XBee module, which is pretty slow, I hear. Probably still way exceeding my own grasp here, but there are plenty of 802.11b or g radios that aren't too pricey. I would have to drive that myself somehow... I guess it's all doable somehow, but heavy emphasis on my reach exceeding my grasp.
|
|
#
?
Sep 16, 2009 06:18
|
|
|
I'm pretty sure that virtual COM port over full-speed USB is faster and more reliable than real RS232 could ever hope to be. It gets 12mbits/sec, but even after you factor in time sharing with other devices and handshaking and all that crap it should still be quite zippy. Microchip makes 8-bit PICs with full-speed USB peripherals. I recommend going that way if you want to use USB because PICs are dirt cheap, easy to use, and there are a lot of parts to choose from depending on what the rest of your project requires. The USB hardware is easy to use but Microchip provides a framework that makes it even easier to use if you don't have the time or desire to learn how it works. In fact, one of the examples included with the framework is for an emulated COM port so you don't even have to do much work yourself. If you just plan on using it as an intermediary between the computer and some kind of wireless you can probably just use the classic PIC18F4550 (or 2550 if you want a lower pincount), but the list of PICs with USB is pretty big with lots of combinations of features, memory, and pin coutn available.
|
|
#
?
Sep 16, 2009 21:05
|
|
|
Am I just really confused here, what exactly does USB have to do with wireless video?
|
|
#
?
Sep 17, 2009 07:33
|
|
|
catbread.jpg posted:Am I just really confused here, what exactly does USB have to do with wireless video? BattleMaster posted:I'm pretty sure that virtual COM port over full-speed USB is faster and more reliable than real RS232 could ever hope to be. It gets 12mbits/sec, but even after you factor in time sharing with other devices and handshaking and all that crap it should still be quite zippy.
|
|
#
?
Sep 17, 2009 15:49
|
|
|
Exitlights posted:I'm just making sure that when I do get a wireless connection going, I'll have a fast enough connection between whatever receives the video and my computer to be able to display the video in real-time. The COM port functionality provided by the Arduino, from what I can tell, maxes out at 115200 baud, which isn't enough to communicate video to my computer with any sort of framerate. Before I get to the wireless transmission part, I'd just like to interface my computer directly with a CMOS camera in real-time, ignoring the wireless part until I can at least get the camera to work. No, the Arduino UART can definitely exceed those speeds, although you may have to set custom clock divisors and perform other magic. You just need a piece of equipment on the other end that can also operate that fast... Edit: yeah, if you look at page 199 of the ATmega168 datasheet (the microcontroller used in the Arduino), you will see that the maximum baud rate at a 20MHz clock speed is 2.5Mbps. At that speed you will be very limited in how much processing you can do before you have to shoot each byte out the port, of course, but you should be able to find a good tradeoff between speed and program complexity. Mill Town fucked around with this message at 22:42 on Sep 17, 2009 |
|
#
?
Sep 17, 2009 22:32
|
|
|
The cool thing about the Microchip USB implementation is that it uses DMA to keep the peripheral fed while you do other stuff.
|
|
#
?
Sep 18, 2009 00:20
|
|
|
BattleMaster posted:The cool thing about the Microchip USB implementation is that it uses DMA to keep the peripheral fed while you do other stuff. That is cool but I still don't know why you would run a USB cable to a boat?
|
|
#
?
Sep 18, 2009 03:33
|
|
|
Mill Town posted:That is cool but I still don't know why you would run a USB cable to a boat? Pretty much for the same reason you'd run an RS232 cable to it, because you didn't read his posts. He needs to connect a wireless transceiver of some sort to a computer so he can control the boat using it. Edit: Though in a hypothetical situation where you actually need to run a really long cable to a boat USB would win because the twisted pair differential signal is way more resistant to noise and the protocol has error correction built in BattleMaster fucked around with this message at 04:34 on Sep 18, 2009 |
|
#
?
Sep 18, 2009 04:27
|
|
|
Except that the USB spec only provides for cables up to 5 metres. For longer distances you'd want to go ethernet. What resolution camera are you thinking of Exitlights? This is a pretty important variable. Most of these cameras use an I2C bus for control and a parallel 8-bit data bus. They also need to be clocked at a rather high rate (15-20 MHz). Crucially, the frame data must be streamed from them without interruption. You have basically no control over how fast you want to get the data out. To do this requires very low latency interrupts and a processor with a pretty high throughput. DMA would help, but I don't know if that is possible with a parallel interface. I've done it with an ARM7, I've never heard of it being done with an AVR. I would still recommend analogue video if you are interested in getting something to work any time soon, unless you just want to tinker/learn.
|
|
#
?
Sep 18, 2009 08:33
|
|
|
Because I'm a total whore for Microchip I'm going to have to mention that the 16-bit PICs (PIC24/dsPIC) have a DMA-capable parallel port and can definitely be clocked high enough to keep up with that. I don't think it could keep up with compressing the video though, if you want to do that. You can forget about it with the 8-bit ones, though, because the only peripherals with DMA are the USB module and the SPI module (only on some newer parts) and they only get 10 million instructions per second anyways. There probably isn't anything wrong with using them for a wireless to USB bridge like we were talking about though. BattleMaster fucked around with this message at 11:46 on Sep 18, 2009 |
|
#
?
Sep 18, 2009 11:37
|
|
|
BattleMaster posted:Because I'm a total whore for Microchip I'm going to have to mention that the 16-bit PICs (PIC24/dsPIC) have a DMA-capable parallel port I'll definitely remember that, I like the dsPIC well enough (except for the libraries....) I wonder about the PIC32, I have a few samples of those lying around.
|
|
#
?
Sep 18, 2009 12:01
|
|
|
BattleMaster posted:Pretty much for the same reason you'd run an RS232 cable to it, because you didn't read his posts. He needs to connect a wireless transceiver of some sort to a computer so he can control the boat using it. I did read his posts. I thought he wanted to have the microcontroller on the boat, grabbing images from a camera, and sending the to a zigbee or similar wireless module. Then there'd be another zigbee or w/e on the other end connected directly to the computer, not another microcontroller.
|
|
#
?
Sep 18, 2009 13:10
|
|
|
catbread.jpg posted:I'll definitely remember that, I like the dsPIC well enough (except for the libraries....) I wonder about the PIC32, I have a few samples of those lying around. Yeah, the 16-bit PICs support DMA with their parallel master port, and it looks like the PIC32 series does as well. I took a look at a datasheet for one and it says that any peripheral that generates an interrupt can be used with DMA. Edit: None of the PICs support DMA with GPIO BattleMaster fucked around with this message at 20:05 on Sep 18, 2009 |
|
#
?
Sep 18, 2009 18:15
|
|
|
I've got a completely stripped out Datsun 510, and I have this desire to run bar-graph LED gauges for every possible sensory input that I can think of -- standard stuff like fuel-mix from an O2 sensor, fuel pressure, oil pressure, engine temp, system voltage, etc., and maybe some other misc. things like an accelerometer, altimeter, outside air temperature... basically, I want the inside of my car to have enough gauges and toggles to rival the inside of an airplane. For everything that's producing any amount of voltage, I feel like I can pattern off of a DIY fuel mix display. My confusion is in the fuel tank sending unit, which doesn't send voltage -- the sending unit reads 12ohms at full and 88ohms when empty. I know how to read the resistance with an ohm reader... but if I wanted to display the fuel level via a series of LEDs, how do I take the resistance and convert that into voltage I can send into an LED display driver? edit: aha. After a more careful look at ohm's law, I believe that because I have a constant 12-14 volts, and a known resistance range (22 to 88 ohms) on the fuel sending unit, what my bar-graph LED gauge should be reading is the current, which is a bit easier to figure out. Hooray for hours of researching instead of simply waiting for somebody to tell me the answer. jovial_cynic fucked around with this message at 17:02 on Sep 19, 2009 |
|
#
?
Sep 19, 2009 05:58
|
|
|
catbread.jpg posted:What resolution camera are you thinking of Exitlights? This is a pretty important variable. Most of these cameras use an I2C bus for control and a parallel 8-bit data bus. They also need to be clocked at a rather high rate (15-20 MHz). Crucially, the frame data must be streamed from them without interruption. You have basically no control over how fast you want to get the data out. To do this requires very low latency interrupts and a processor with a pretty high throughput. DMA would help, but I don't know if that is possible with a parallel interface. I am still keeping the analogue video in mind though, since it is asking a lot of a little microprocessor to sling pixels wirelessly in realtime. I'm probably going to attempt the CMOS first since I would like to be able to control one. I'll admit that I'm a little lost in your back and forth here though, so maybe you can clear a few things up. First, I wiki'd DMA, but could you explain its relationship and importance to the camera's parallel data interface? I'm also hazy on this discussion of interrupts in CPUs, but I need to look that one up a bit more I think... sorry, I'm sort of flailing around here, but I do appreciate all the help and input.
|
|
#
?
Sep 20, 2009 00:08
|
|
|
Direct memory access and interrupts are two features that can free up processing time so that the CPU can concentrate on other tasks. DMA: usually when you want to move data between memory and a peripheral you need to get the CPU to read the data from one and then write it to the other. That isn't so bad for moving small amounts of data periodically, but if a constant flow is required it can seriously bog the CPU down and prevent it from working on other things. DMA allows the peripheral to access memory completely independently of the CPU so that the CPU can do other things in the meantime. In the case of the parallel camera interface, the camera is making GBS threads out data so fast that the CPU would be bogged down trying to keep up with reading it all. Letting DMA handle it by moving the data into memory independent of the CPU would let the CPU spend more time working with the data instead of wasting all its time copying it. DMA can also maximize throughput through communications peripherals such as USB or serial ports by allowing the CPU to work on the next block of data while the peripheral is transmitting the previous block. By the time the peripheral is finished there will be another chunk of data waiting for it and the cycle can begin again. Interrupts: normally when you want to see if a peripheral has finished an operation (transmission of data, etc.) the CPU needs to poll it repeatedly until it reports that it is finished. If the peripheral takes a long time to complete then the CPU can waste a lot of time doing that. Interrupts allow a peripheral to inform the CPU that it needs intention, which causes the CPU to drop what it is doing and respond to it. Interrupts are also handy not just to save CPU time but to respond to certain events in a timely manner. For instance if you need to respond immediately to an I/O pin changine state, or a timer overflowing, or in the absense of DMA if you need to load a peripheral with new data as soon as it's finished transmitting. BattleMaster fucked around with this message at 02:35 on Sep 20, 2009 |
|
#
?
Sep 20, 2009 01:41
|
|
|
jovial_cynic posted:edit: aha. After a more careful look at ohm's law, I believe that because I have a constant 12-14 volts, and a known resistance range (22 to 88 ohms) on the fuel sending unit, what my bar-graph LED gauge should be reading is the current, which is a bit easier to figure out. Hooray for hours of researching instead of simply waiting for somebody to tell me the answer. You can also wire a close-tolerance sense resistor in series with your tank sensor and measure voltage across that.
|
|
#
?
Sep 20, 2009 20:02
|
|
|
BattleMaster posted:Direct memory access and interrupts are two features that can free up processing time so that the CPU can concentrate on other tasks. As far as using DMA for the camera, what would that look like? What I was envisioning pre-DMA was for the processor to accept the parallel input from the camera, serialize it, and send it through whatever wireless radio I had, and then use another processor on the other end with another radio, and transmit that on into the computer. Where do I insert DMA in this scenario? Is it for the receiving radio + processor to computer part? In real-time news, I got my Arduino yesterday, and began playing around with it today. The thing is easy as all hell to program, and I connected it to that RC car I'm testing everything with. I'm going to put together a little car-control program and let the car drive itself around a little bit under the control of the Arduino. I'm very excited now though, hopefully this project will move forward more quickly than I anticipated.
|
|
#
?
Sep 21, 2009 05:53
|
|
|
Exitlights posted:As far as using DMA for the camera, what would that look like? What I was envisioning pre-DMA was for the processor to accept the parallel input from the camera, serialize it, and send it through whatever wireless radio I had, and then use another processor on the other end with another radio, and transmit that on into the computer. Where do I insert DMA in this scenario? Is it for the receiving radio + processor to computer part? My DMA experience is on the MSP430 platform, but I'm sure its similar. With the MSP430 you setup DMA like any other peripheral. There are a few settings that determine what it does: Trigger source: DMA triggers on an interrupt (port state change, register change, etc). Changing this trigger changes the way it works. For instance, setting it to the UART-Tx_ready register means that when your UART is finished transmitting, DMA triggers. Triggers include ADC sampling, UART functionality, timer overflow, etc. Copy mode: DMA can do single memory location to single memory location (think ADC to UART), block of memory to single location (dumping an array out the uart, for instance), single location to block of memory (uart or ADC or something to a memory array), and block to block (say, the 7 ADC channels to an array in memory). Data sources: Self explanatory, addresses where the data comes from, according to the copy mode. Having these features assignable by code makes the DMA hardware very powerful and very flexible. While DMA is scooting data around where you need it, the CPU can be busy doing useful tasks. That said, I would consider keeping the control code and camera business separate. If you could find a camera that transmits data in analog or has its own built in digital radio, I would totally prefer that if I were you. Moving the video manually takes the project from doable and an awesome learning experience to "holy poo poo how can I keep that much data moving fffffffff"
|
|
#
?
Sep 21, 2009 07:54
|
|
|
Delta-Wye posted:My DMA experience is on the MSP430 platform, but I'm sure its similar. With the MSP430 you setup DMA like any other peripheral. There are a few settings that determine what it does: Delta-Wye posted:That said, I would consider keeping the control code and camera business separate. If you could find a camera that transmits data in analog or has its own built in digital radio, I would totally prefer that if I were you. Moving the video manually takes the project from doable and an awesome learning experience to "holy poo poo how can I keep that much data moving fffffffff" About the wireless control code, though, I think that's where I'm headed next. I'm starting to look into pretty basic wireless transmitters/receivers, and this pair from SparkFun seems to be the ticket (very cheap): http://www.sparkfun.com/commerce/product_info.php?products_id=8950 and http://www.sparkfun.com/commerce/product_info.php?products_id=8946 . There are some pretty robust-looking tutorials to get these things talking, the range seems decent, the bitrate is fine for telling the car how to move its servos. I think I know how to wire up the receiver, but I'm a little torn about the transmitter. I suppose I could get another Arduino or some cheaper variant and wire the receiver to that, and then connect THAT to my computer... or I could just get a USB to serial adapter. The transmitter has a single data pin, so it can't be that difficult, can it? But, it seems like just using another Arduino would be the easier way to go about it since I'm not sure how I would communicate out over that adapted port. If it's doable with the USB adapter though, that way is cheaper, and I think I would prefer that (and the experience of communicating over a serial port).
|
|
#
?
Sep 21, 2009 23:21
|
|
|
Don't buy another Arduino, once you're comfortable with it just start buying AVR microcontrollers directly from Atmel (edit: or Digikey or wherever you like to buy stuff). It will be exactly the same only you won't have to pay someone else to make a board for you. It's not like a crystal and voltage regulator and some capacitors is hard to assemble.
BattleMaster fucked around with this message at 01:06 on Sep 22, 2009 |
|
#
?
Sep 22, 2009 01:03
|
|
|
|
| # ? May 22, 2024 06:47 |
|
|
I fixed a problem I've been having with loading the config data into an FPGA via my ASIC. I watched the whole process on a logic analyzer and everything met the spec for the FPGA. What they didn't bother putting in the datasheet was that you have to toggle the clock line a few more times after the last bit has transferred for it to work. On a completely unrelated note, does anyone know where I can find details on the old NES hardware? I remember someone asking an NES question a while back.
|
|
#
?
Sep 22, 2009 02:25
|
|
