Electronics > Projects, Designs, and Technical Stuff
DIY Modular Test Equipment Project
SaabFAN:
--- Quote from: Mastrofski on June 05, 2016, 01:15:18 am ---
I think for one-off pieces of equipment, using odds and ends is fine, but for something going into production, or something designed to be recreated by others(such as this project), sourcing components begins to become an issue.
--- End quote ---
Didn't realize that this one is intended as a (maybe commercial) product. In that case, only Components that at least "Active" or "Recommended for new Designs" should be used.
For standard-parts like diodes or transistors, there's normally a pin-compatible replacement, but ICs can become a pain real quick.
Btw. how are you planning to implement the Modularity?
- Mainframe-Style: One device with a backplane and Plug-In Modules
- Modular Construction: Complete devices that look different on the inside, but always have the same front-panel and case
bktemp:
--- Quote from: void_error on June 05, 2016, 11:23:37 am ---If you're all wondering why I didn't use a SPI connection directly to the LCD and instead went for I/O expanders it's because SPI doesn't allow reading the LCD data (see UC1701 datasheet) such as BUSY status.
--- End quote ---
Do you need to read the data back?
I generally avoid connecting GLCDs using I2C, because it is slow. Especially in your case, because you need to send many I2C bytes for writing a single byte to the LCD (setup data byte, toggle WRITE. It looks like you need 3 I2C bytes for each write to the ouputs, so thats 9 bytes for each data byte).
The same applies for the rotary encoder. Depending on the encoder, you may need to sample the levels 100-1000 time per second otherwise it misses steps or gets the direction wrong.
void_error:
--- Quote from: Mastrofski on June 05, 2016, 01:15:18 am ---I think for one-off pieces of equipment, using odds and ends is fine, but for something going into production, or something designed to be recreated by others(such as this project), sourcing components begins to become an issue.
--- End quote ---
Luckily for me there's a local distributor about 1km (actually same neighborhood) from where I live and they can get pretty much any part I want from the large distributors like Digikey and Mouser at a slightly higher price but without the $50+ shipping that I would have to pay if I got the parts straight from the overseas distributors.
I usually try to avoid sourcing parts from outside Europe, most of the stuff I order from TME. I think the Waveform Generator has all the parts available there, I'll have to double-check to be sure.
--- Quote from: SaabFAN on June 05, 2016, 11:29:08 am ---Didn't realize that this one is intended as a (maybe commercial) product. In that case, only Components that at least "Active" or "Recommended for new Designs" should be used.
For standard-parts like diodes or transistors, there's normally a pin-compatible replacement, but ICs can become a pain real quick.
Btw. how are you planning to implement the Modularity?
- Mainframe-Style: One device with a backplane and Plug-In Modules
- Modular Construction: Complete devices that look different on the inside, but always have the same front-panel and case
--- End quote ---
It's going to a combination of both Mainframe-Style and Modular Construction.
The case won't be the same but the front panel is always going to be the User Interface board.
For Waveform Generator I intend to make it a plug-in board with the BNC connectors on the front panel, whule the Aux Power Supply modules being separate boards or even stackable, that depends on how the PCB layouts turn out.
For the Lab Power Supply there are going to be several modules, with the digital isolator board plugging into the back of the User Interface board just like the Waveform Generator. I'm going to stick to 0.1 inch pitch connectors so I maintain some sort of compatibility with breadboards/arduino boards/etc.
--- Quote from: bktemp on June 05, 2016, 11:43:47 am ---
--- Quote from: void_error on June 05, 2016, 11:23:37 am ---If you're all wondering why I didn't use a SPI connection directly to the LCD and instead went for I/O expanders it's because SPI doesn't allow reading the LCD data (see UC1701 datasheet) such as BUSY status.
--- End quote ---
Do you need to read the data back?
I generally avoid connecting GLCDs using I2C, because it is slow. Especially in your case, because you need to send many I2C bytes for writing a single byte to the LCD (setup data byte, toggle WRITE. It looks like you need 3 I2C bytes for each write to the ouputs, so thats 9 bytes for each data byte).
The same applies for the rotary encoder. Depending on the encoder, you may need to sample the levels 100-1000 time per second otherwise it misses steps or gets the direction wrong.
--- End quote ---
I could get away without reading the data back but I might as well have the option to do it for example just updating a certain portion of the screen instead of the whole screen.
I did suspect I2C would be quite slow so I replaced the I2C I/O expanders with SPI ones.
The MCP23S08 expanders used have an interrupt output pin with programmable polarity, which is triggered depending on how the input pin interrupt registers are set. In other words, all the micro has to do when the expander's INT pin changes state is transfer the data. With SPI that would be really fast, up to 10Mbits/s, depending on the UI micro's clock. With the USB-UART micro moved off-board the UI micro can run off an 8MHz oscillator (I had to use 16MHz when the clock was shared because the USB micro had x3 or x4 PLL to achieve the 48MHz clock required for USB operation), add x4 PLL and SPI can go up to 8MHz (Fosc/4).
The UI code will be heavily based on interrupts, taking advantage of all the core independent peripherals the PIC16F18857 has.
prasimix:
--- Quote from: void_error on June 05, 2016, 12:10:01 pm ---
--- Quote from: SaabFAN on June 05, 2016, 11:29:08 am ---Didn't realize that this one is intended as a (maybe commercial) product. In that case, only Components that at least "Active" or "Recommended for new Designs" should be used.
For standard-parts like diodes or transistors, there's normally a pin-compatible replacement, but ICs can become a pain real quick.
Btw. how are you planning to implement the Modularity?
- Mainframe-Style: One device with a backplane and Plug-In Modules
- Modular Construction: Complete devices that look different on the inside, but always have the same front-panel and case
--- End quote ---
It's going to a combination of both Mainframe-Style and Modular Construction.
The case won't be the same but the front panel is always going to be the User Interface board.
For Waveform Generator I intend to make it a plug-in board with the BNC connectors on the front panel, whule the Aux Power Supply modules being separate boards or even stackable, that depends on how the PCB layouts turn out.
For the Lab Power Supply there are going to be several modules, with the digital isolator board plugging into the back of the User Interface board just like the Waveform Generator. I'm going to stick to 0.1 inch pitch connectors so I maintain some sort of compatibility with breadboards/arduino boards/etc.
--- End quote ---
Glad to see that you decided to define multi-modular solution with Mainframe-style possibility. That is ambitious project and hopefully more people will be attracted soon and decide to join you. If I "dream" about something then it's interoperability of what I made with other people designs. I don't have a problem to adopt everything that is already created to share the same "DIY-instrumentation-bus" and works under same software framework and successfully communicate with commercial instruments.
Like timofonic I vote for GitHub/Bitbucket openness in one moment because it could make a whole thing more interesting in the long run (and hopefully you are already aware of how looooooong could takes to make something in correct/usable way :)).
From my side I'm looking forward to see if your design could become a potential "target" for firmware that we are developing. Not sure for now, but if currently developed code could be ported to PIC that can save literally hundreds of hours for you.
One more thing because I been there: it's a LCD display or better to say its 128 x 64 (and monochrome) resolution. TFT LCD becomes really dirty cheap and they are not of equally dirty quality! Even if you hate "touch screen" you don't need to rely completely on it: there is no reason why encoders shouldn't be on your front panel together with touch-screen.
Finally something that I should mention on the beginning: I'm suggest to not take mechanical aspects too lightly! That can really generate a lots of frustration: because you realized that something is not accessible, cannot be mounted, have EMC or heating issue, etc. Of course today's 3D modeling, thermal modeling, etc. could help you to avoid such mistakes that will push you into another revision, but remember that you are still alone and even with 96 working hours day that will consume all your time (again I'm talking about something that will be usable for you and eventually many others). So, mind the mechanics! Define boundaries within everything will happen first.
:-+
JPortici:
+1 on the tft screen. nowadays they are much cheaper than GLCDs.
One thing i wanted to try on a new project is going old school: encode the framebuffer in 4 bit per pixel and use a palette. a 320x240 screen would then need "only" 37.5 kB of ram for the framebuffer (and 16 colours are more than enough for my application.. and yours)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version