I am trying to find if an inout port is used as an input port or as an output port during simulation from my PLI based C-code. How can it be done?
Before you go down this path, note that most tools have capabilities to give you this information with Extended VCD files or in other formats usually associated with power estimation tools.
Doing this withe the VPI requires extensive knowledge of the §38 VPI routines and §36 VPI object model diagrams in the 1800-2012 LRM. I can give you an outline of what needs to be done:
For each inout port
Register a cbValueChange callback using vpi_register_cb
Build a list of drivers using the diagram §37.16 Nets
Classify each driver as being outside the module (HiConn) or inside (local or LoConn)
The callback routine needs to scan the list of drivers for the port that changed value
If the active driver is outside the module, the port is in input mode.
If the active driver is inside the module, the port is in output mode.
Related
For a work project, I have to read a bunch of holding registers from an IFM CR1203 PLC that is programmed using CODESYS 3.5.
The PLC will be running a slave instance and the device reading the holding registers will be a PC running a custom application programmed in Javascript to be a client. I have already programmed MODBUS TCP/IP functions for the custom application that is tested and works (For a previous project I had to do the same for a different PLC programmed using a different platform).
My current issue is that I need the raw memory address of the first holding register to do this, but I can't find it on the CODESYS IDE. CODESYS uses an addressing system that makes it easy for different CODESYS-based devices to communicate. Here is a link that explains how it works: CODESYS MODBUS register location guide
The only thing that looks like it can work is from the link above:
<memory position> : <number> ( .<number> )* // Depends on the target system
But I don't fully understand what all that means.
I also can't find any documentation on the PLC or CODESYS that explains this topic in enough detail. Here is a snippet of dummy code used for testing that shows the CODESYS addresses:
Can someone please explain to me how I can convert the value %IW0 to a raw memory address, for example, 0xFFFF?
I use Machine Expert (Codesys 3.5.16) and in their documentation says:
The I/Os are mapped to Modbus registers from the master perspective as follows:
%IWs are mapped from register 0 to n-1 and are R/W (n = Holding register quantity, each %IW register is 2 bytes).
%QWs are mapped from register n to n+m -1 and are read only (m = Input registers quantity, each %QW register is 2 bytes).
So in your example they should be address 0 and 1.
I am in the process of programming some sort of USB oscilloscope.
I followed the tutorial, using a STM32F429.
https://www.youtube.com/watch?v=MmwR1VU_rVc&list=PLnMKNibPkDnHxpOv2HETihQy5HHQGv2nS&index=26
The tutorial was very helpful with this and I am able to use the software from the tutorial (stmscope) to see the incoming data.
However, I would like to process the data in Matlab, where my problems start. As far as I understand the baudrate does not matter, because there is no real UART connection?
For reading the UART in another project I used for example "Putty" or "SerialMonitor". By specifying the baudrate and the com port the readout was quite easy, even in Matlab.
The used USB port is simulated as a virtual com port and the data is sent with CDC_transmit. However, with the previous methods "Putty" or "SerialMonitor" I cannot read the sent data, because I have to specify a baudrate for this, which is unknown to me. Which program is suitable to monitor the incoming data?
In Matlab I also have the same problem that I have to specify a baudrate for the com port.
My goal is to evaluate the data in Matlab. Preferably I would like to read the data directly with Matlab from the virtual com port and save it in Matlab. If this is not possible I would first save the data to a txt.file and then read it into Matlab.
Are there any ready-made solutions or open source programs for this?
Thanks for reading and your help!
I am looking to have the processor read from I2C and store the data in DDR in an embedded system. As I have been looking at solutions, I have been introduced to Linux device drivers as well as the GNU C Library. It seems like for many operations you can perform with the basic Linux drivers you can also perform with basic glibc system calls. I am somewhat confused when one should be used over the other. Both interfaces can be accessed from the user space.
When should I use a kernel driver to access a device like I2C or USB and when should I use the GNU C Library system functions?
The GNU C Library forwards function calls such as read, write, ioctl directly to the kernel. These functions are just very thin wrappers around the system calls. You could call the kernel all by yourself using inline assembly, but that is rarely helpful. So in this sense, all interactions with the kernel driver will go through these glibc functions.
If you have questions about specific interfaces and their trade-offs, you need to name them explicitly.
In ARM:
Privilege states are built into the processor and are changed via assembly commands. A memory protection unit, a part of the chip, is configured to disallow access to arbitrary ranges of memory depending on the privilege status.
In the case of the Linux kernel, ALL physical memory is privileged- memory addresses in userspace are virtual (fake) addresses, translated to real addresses once in privileged mode.
So, to access a privileged memory range, the mechanics are like a function call- you set the parameters indicating what you want, and then make a ('SVC')- an interrupt function which removes control of the program from userspace, gives it to the kernel. The kernel looks at your parameters and does what you need.
The standard library basically makes that whole process easier.
Drivers create interfaces to physical memory addresses and provide an API through the SVC call and whatever 'arguments' it's passed.
If physical memory is not reserved by a driver, the kernel generally won't allow anyone to access it.
Accessing physical memory you're not privileged to will cause a "bus error".
BTW: You can use a driver like UIO to put physical memory into userspace.
As I know, If one creates a raw socket (with type of SOCK_RAW) and binds it to a network interface, he can receive all the IP traffic on that interface only by using the recvfrom function.
But, in many examples for sniffers I saw a call to the winsock's function WSAIoctl with control code SIO_RCVALL to perform.
So, what's the purpose of that control mode in the mission of sniffing?
Read the documentation. SIO_RCVALL is what enables the NIC to be sniffed, and to some extent what level of sniffing is allowed.
I am trying to send/retreieve data from/to FPGA using Matlab. I connected FPGA using Virtual com port. Now how to send data from Matlab to FPGA or read data of FPGA ?
FTDI 2232H is on the FPGA as well. I connected external LED's and switches on the I/O ports of the FPGA.
I am new in this field, so want some guideline to start communication b/w MAtlab and FPGA:
I tried following code:
s1= serial('COM9')
fopen(s1)
. Is it the right way to communicate ? Kindly guide. thanks
FPGA's are configured using a Hardware Description Language (HDL) such as Verilog or VHDL. These languages let you specify how the switch configuration within the FPGA, which in turn lets you construct your custom digital logic and processing system.
The HDL Coder Toolbox in Matlab lets you design and prototype your custom logic using higher-level functions, which are then translated into HDL and can be be used to directly program your chip. This tutorial describes the process in detail.
If you already have a design implemented on your FPGA and want to communicate with that implementation, you would use Matlab's serial port communication functions. The exact protocol will depend on the interface you have implemented.
Some intermediate debugging steps I find helpful:
Verify that you can send serial port data from your computer. In Windows XP, you can do this easily with HyperTerminal, and hooking up a scope to the output pins of your serial cable. Set up a trigger to capture the event. For Windows 7 and newer, you'll need to download a HyperTerminal client.
Repeat this same process with Matlab. Using a scope, verify that you see the serial port signal when sent from Matlab, and that the output matches the results from step 1. Again, set up a scope trigger to capture the event.
Now connect the serial cable directly to the FPGA board. Modify your HDL to include a latch on the serial input that displays the output on the LED's. Verify that your board initializes to the correct LED state, and that the LED state changes when you send the serial message.
Lastly, verify that you are interpreting the message correctly on the FPGA side. This includes making sure that the bit-ordering is correct, etc. Again, the LED outputs can be very helpful for this part.
The key here is to take small, incremental steps, physically verifying that things are working each step of the way.