I've to design an IO-module for an industrial control system in a CAN-bus network.
The IO-pins (10-40 pins) have to be all multi purpose: digital and analog in- and output. Further the pins have to serve as a communication port when needed: Modbus RTU, modbus TCP, DALI, etc. (Analog input max 7 channels)
I understand that all of this options need different HW; like galvanic isolation or different voltage levels etc.
Costs have to be as low as possible.
I was thinking of making this bit of additional hardware as a plug-in module or as an optional additional sandwich PCB.
My question is: Is an FPGA the right choice for this because of the reconfigurable purpose of the IO-pins? (Xilinx, altera/intel and microsemi have FPGA's with ADC's)
You didn't specify if IOs have to be reconfigurable at compile or runtime. In most cases, you cannot change IO properties (type, voltage, terminations,etc.) once HDL code is compiled into FPGA bitstream.
Related
I am trying to figure out what the maximum throughput of a Bluetooth 2.1 SPP connection is.
I found 2 publications concerned with the topic (1, 2) and they both show diagrams, which show the throughput as a function of the Signal to noise ratio (that I can assume to be perfect for my concideration) and the kind of ACL package used. My problem is, I have no Idea which ACL packets are used. How is this decision made? Is it made on the fly, like "what's needed to transfer the current data is used"?
Furthermore, in the Serial Port Profile specification (chapter 2.3) I found this sentence:
This profile requires support for one-slot packets only. This means that this profile
ensures that data rates up to 128 kbps can be used. Support for higher rates is optional.
The last sentence realy confuses me. How do I find out whether this "option" applies in my case?
This means that in SPP mode, all bluetooth modules should work up to 128kbps, and some modules may work even faster.
Under SPP is RFCOMM, which tries to deliver the packets as quickly as possible. If only one packet is sent in one timeslot, you get the 128kbps. The firmware of the bluetooth module, or the HCI driver however can do things differently.
There are SPP speeds up to 480kbps reported - however this requires that both SPP modules are from the same vendor (e.g. BlueGiga iWrap modules can do this speed).
On the other end, if you're connecting to an unknown device, for example a BT112, or an RN41 module to an Android device, the actual usable SPP bandwidth can be much lower than 128 kbps (I have measurements as low as 10kbps).
In case of some old generation iPhones, the usable SPP bandwidth is around 8 kbps.
It is a wise idea to treat "standards" and "datasheets" very conservative, and do your own measurements if actual net data bandwidth is critical.
Even though BT, BT+EDR has theoretical on-the-air bitrates of 3Mbps, the actual usable net data bandwidth is a way smaller.
How are signals/ports of peripheral in a microcontroller connected to the PAD ??
Say, my SoC has 'n' signals. then these 'n' signals will be connected to pad and then reach the top-level. How is this connection done ?
Pad connections are made by HDL wires as with any other connection. Those wires would traverse hierarchical boundaries until they reach the pads which are instantiated cells like any other*. Some pads require more than one connection (for output signals, input signals, output enables and/or direction controls). Between your peripheral and the pad there may be additional SoC logic for pad functional multiplexing, test mode multiplexing, debug and/or jtag/scan test structures.
A typical (simplified) hierarchy may look like:
top
core
processor
system_logic
peripheral_1
peripheral_N
subsystem_M
io
pad_X
funcmux_X
testmux_X
jtag_X
pad_cell_X
pad_Y
pad_Y
A peripheral peripheral_1 may be hooked to pad_X, requiring 1 wire for a straight output or input pad, or 2 wires for a tristate-able output pad, or 3 for a bidirectional pad, or more for more complex electrical configurations of the pad. That bundle of N wires would travel up the Verilog hierarchy from peripheral_1 to top and down to the required pad logic, via any additional logic controlling pad multiplexing or test. The hierarchy above is just one example.
In an SoC, that's a lot of wires in total, and is very error-prone to do manually. An automated EDA IP assembly tool can be used.
*In standard-cell SoC design flows, the pad is just another cell.
The exact arrangement may be dictated by your cell library and/or physical design flow.
I have a question recarding the capability of the combination of different chips.
We have a PIC16F1824 microchip controller, is it possible to connect this with the bluetooth module from http://www.microchip.com/pagehandler/en-us/technology/bluetooth and read data from a chip, which is connected with this microchip controller ?
Thanks in advanced!
With kind regards,
Tim
Yes, both the PIC and the bluetooth module have a UART interface. The only thing you need to be careful of is if they use the same supply voltage. If not, look through the data sheets to ensure that the I/O pins on both devices will tolerate the I/O voltage mismatch. The most common case is a 3.3V device with inputs that are not tolerant of 5V logic.
How can I configure one pin for input and another for the output?
If I am not wrong this could be done with GPIO registers that controlls device pins that are not connected to peripherical functions.
Look in UM10360.PDF, Chapter 9: GPIO. There you can find the description for the FIOxDIR direction registers, as well as the reigisters for querying, setting and clearing GPIO pins.
I also strongly recommend looking at the CMSIS Standard Peripherial Driver Library that NXP offers for 175x/176x, look in microcontroller support documents. Edit: There are lots of sample code in this Library.
https://github.com/dwelch67
I have a number of lpc based examples. You are looking for the IODIR register, depending on the port and flavor of LPC, there are now what they call fast I/O registers. a one in a bit location means that pin is an output, a zero an input.
I have a device that takes low current 3-12v input signal to do it's magic and I would like to interface it to my linux box. What kind of options do I have on this? It would be great to have some low-cost possibly user-space solution.
If I understand right, you need to control your box by changing 3-12v input signals to it. Here's the choices I can think of from the top of my head:-
a: Using RS232 serial handshake lines. RTS/CTS can usually controlled programatically as "on/off" signals without driver development using IOCTL calls.
b: Use a "GPI dongle" such as the Advantech ADAM range. These typically take serial or TCP/IP inputs and convert them to suitable output signals.
c: You may be able to do something with a parallel printer port if your PC stil has such a thing.
As shodanex says, be aware that RS232 levels are NOT directly compatible with TTL/CMOS inputs so you may need some minor level shifting/clamping electronics to fix this.