|
remember how everyone then posits that since that can be done, we'll soon replace boring ol' predictable stoplight mechanisms with goofy poo poo you can't trust outside it's training parameters?
|
#
?
Oct 21, 2015 20:10
|
|
|
|
| # ? May 15, 2024 03:26 |
|
|
karasu posted:What our layout team did was calculate the traversal speed of the different signal layers and make a big spreadsheet which lists the lengths that each signal spends on every plane and calculate the combined delay. Then they added detours for some signals so that all the signals of a group have the same delay. We're using Altium which has signal integrity functionality but nobody used it. I joined the project when the first boards were already in the house, otherwise I would have freaked out with this workflow like our FAE did. lol full disclosure: i haven't actually done a DDR3 design yet, next week i'm off to denmark for a design course, at least i'll be using straight chips and not DIMMs i'm expecting to have to do the simulations and fine tuning myself on the layout though, i don't expect a PCB layout artist to know the SI tooling very well
|
|
#
?
Oct 21, 2015 20:17
|
|
|
Mr Dog posted:remember that time somebody autogenerated a clockless FPGA to distinguish between two tones and it had a bunch of poo poo in the corner that wasn't connected to anything and if you took that stuff out or changed the ambient temperature significantly it didn't work any more http://www.damninteresting.com/on-the-origin-of-circuits/
|
|
#
?
Oct 21, 2015 20:47
|
|
|
That was super interesting, I hadn't heard of it before.
|
|
#
?
Oct 22, 2015 00:45
|
|
|
its a really good way of finding corner cases in your simulator
|
|
#
?
Oct 22, 2015 01:01
|
|
|
if i want to program a couple of small PALs/GALs to replace a handful of TTL chips then what should i be learning? vhdl? verilog? palasm? cupl?
|
|
#
?
Oct 22, 2015 14:55
|
|
|
verilog
|
|
#
?
Oct 22, 2015 15:08
|
|
|
and u should use one of the modern pal/gal replacements that are basically tiny fpgas, which is why you use a real language. lattice makes a shitload of them
|
|
#
?
Oct 23, 2015 02:11
|
|
|
verilog and/or vhdl and the device you're looking for is a CPLD I hear it's even hard to find a PAL or GAL or programmer for them these days
|
|
#
?
Oct 25, 2015 09:01
|
|
|
you can buy PALs and GAL on digikey no problem, and program them in any eprom programmer
|
|
#
?
Oct 25, 2015 13:19
|
|
|
i wish i could get a gal pal 
|
|
#
?
Oct 25, 2015 15:30
|
|
|
Mr Dog posted:i wish i could get a gal pal build yourself one... out of gals and pals 
|
|
#
?
Oct 25, 2015 20:34
|
|
|
Where's a good place to get an oscilloscope? In school we used HP/Agilent or Tektronix and they all seemed fine. Right now I need it for a hobby project where I'm doing electromyography and am trying to scale and threshold some A/D within 0-1V and my fluke dmm just can't do it. It's not like I need ~GIGASAMPLES~ though, but I'd like something with triggering/one-shot mode for this particular experiment. Doing screen caps to the computer would be cool but eh. Would something like this be ok? https://washingtondc.craigslist.org/mld/tls/5290405649.html There are nicer ones like this but I don't really want to lay down the cash: https://washingtondc.craigslist.org/nva/ele/5288379388.html Hed fucked around with this message at 02:48 on Nov 2, 2015 |
|
#
?
Nov 2, 2015 02:43
|
|
|
Hed posted:Where's a good place to get an oscilloscope? In school we used HP/Agilent or Tektronix and they all seemed fine. Right now I need it for a hobby project where I'm doing electromyography and am trying to scale and threshold some A/D within 0-1V and my fluke dmm just can't do it. It's not like I need ~GIGASAMPLES~ though, but I'd like something with triggering/one-shot mode for this particular experiment. Doing screen caps to the computer would be cool but eh. you can get an awesome older HP/Agilent/Keysight or Tektronix scope or logic analyzer for cheap on eBay or from Weird Stuff (which has an eBay store) or Halted/HSC my HP 1660cs is a logic analyzer that includes a scope (including triggering like you want) and was only a few hundred bucks at HSC, and it has both GPIB and 10Base-T for control and programming and remote UI and data collection and stuff I saw a 16500 mainframe and analyzer listed on eBay a month or two back by Weird Stuff for like $400, which is less than what I paid for an older model a year ago e: looking at the listings you posted, the first might or might not be enough for what you want, the second I wouldn't bother with since you can get way more for less if you buy equipment that's a bit older one other thing to watch out for is that Tek at least switched to Windows for the OS on their higher end equipment, meaning early-90s poo poo is running XP and likely to be a garbage dump if you let it near a network; all the HP-and-successors stuff I've seen has used their bespoke OS which makes me trust it a bit more eschaton fucked around with this message at 04:13 on Nov 2, 2015 |
|
#
?
Nov 2, 2015 04:10
|
|
|
this is the kind of thing I'm talking about HP 54502A 400 MHz digital scope, for $200 and like other HP digital equipment it has HP-IB (aka GPIB, aka IEEE-488) which means you can use a USB adaptor or whatever to talk to it and automate whatever you're using it for, and Keysight still has all the docs online (and if it took software, the software would be there too)
|
|
#
?
Nov 2, 2015 04:58
|
|
|
idiot embedded programming question: I'm working on moving out of the arduino environment - I've been using VisualMicro w/ Visual Studio for a spare time project, and it's really awesome. I'm working on separating things into different .cpp files... but is there a standard place for putting all my #define statements? Like, I guess stuff specifically for the functions of that cpp file would go there, but what about global stuff? Does that go in my main file or what?
|
|
#
?
Nov 2, 2015 05:07
|
|
|
those old HP scopes are usually equivalent time below a certain timebase, really annoying because they don't give a clear indication of when that is all the newer fancy HP instruments run windows XP too, but they do offer windows 7 now. they just released a UI refresh that makes them look and perform like a CD player program from 2002 (http://literature.cdn.keysight.com/litweb/pdf/5991-3864EN.pdf?id=2432677) just get a rigol DS1054z for home use, it's well built, lots of features (advanced triggering, protocol decoders, all standard measurements), can be upgraded to 100 MHz and they all come with USB, LXI Ethernet and USB flash drive support as standard, either one can do screenshots that series also has a fairly wideband front-end so it will show sine wave signals significantly above 100 MHz, although loss increases a fair bit above 200 MHz and the frequency counter stops working above 100 or so I've tried several tektronix MDO 3000 series scopes through work (though we don't use tek scopes in my department), rigol scopes are easier to use, have better looking UIs (and better persistence rendering) and are actually responsive whereas the low end tek scopes are super slow to do anything.
|
|
#
?
Nov 2, 2015 22:09
|
|
|
bump
|
|
#
?
Dec 4, 2015 22:13
|
|
|
Fanged Lawn Wormy posted:idiot embedded programming question: sounds like you've got the right idea, you'll have to figure out the details yourself based on your workflow preferences, tools, etc. over time, you'll refine the conventions you use to organize and develop your firmare. this shows the source for two applications. . ├── include │ └── spi.h └── src ├── app │ ├── adapter │ │ ├── config.h │ │ ├── main.c │ │ └── Makefile │ └── logger │ ├── config.h │ ├── main.c │ └── Makefile └── driver ├── spi_x.c └── spi_y.c both applications use the same API for the communicating with a spi device, so both main files start out like this, code:you should try to avoid using global #defines to configure drivers when possible.. there are some good reasons to do it, e.g. you really want to maximize battery life and minimize wake-time, so you don't want to configure your modules at run time. configuring your code with defines will however make your code less maintainable. at first its one #if, then its another, before long it becomes a mess. logger/config.h code:code:driver/spi_x.c code:a side effect of including config.h in the driver is that it ties your driver implementation to the workflow conventions you've defined. at best, your code will be difficult to share with others, at worst your source tree will become difficult to maintain over time. a better way would be to expose the functionality you want through an API call rather than a global define. here i'm replacing the SPI_BAUD define with a setter include/spi.h code:spi_x.c code:logger/main.c code:Jerry Bindle fucked around with this message at 23:14 on Dec 4, 2015 |
|
#
?
Dec 4, 2015 23:09
|
|
|
spent an hour debugging SPI flash reads and writes turns out those were working just fine erase was hosed up
|
|
#
?
Dec 7, 2015 20:08
|
|
|
|
|
#
?
Dec 7, 2015 20:46
|
|
|
my usb datalink occasionally backpressures hard enough that the itty bitty fifo has to dump data on the floor. possible solutions: fix the usb datalink to be more reliable add a fuckoff big fifo guess what im going to propose in the next rev of this prototype
|
|
#
?
Dec 7, 2015 20:47
|
|
|
if you guessed replacing the 32x8192 fifo with like 256mb of sram you guessed right!!!
|
|
#
?
Dec 7, 2015 20:47
|
|
|
Bloody posted:if you guessed replacing the 32x8192 fifo with like 256mb of sram you guessed right!!! might even be cheaper that way what with the relative volume of the components!
|
|
#
?
Dec 7, 2015 21:05
|
|
|
yeah when you factor in the cost of time it's outrageously cheap to add a fuckoff pile of RAM to the system and quite expensive for me to spend debug time figuring out why the USB link isn't quite perfect
|
|
#
?
Dec 7, 2015 21:08
|
|
|
although it is kind of weird that the USB3.0 device plugged into a USB3.0 port with a USB3.0 cable just doesn't enumerate at all. USB2.0 for lyfe i guess
|
|
#
?
Dec 7, 2015 21:08
|
|
|
other things coming to the next rev: replacing the fpga with just, like, t he biggest one in the family, who even cares
|
|
#
?
Dec 7, 2015 21:10
|
|
|
Bloody posted:if you guessed replacing the 32x8192 fifo with like 256mb of sram you guessed right!!! how fat is your BOM that 256mbit of SRAM is no big deal?
|
|
#
?
Dec 7, 2015 21:14
|
|
|
Bloody posted:other things coming to the next rev: replacing the fpga with just, like, t he biggest one in the family, who even cares where all nontrivial fpga projects end up eventually
|
|
#
?
Dec 7, 2015 21:22
|
|
|
DuckConference posted:how fat is your BOM that 256mbit of SRAM is no big deal? oh probably sdram i guess either way, our hundred dollar a pop fpgas are at best a tiny fraction of our bom so lol
|
|
#
?
Dec 7, 2015 21:38
|
|
|
nobody even makes 256mbit srams lol although tbf a 72mbit one would likely be just fine and easier to use than an sdram so final answer 36-72mbit sram
|
|
#
?
Dec 7, 2015 21:45
|
|
|
buy 2 of the biggest fpga and use one as a fifo
|
|
#
?
Dec 7, 2015 21:46
|
|
|
Palace of Hate posted:buy 2 of the biggest fpga and use one as a fifo unironically considered doing this with one of our dev boards around 20 minutes ago
|
|
#
?
Dec 7, 2015 21:47
|
|
|
Bloody posted:my usb datalink occasionally backpressures hard enough that the itty bitty fifo has to dump data on the floor. possible solutions: wish you're posts were dumped on the floor
|
|
#
?
Dec 7, 2015 21:50
|
|
|
Palace of Hate posted:buy 2 of the biggest fpga and use one as a fifo #yolo
|
|
#
?
Dec 7, 2015 21:55
|
|
|
Bloody posted:other things coming to the next rev: replacing the fpga with just, like, t he biggest one in the family, who even cares if u do this you'll prob have enough sram in the fuckoff fpga for ur giant fifo
|
|
#
?
Dec 7, 2015 21:56
|
|
|
i can't imagine what it is that hosed up in the usb to make that much ram needed to solve the problem, but at the same time it sounds like the right call
|
|
#
?
Dec 7, 2015 22:02
|
|
|
saturating a usb3 bus creates fun problems like that yes luckily my job on that project for me was to say "its broke" to the guys that actually made the board
|
|
#
?
Dec 7, 2015 22:05
|
|
|
oh i've only worked with usb2.0, i bet 3.0 has a whole nest of catches i have no clue about
|
|
#
?
Dec 7, 2015 22:06
|
|
|
|
| # ? May 15, 2024 03:26 |
|
|
Barnyard Protein posted:i can't imagine what it is that hosed up in the usb to make that much ram needed to solve the problem, but at the same time it sounds like the right call it's 2.0 only but a 32x8192 fifo fills in idk a few milliseconds in our system and we're just using a bulk endpoint because i didnt want to figure out how to use a different one and then make a different one go fast enough also i doesn't super duper matter to the long-term system because some day this usb bridge will be a wireless link to another real-time device so... eh.
|
|
#
?
Dec 7, 2015 22:54
|
|