|
http://www.youtube.com/watch?v=wy5AP81KJNs Almost. So close. (Also less likely to start a fire than my last project)
|
#
?
May 6, 2009 00:31
|
|
|
|
| # ? May 8, 2024 04:43 |
|
|
SnoPuppy posted:Glad to help. Ugh it's still having major issues. If I have it so that only the doc OR fco is the clock, running a test pattern into my fifos only, it seems to either do the same thing (digital errors every couple of samples; that's if I keep the PLL) or just not show anything at all (buffer never fills; that's if I remove the PLL, for both DCO and FCO). I'm bringing the board home with me to give me company while I get my wisdom teeth pulled, so I'll keep at it. Remote access ISE sucks though...
|
|
#
?
May 6, 2009 04:15
|
|
|
clredwolf posted:Ugh it's still having major issues. If I have it so that only the doc OR fco is the clock, running a test pattern into my fifos only, it seems to either do the same thing (digital errors every couple of samples; that's if I keep the PLL) or just not show anything at all (buffer never fills; that's if I remove the PLL, for both DCO and FCO). I'm bringing the board home with me to give me company while I get my wisdom teeth pulled, so I'll keep at it. Remote access ISE sucks though... What are your OFFSET IN constraints? They're a good idea for all digital designs, and absolutely mandatory for high speed work. Xilinx can make DDR constraints kind of a bitch - what version of ISE are you using? I heard they got better in 10.1. Rewriting the capture engine shouldn't take long - hour or two tops. All you should be doing is de-serializing a data stream and pushing the result into an async FIFO, to move to a slower clock domain. If you're meeting timing, the only option is that you're not constraining something correctly. I'm also assuming you have a test bench so that you can verify correct operation in simulation at least. If you don't, make one. Right now. Catching problems in simulation is about 1000 times easier than hardware. Although I'm strictly a VHDL guy, if you post your code somewhere, I might be able to take a look at it. No guarantee whether I can spot an error though.
|
|
#
?
May 6, 2009 04:36
|
|
|
BattleMaster posted:The only other thing I can think of is that perhaps optimizations are disabled when you do a debug build. I don't know specifically about AVR compilers or what-have-you but this is almost always true. When a compiler generates a debug build, optimizations are turned off for the sake of the debugger. Optimizations reorganize code in a way that makes it difficult or impossible for a debugging session to follow the source code precisely.
|
|
#
?
May 6, 2009 14:28
|
|
|
SnoPuppy posted:Accelerometer mounted on a deflecting beam? Analog Devices makes some pretty sensitive MEMS devices (0.025 deg of tilt per LSB). Plexiwatt posted:Instead of a pendulum, how about a thin, flexible rod with a high drag coefficient sail/panel on the end. Then put a strain gauge or four (cheap as gently caress and very accurate when calibrated) on the flexible rod. Needs very little I/O circuitry besides a bridge and A/D and has a pretty simple analytical model to boot. Both of these would work, but I'd like to avoid mounting electronics on the movable parts, since that would make assembly and manufacturing much more difficult. That's why I was leaning towards magnets or optics: the electronics can be mounted anywhere but still be effected by the pendulum/whatever's position. Hillridge posted:How do you plan to send the airflow data back to whatever is logging/processing it? This sounds like a good application for a Zigbee device.
|
|
#
?
May 6, 2009 15:35
|
|
|
BattleMaster posted:I went and had a look and it's actually a macro, so you're right. This page tells me that you can just skip using the macro altogether but it doesn't look like it would actually work differently either way. I had it "optimized" to compile for execution speed. The optimization configuration is just selecting what parameter you want it to be concerned about (memory size, execution timing, etc). I notice that when it handles interrupts with the library I'm using it takes something like 20 cycles to actually start the code in the interrupt routine. I can't imagine how much crap code is in there taking up time. What the hell is the point of an interrupt if it takes 20 clock cycles to happen? Also, on another note, Atmel's XMEGA series is officially now the duke nukem forever of microcontrollers. Delta-Wye posted:http://www.youtube.com/watch?v=wy5AP81KJNs ANIME AKBAR fucked around with this message at 15:44 on May 6, 2009 |
|
#
?
May 6, 2009 15:41
|
|
|
ANIME AKBAR posted:I notice that when it handles interrupts with the library I'm using it takes something like 20 cycles to actually start the code in the interrupt routine. I can't imagine how much crap code is in there taking up time. What the hell is the point of an interrupt if it takes 20 clock cycles to happen? It's probably pushing registers onto the stack so it doesn't gently caress with the normal flow of the program. After it's done the interrupt routine in pops them off the stack and back into where they used to be so the code it returns to is none the wiser that it was interrupted. If you've written your own interrupt routines in assembly you're probably just used to stashing those things in pre-determined memory locations which is an awful lot faster than stack operations. Edit: Even so 20 clock cycles is on par with a PIC18, and the Z80 takes 16 just to push one register pair! BattleMaster fucked around with this message at 15:57 on May 6, 2009 |
|
#
?
May 6, 2009 15:54
|
|
|
well yeah it's a given that you at least stack SREG and maybe a couple general purpose working registers. I'm guessing that it's expecting functions that will demand practically all of my working registers to be free for use at all times, so it's storing absolutely everything in sram (or the stack), which would definitely explain why things are so slow. That's certainly overkill, and I hope there's a way to fix it...
|
|
#
?
May 6, 2009 16:33
|
|
|
I wouldn't be surprised if it was maximizing use of GPRs to avoid large amounts of RAM use. It's faster to keep something in a GPR than to store it in RAM and read it later. To be honest I don't think that 20 clock cycles on a 20MHz microcontroller is as slow as you think it is. Most architectures don't even get 1 instruction per 1 clock cycle and people who use them manage just fine with even slower interrupt service routines. Edit for spelling BattleMaster fucked around with this message at 16:53 on May 6, 2009 |
|
#
?
May 6, 2009 16:51
|
|
|
ANIME AKBAR posted:pretty cool. I like how the LEDs light up based on what it's sensing. Any idea what went wrong? It is set to drive until it sees the edge, then turn until it no longer sees the edge - it usually ends up with enough of the sensor hanging over that it needs to turn about 90 degrees to get it back over the table, which is perfect. I suspect that time it was right on the edge of the first sensor, and when it rocked back slightly lost track of the edge and exited the turn prematurely. Luckily the 2+ foot drop didn't hurt it.
|
|
#
?
May 6, 2009 17:38
|
|
|
I'm an amateur at ordering from DigiKey. I got my ESD diodes and they are smaller than the tip of my soldering iron. I don't suppose there is anything I can do with these.
|
|
#
?
May 7, 2009 02:03
|
|
|
What size package are they?
|
|
#
?
May 7, 2009 06:21
|
|
|
Poopernickel posted:What size package are they? Super tiny? I don't really know. They only cost me a couple dollars so I'm willing to scrap them and start over. DigiKey has tons of these things (USB TVS diodes) but how do you know if any are suited for soldering by hand? I wish I could link to a search result there.
|
|
#
?
May 7, 2009 06:47
|
|
|
very posted:Super tiny? I don't really know. They only cost me a couple dollars so I'm willing to scrap them and start over. DigiKey has tons of these things (USB TVS diodes) but how do you know if any are suited for soldering by hand? I wish I could link to a search result there. "Suited for soldering by hand" is a relative term - I'm willing to bet that I could do those, given the right gear. DO-41 or DO-14 are both standard sizes for diodes, and I think something like that, if you can find the right TVS, would be good. Anything through-hole should be doable.
|
|
#
?
May 7, 2009 06:54
|
|
|
very posted:Super tiny? I don't really know. They only cost me a couple dollars so I'm willing to scrap them and start over. DigiKey has tons of these things (USB TVS diodes) but how do you know if any are suited for soldering by hand? I wish I could link to a search result there. It depends on the package size of the part. If you don't like surface-mount components, then "suitable for soldering by hand" means anything in an axial, radial, or DIP package. If you're down with surface mount but you're just doing point-to-point soldering, I wouldn't recommend any surface mount parts smaller than a 1206 package. On a real PCB with decent LAN patterns I can handle 0603's without too much trouble (although I prefer 0805). Poopernickel fucked around with this message at 08:23 on May 7, 2009 |
|
#
?
May 7, 2009 07:03
|
|
|
I'm looking to build a ducking or priority circuit but I'm not finding any good schematics/explanations of the theory behind them online and I don't have any analog circuitry experience, only digital stuff from being a computer engineering major. My situation: I have a satellite receiver in my car. I do not have an auxiliary 1/8" input for my iPod in my car. The satellite receiver hookup has normal L/R/Ground wires attached to it. I would like to splice a 1/8" jack into the satellite wires in such a way that when I plug a device into the jack, the satellite audio will cut out, and when I unplug a device from the jack, the satellite audio will come back. I know what I want is known as a "priority circuit" or "ducking circuit" but looking on Google I haven't found anything promising. Can anyone point me in the right direction? edit: oooh, this looks pretty similar http://www.ldrider.ca/techpages/audiooverridebox.htm What concerns do I have to take into mind wiring this in with the satellite audio output? Voltage of the iPod versus voltage of the satellite audio? The iPod should be line out 0.75v or no? Should the satellite audio be the same? I'm confused by this sentence: quote:If the input signal ground is not the power ground, the signal input should only be used on the stereo input. The stereo input has been designed to handle high power stereos which have 2 wires for each channel as opposed to low power car stereos which can just run a common ground for both left and right channels resulting in a three wire setup, like a Walkman. What is meant here? I have a three wire setup for the satellite audio and I assume I will for the 1/8" aux input as well. ashgromnies fucked around with this message at 02:07 on May 8, 2009 |
|
#
?
May 7, 2009 23:28
|
|
|
I'm looking to make something that heats a piece of metal to a specific temperature. Basically, I want to be able to push a button and something about the size of an eraser heats up to ~120F and stays there until I push the button again. I'd also like to make it so that it uses rechargeable batteries. Does anybody have any ideas on where I could start or what electronics knowledge I'd need to know?
|
|
#
?
May 8, 2009 00:53
|
|
|
Peantoo posted:I'm looking to make something that heats a piece of metal to a specific temperature. Basically, I want to be able to push a button and something about the size of an eraser heats up to ~120F and stays there until I push the button again. I'd also like to make it so that it uses rechargeable batteries. Does anybody have any ideas on where I could start or what electronics knowledge I'd need to know? What are you trying to heat up and how specific does the temp need to be? Big difference between needing +- 10 degrees or .01 degrees. You could probably get a rough regulator going with a thermistor and op amp.
|
|
#
?
May 8, 2009 02:40
|
|
|
ashgromnies posted:I'm looking to build a ducking or priority circuit but I'm not finding any good schematics/explanations of the theory behind them online and I don't have any analog circuitry experience, only digital stuff from being a computer engineering major. Wowowowow that is a complicated solution to a simple problem. They make spring-loaded headphone jacks that physically disconnect from a secondary source when something is plugged in. They're very common in guitar amplifiers. One of those and maybe a potentiometer on your ipod line and you could be good to go! edit: check this out: Digikey #CP-3505-ND Poopernickel fucked around with this message at 06:07 on May 8, 2009 |
|
#
?
May 8, 2009 06:00
|
|
|
Poopernickel posted:Wowowowow that is a complicated solution to a simple problem. Are you sure that part number is what I want? I can't find anything about that behavior in the description and it only has five contacts on it - I'd think those would be left in, right in, left out, right out, ground? Or am I misunderstanding? edit: Also the thing I don't like about this solution is that it requires me to now run the satellite wires back up to the front of the car where the jack will be, then back to the trunk, thus degrading signal quality. Right now all of the satellite wires are contained in a small run in the trunk. ashgromnies fucked around with this message at 13:50 on May 8, 2009 |
|
#
?
May 8, 2009 13:39
|
|
|
ashgromnies posted:Are you sure that part number is what I want? I can't find anything about that behavior in the description and it only has five contacts on it - I'd think those would be left in, right in, left out, right out, ground? Or am I misunderstanding? I'm assuming there is a line that runs from the satellite receiver in trunk to the stereo in the front of the car at some point. If not, how is it setup exactly? If there is a line going to the stereo, then you will be splicing this into that line at the point where you want to plug in your iPod. Here's the way the pins are connected in the jack:  This is assuming the tip of the plug is L and the ring is R. You will need to cut at least the L and R wires. Pin 1: Connect to ground of the satellite receiver to stereo wire. Pin 2: Connect to the Stereo side of the R wire. Pin 3: Connect to the Sat side of the R wire. Pin 4: Connect to the Sat side of the L wire. Pin 5: Connect to the Stereo side of the L wire. When nothing is plugged in, pin 2 is connected to pin 3 and pin 4 is connected to pin 5, passing the satellite signal on to the stereo. When the plug is inserted, it breaks these connections and the signal on the plug comes out on pins 2 and 5 and goes to the stereo while the satellite signal goes no where. Hillridge fucked around with this message at 14:11 on May 8, 2009 |
|
#
?
May 8, 2009 14:05
|
|
|
Hillridge posted:I'm assuming there is a line that runs from the satellite receiver in trunk to the stereo in the front of the car at some point. If not, how is it setup exactly? I would assume there is but I would really prefer to not have to rip the dash out because I don't have the tools to do it and I hear it's a pain in the rear end on these cars. This is where I got the idea from: http://forums.tdiclub.com/showthread.php?t=149894 my wiring is the same. Thanks for the schematic explanation. I will preferably remove the dash if I can find a good, easy way to without having to buy special tools, but otherwise I'm probably going to have a second wire run for the satellite audio. It will add like 32 feet total run to it which I would assume sucks for the audio signal. edit: ahh here are some removal instructions. Looks like the same wires exist there and I could probably splice in and find a way to run it into my center console where I'd like it to live. ashgromnies fucked around with this message at 14:27 on May 8, 2009 |
|
#
?
May 8, 2009 14:15
|
|
|
ValhallaSmith posted:What are you trying to heat up and how specific does the temp need to be? Big difference between needing +- 10 degrees or .01 degrees. I'm trying to heat a little nub, possibly made of plastic or rubber to something really close to 120 degrees. I'd be ok to make it in the range of 120-125, so I guess a +-difference of 2.5 degrees at 122.5 would be what I'm aiming for. It has to be safe to the touch (it's for a kids science project) and you need to be able to drag it on paper and stuff without it tearing the paper. Your thermistor idea was pretty much what I was needing to know. If I can cap that with a thin silicone cap or something else soft and get it to heat to at least 120 on the outside of that cap, I'd be golden.
|
|
#
?
May 8, 2009 22:44
|
|
|
I finally scrounged up enough money for The Art Of Electronics. Does anyone know if there is any sort of answer key available anywhere for the exercises? I'm not having trouble with any particular question, it would just be nice to check my work as I go through a few of the sections.
|
|
#
?
May 11, 2009 02:30
|
|
|
Keebler posted:I finally scrounged up enough money for The Art Of Electronics. Does anyone know if there is any sort of answer key available anywhere for the exercises? I'm not having trouble with any particular question, it would just be nice to check my work as I go through a few of the sections. I wouldn't really bother with the questions. Its nice a reference and for learning the basics but much of the details are out of date. The book was published in 89 and 3rd ed has been pushed back more than Duke Nukem Forever. Anyone know of a book that is a good as AoE but more recent?
|
|
#
?
May 11, 2009 04:32
|
|
|
ValhallaSmith posted:I wouldn't really bother with the questions. Its nice a reference and for learning the basics but much of the details are out of date. The book was published in 89 and 3rd ed has been pushed back more than Duke Nukem Forever. The million dollar question. There are some more specific books (ie books that cover in more detail what is covered in AoE in a chapter) that are pretty good, but I have yet to encounter a general textbook that's as good. A good textbook off the top of my head (can't think of more that are good for hobbyists): -"Opamps for Everyone", Mancini clredwolf fucked around with this message at 22:46 on May 12, 2009 |
|
#
?
May 11, 2009 18:54
|
|
|
clredwolf posted:
From reading one of the reviews on Amazon, it turns out this book is available for free: http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=slod006b Looks pretty good so far. Kinda wish I had this at the start of my analog class this semester.
|
|
#
?
May 11, 2009 23:02
|
|
|
SnoPuppy posted:What are your OFFSET IN constraints? They're a good idea for all digital designs, and absolutely mandatory for high speed work. Xilinx can make DDR constraints kind of a bitch - what version of ISE are you using? I heard they got better in 10.1. I had to get my wisdom teeth out last week, so I've made little progress until now. I gave it another whirl today,and this is what I get: What I want to see:  Click here for the full 736x552 image. What I actually see (my code):  Click here for the full 736x552 image. Test pattern (works; I replace U2's .din(captured_dataA) with .din(test_pattern) ):  Click here for the full 736x592 image. I think it lies somewhere between the input pins and the fifo, so probably somewhere in the adc_capture module. I am really stupefied by this right now though. The adc_capture code is really simple! Ugh, I'm gonna go take a break before the laptop gets a pipe through it... Code I am using (I pastebin'ed the 3 modules I think the problem lies in): http://pastebin.com/m6e18c750 Also I'm using Xilinx's FIFO builder to make me a 2048-size fifo. As evidenced by the test pattern, it seems to work okay (it's just a counter that's clocked off the data clock and increments every time it sees a frame sync).
|
|
#
?
May 12, 2009 22:51
|
|
|
clredwolf posted:I had to get my wisdom teeth out last week, so I've made little progress until now. I gave it another whirl today,and this is what I get: Is this a school project? You're close, but I've noticed a couple of things that are odd/wrong. 1) Why do you double sync the frame signal? Its signal path should look identical to the data, up through the shift register. This includes the DDR flops and shift register. 2) You're looking for the frame signal wrong. The center of a frame is high-to-low transition. Also it is a good idea to check the entire frame signal (i.e. compare to "111111000000"). If the timing is marginal, you should get errors in the frame signal and this should help catch them. 3) I don't see a *.ucf file with timing constraints. You really should have them. Take a look at the Xilinx constraints guide (cgd.pdf) and OFFSET IN whitepaper (wp237.pdf). You should be able to find them on xilinx's web site. 4) I don't think that the data sheet specifically mentions which clock edge is used. I want to say that all data words are rising edge aligned, but like I said, this isn't explicitly called out in the data sheet. Because of this, you might want to make your code work for either rising OR falling edge aligned data (this will also help if there is excessive clock-data skew). Making your code work for either case is a pretty simple exercise. Just extend the shift registers by another 2 bits, making them 14 total (data and FCO). Then look for the frame signal in bits (11 downto 0) and (12 downto 1). Whichever goes true is the one you want. One thing to note, when you're doing the compare on fco_sr, you might have problems meeting timing. Just pipeline the compare and you should be fine. As always, test benches make debugging much easier. edit: Also, you need a BUFG after your IBUFGDS. I think the tools will auto-insert them, but it's always nice to make sure they're there. SnoPuppy fucked around with this message at 15:39 on May 13, 2009 |
|
#
?
May 13, 2009 15:28
|
|
|
Close. Robotics club at my university. We're trying to implement a rather sexy sonar system, with this ADC as the core. 1) I did this because I wanted to see if using the same-edge-pipelined IDDR block would be any more effective than the opposite-edge IDDR block. You have to delay the frame sync a little if you do that. (It didn't get me anything so I'll probably roll back to opposite-edge timing, since it's a little neater) 2) Ok I'll give that a shot. I think I'm looking for it right, but my shift register is running in reverse (lsb to msb). I'll switch it the other way because I admit that is pretty confusing. 3) I do have a .ucf, but I don't trust it. I'll look at those docs and see if this helps it along any. I've got a test bench up, but honestly test benches are my Achilles heel. I never did catch on how to do them really well. I do have a test bench set up for this guy though, I just didn't post it. I'll use that to see if I can get any closer. I'll be working on this tonight a bit, I'll post results when I get them. EDIT: Progress... My testbench: http://pastebin.com/m124f42b7 My (messy) testbench output (Q1 and Q2 are from fco_ddr): http://www4.ncsu.edu/~bmhendri/document1.pdf The new capture module: http://pastebin.com/m7d7420e8 The, erm, output:  Click here for the full 736x532 image. Basically I added a DDR decoder for the fco, so I could get 12 cylces of capture from it. Looking for 12'b111111000000 gave no results, and the testbench suggested that 12'b011111100000 might work, and it gave the above results. It's closer, but not quite there. Comparators are 2-stage pipelined, 3 inputs each for best compilation on the FPGA (3-input LUT + flip-flop, right?). I'm too tired to soldier on right now, I think I'm gonna make a big push once I'm all refreshed tomorrow. clredwolf fucked around with this message at 03:21 on May 14, 2009 |
|
#
?
May 13, 2009 22:43
|
|
|
clredwolf posted:Close. Robotics club at my university. We're trying to implement a rather sexy sonar system, with this ADC as the core. is this anything like the sodar ranging project I posted about several months back? Keebler posted:I finally scrounged up enough money for The Art Of Electronics. Does anyone know if there is any sort of answer key available anywhere for the exercises? I'm not having trouble with any particular question, it would just be nice to check my work as I go through a few of the sections. ValhallaSmith posted:I wouldn't really bother with the questions. Its nice a reference and for learning the basics but much of the details are out of date. The book was published in 89 and 3rd ed has been pushed back more than Duke Nukem Forever. ANIME AKBAR fucked around with this message at 17:54 on May 14, 2009 |
|
#
?
May 14, 2009 17:40
|
|
|
clredwolf posted:EDIT: Progress... Your code looks relatively good, as far as I can tell For the output diagram, what is the input? Is it a test pattern? That some of the bits aren't changing is a little strange. Remember, you have to take timing into account when you're writing a test bench to deal with the outside world. There should be some skew between the DCO and data lines/frame line, and it looks like your test bench doesn't take this into account. Thus you could get a false pass/fail. You said that you're using an eval board for both the ADC and FPGA, right? Are you sure that your traces are length matched? Have you measured the clock/frame/data skew, at the FPGA via? This could be an issue if there is too much difference between the two. The compare should be with "111111000000". If you look at pages 8&9 of the datasheet, you can see that the frame and data lines have identical timing characteristics. And that the frame is "1" for the first 6 bits, and "0" for the next 6 bits. If that isn't working, you have some sort of weird timing issue and I would suggest looking at the DCO/FCO signals with a fast scope (bandwidth should be >= 5x clock rate). FYI, if you're using a Virtex4, the LUTs are 4 input. And really, I wouldn't have pipelines unless you're failing timing without them. A 12 bit compare to a constant should only take 4 LUTs and be 2 levels deep (three for the 12 inputs -> one for the three outputs). Don't optimize unless you need to, since it can introduce bugs.
|
|
#
?
May 14, 2009 19:45
|
|
|
ANIME AKBAR posted:The book sometimes used as a primary textbook in classes, so I doubt you'll be able to find complete answer keys. I've never really looked at their problem sets before (though their good/bad circuit exercises are pretty great and entertaining). Thats kind of what I figured. I was mainly after a book that could provide a breadth of information as well as serve as a reference. My background is in CS so I'm still lacking in a few areas. Being able to play around with the exercises would have just been icing on the cake.
|
|
#
?
May 14, 2009 20:40
|
|
|
ANIME AKBAR: Kinda, I think I talked about mine a bit in that thread too. Same concept, but 10 feet underwater instead. That converter is *total* overkill for this, but it's worth it to have the amplifiers, filter, and ADC on a single chip (plus I can move to high frequencies later). Unfortunately the evaluation board I've got is running at full blast right now (50MHz clock = 350MHz data clock, where the FPGA gets dodgy at 400MHz), but I guess that's good because if it works at 50MHz it'll work at 10MHz (or whatever) just fine. I think I'm gonna make another thread in DIY about the whole robot in a few weeks. It's not technically DIY, but we're using a lot of off-the-shelf components and we're doing really gangbusters this year (esp compared to last year, ick). A lot of DIY-type stuff is being used to great advantage. For one we're using a lot of Arduinos!  SnoPuppy, thanks again for all the help! It's really helping me move along here, the only other guy I know who's any good at verilog is on vacation. I'm retooling my test bench a bit, I think I've found a few potential issues now. I'll keep at it. I'm not ever getting matches on 12'b111111000000, even in the test bench. I think I've timed something wrong there. I don't know for sure if the lines are length matched, but I kinda know the guy who designed the board and he's a nazi about line lengths. I would think it's matched pretty well, but I don't have the tools to really check for myself here. I know it works well on their old FPGA code too (they used a DCM with a skew of 90 degrees on the dco, I'm not sure if that affects anything). Part of the problem is that I'm having to run ISE through remote desktop, over my lovely cable connection. I don't have a full version on my laptop, and my university lets me use it over remote access only which is kind of annoying. Slows my pace of work way down.
|
|
#
?
May 15, 2009 02:07
|
|
|
Hey guys, quick question: I want to relocate a 6 character LCD by detaching it from the circuit board and attaching it again with a 3 foot long wire. Would that work?
|
|
#
?
May 19, 2009 02:24
|
|
|
dyne posted:Hey guys, quick question: Should work. If it is serial controlled, RS232 should be fine over a 3 foot wire. If you are transmitting the direct signals for driving the LCD, they usually only run at 60-200Hz or something relatively low-frequency low-power and I suspect would be fine. You should just try it and get back to us 
|
|
#
?
May 19, 2009 05:59
|
|
|
Delta-Wye posted:Should work. If it is serial controlled, RS232 should be fine over a 3 foot wire. If you are transmitting the direct signals for driving the LCD, they usually only run at 60-200Hz or something relatively low-frequency low-power and I suspect would be fine. I will  , but not for a week or two since the part hasn't arrived yet
|
|
#
?
May 19, 2009 13:00
|
|
|
clredwolf posted:Part of the problem is that I'm having to run ISE through remote desktop, over my lovely cable connection. I don't have a full version on my laptop, and my university lets me use it over remote access only which is kind of annoying. Slows my pace of work way down. This is pretty much necromancy here, but I wanted to mention that Xilinx offers a "free" version of ISE for download called the webpack. It's completely identical to the for-money version except that ISim runs gimpy if you're simulating a design with more than 50,000 lines of code (it warns you to upgrade and then simulates slowly). But who really simulates a design _that big_ anyways?
|
|
#
?
May 19, 2009 16:51
|
|
|
Poopernickel posted:This is pretty much necromancy here, but I wanted to mention that Xilinx offers a "free" version of ISE for download called the webpack. It's completely identical to the for-money version except that ISim runs gimpy if you're simulating a design with more than 50,000 lines of code (it warns you to upgrade and then simulates slowly). But who really simulates a design _that big_ anyways? I need to run an IP core in the full version (the signal decimator/CIC core). I've sadly been without internet for a few days (thanks AT&T) so it's not necromancy, it's just been sleeping.... UPDATE: I got just a tad step further. Now I seem to be receiving on the right frame (part of it was my testbench had some errors, opps), and then I uncovered this suspicious error: http://www4.ncsu.edu/~bmhendri/document2.pdf explenation: 'out' is misnamed, it is the input to the capture model. dinA_out is the real output of the block. http://www4.ncsu.edu/~bmhendri/adc_capture_test.v http://www4.ncsu.edu/~bmhendri/adc_capture.v How come the shift registers are changing the SAME cycle that the IDDR registers are changing? clredwolf fucked around with this message at 03:49 on May 20, 2009 |
|
#
?
May 19, 2009 23:37
|
|
|
|
| # ? May 8, 2024 04:43 |
|
|
Yay, I got a testbench working! http://www4.ncsu.edu/~bmhendri/document3.pdf Lemme see if it synthesizes and how well it works.... -UPDATE- Well dog crap, it doesn't work  Gives me all zeros.Running it with the test pattern generator fails too, looks like it's not getting a clock... Time to check my timings again. -UPDATE2- Ugh, I lowered the size of the FIFO buffer (yet again) to meet timing constraints. All constraints are met now, and...still all zeros. I don't get it. I uploaded my .ucf file here. Any possible problems? Do I need to throw a DCM back in the mix? http://www4.ncsu.edu/~bmhendri/Top.ucf clredwolf fucked around with this message at 06:04 on May 20, 2009 |
|
#
?
May 20, 2009 05:15
|
|