I'm working on a project where I want to install a photodetector circuit to a computer through some sort of interface (preferably USB). However, since I am new at this so I do not know in what direction that I should approach this problem on. Assuming I have a photodector circuit with a USB connection, does the "interfacing" require only writing the device driver? Or do I need to do any additional work? Please advise if I am overlooking something. Thanks!
The easiest way to communicate with your computer would be using an integrated circuit that does all the communication for you. Take a look e.g. at the FTDI FT232 Chip. It is extremly simple to use as it emulates a virtual COM port in the basic mode (USB drivers for all major platforms are included). So the only thing you would have to do on the PC side would be writing to the serial (COM) port.
Then your microcontroller circuit can simply communicate with this chip via UART, which is supported by almost every controller (e.g. Atmel ATmega series).
Alternatively you can simply use your real RS232-Port, but many modern computer don't have such a port anymore.
The simplest one possible is obviously through the LPT port.
Out of its 25 pins, 8 are available for input/output and can be connected to any sort of electronic device... including your custom PCB.
It takes simple values :
0 - 00000000
1 - 00000001
2 - 00000010
3 - 00000011
.
.
.
.
255 - 11111111
Check this out for pinouts http://t3.gstatic.com/images?q=tbn:ANd9GcTQy9wmJzTBVAJjMwEdavBoypcwFOXwQ-sA5E2aR-dBLyn1_DDRfg
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'm currently starting to use ThreadX on a STM32 Nucleo-H723ZG (STM32H723ZG MCU).
I noticed that when loading the Nx_TCP_Echo_Server / Nx_TCP_Echo_Client projects from CubeMX, the RAM gets filled up pretty much to the top, which makes me wonder, how I'm supposed to add my own code and data here.
Since I'm pretty new to RAM partitioning, RTOS and similar, I don't have a perfect feeling for what is wrong or right and how to proceed (and if it is a problem at all).
Nevertheless I wonder, if maybe using a different way of partitioning the RAM or by dropping some non-necessary code-parts, the RAM could be freed-up.
Or a different way of thinking:
Since RAM_D1 got filled, but _D2, _D3 and DTCMRAM are pretty much empty, is there a way to use the free RAM for my own purposes (I would like to let SPI and ADC processing run via DMA, so this needs a place to go ....)
Hope my questions are not too confusing ;)
The system has the following amount of RAM, according to STM:
"SRAM: total 564 Kbytes all with ECC, including 128 Kbytes of data TCM RAM for critical real-time data + 432 Kbytes of system RAM (up to 256 Kbytes can remap on instruction TCM RAM for critical real time instructions) + 4 Kbytes of backup SRAM (available in the lowest-power modes)" (see STMs STM32H723ZG MCU product page)
Down below you'll find screenshots of the current RAM usage, for RAM_D1 especially .tcp_sec eats up most of the RAM.
--> Can .tcp_sec be optimized or kicked-out?
If tcp means here the tcp protocol, maybe this can be a way to optimize this, since I'm not sure whether I need a handshake etc., maybe UDP is sufficient (and faster for the ADC data streaming) ... what do you say?
Edit:
The linker-file shows, that there .tcp_sec (NOLOAD) is written ... is NOLOAD maybe a hint on a "placebo" RAM occupation (pre-allocation / reservation, but no actual usage?)
Linker-script extract:
/* User_heap_stack section, used to check that there is enough RAM left */
._user_heap_stack :
{
. = ALIGN(8);
PROVIDE ( end = . );
PROVIDE ( _end = . );
. = . + _Min_Heap_Size;
. = . + _Min_Stack_Size;
. = ALIGN(8);
} >RAM_D1
.tcp_sec (NOLOAD) : {
. = ABSOLUTE(0x24048000);
*(.RxDecripSection)
. = ABSOLUTE(0x24048060);
*(.TxDecripSection)
} >RAM_D1 AT> FLASH
For context:
I am developing a "system controller", where my plan is to have it running a RTOS, which manages the read-in of analog values, writing control messages via SPI to two other STMs of the same kind and communicating via Ethernet to my desktop application.
The desktop application is then in charge of post-processing the digitized analog values and sending control messages to the system controller. In the best case the system controller digitizes the analog signal on ADC3 with 5 MSPS (at probably 6 Bit resolution = 30 MBit/s) and sends that data hickup-free to my desktop application.
-> Is this plan possible on this MCU?
I tried to buy a higher (more RAM) version of the nucleo I've got, but due to shortages this one is the best one I was able to get.
For the RTOS I'd like to stick with ThreadX, since FreeRTOS support in STM32IDE seems to be phased out now, after ThreadX was employed as the RTOS by STM.
(I like the easy register configuration using CubeMX/STM32 IDE, hence my drive to use that SW universe ... if there are good reasons to use a different RTOS, tell me :) )
Thank you for your time!
I generated the same project on my side and took a look. I believe you should be able to implement what you want in this CPU. You will need to carefully use the available memory.
It seems there is a confusion about the section .tcp_sec. It contains DMA reception and transmission descriptors for the Ethernet controller/driver. These are constrained by the driver and hardware to be at a specific address. The descriptors are rather small, but the buffers are bigger. With some work these can be reduced. If you are using Ethernet you will need this, no mater if you use TCP or not. As I said, the name can be confusing.
The flash has still plenty of space available. In the debug configuration only about 11% is used. The rest is available for your application code.
You can locate you data in other memory regions. Depending on the toolchain you will use is how you will need to tell the compiler/linker where your data goes. You can look towards the top of the main.c file in that example to see how the DMA descriptors are assigned to a specific section for three different toolchains (IAR, ARM MDK, GCC).
In terms of how to most efficiently use and configure the microcontroller peripherals please get in touch with STMicro, they will know best.
This should get you started. Let us know if this helps!
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!
describe how a JTAG connection is used to test the circuitry in a chip using just 5 pins
JTAG is used as a synonyme for the boundary scan protocol, see
- https://en.wikipedia.org/wiki/JTAG#Boundary_scan_testing
- https://en.wikipedia.org/wiki/Boundary_scan
It was the Joint Test Action Group (JTAG) who originally devised this protocol for testing circuitry around chips.
Besides this original purpose, the same protocol is used to program and debug CPUs, FPGAs etc.
In order to use JTAG, you need an adapter device that supports the circuitry you would like to test/debug.
[...] using just 5 pins
You are wondering how to test the entire chip through "just" 5 pins? To get a rough idea, think of a shift register similar to UART and SPI (but keep in mind that JTAG is notably more sophisticated).
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.