I need to write to a register to kick a device out of boot and into application mode for the using I2C on the ST-Nucleo-F767ZI. I am currently using the ST provided HAL function HAL_I2C_Mem_Write to write data to registers, but this function requires the data to not be NULL. What is the correct way to ping a register using the ST HAL? Is it HAL_I2C_Master_Transmit?
The answer to the above question is that yes - the correct way to handle a ping of a register is via the HAL_I2C_Master_Transmit. This function will transmit the data provided - in this case the register address on the device. The HAL_I2C_Mem_Write function is a higher level function which expects that the caller is writing data to the register; hence, in the function itself if the input size is 0 or pData is NULL, then the driver will throw HAL_ERROR.
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 new to STM32 and freertos. I need to write a program to send and receive data from a module via UART port. I have to send(Transmit) a data to that module(for eg. M66). Then I would return to do some other tasks. once the M66 send a response to that, my seial-port-receive-function(HAL_UART_Receive_IT) has to be invoked and receive that response. How can I achieve this?
The way HAL_UART_Receive_IT works is that you configure it to receive specified amount of data into given buffer. You give it your buffer to which it'll read received data and number of bytes you want to receive. It then starts receiving data. Once exactly this amount of data is received, a callback function HAL_UART_RxCpltCallback gets called (from IRQ) where you can do whatever you want with this data, e.g. add it to some kind of queue for later processing in the task context.
If I was to express my experiences related to working with HAL's UART module is that it's not the greatest one for generic use where you don't know the amount of data you expect to receive in advance. In the case of M66 modem you mention, this will happen all the time.
To solve this you have two choices:
Simply don't use HAL functions at all in case of UART, other than the initialization functions. Implement your own UART interrupt handler (most of the code can be copied from handler in HAL) where upon receiving data you place received bytes in a receive byte queue handled in your RTOS task. In this task you implement protocol parsing. This is the approach I use personally.
If you really want to use HAL but also work with a module that sends varying amount of data, call HAL_UART_Receive_IT and specify that you want to receive 1 byte each time. This will work, but will be (potentially much) slower than the first approach. Assuming you'll later want to implement some tcp/ip communication (you mentioned M66 GPRS module) you probably don't want to do it this way.
You should try the following way.
Enable UARTX Rx interrupt in NVIC.
Set Interrupt priority.
Unmask Interrupt request in EXTI.
Then use USARTX Interrupt Handler Function Define in you Vector.
Whenever the data is received from USARTX this function get automatically called and you can copy data from USARTX Receive Data Register.
I would rather suggest another approach. You probably want to archive higher speeds (lets say 921600 bods) and the interrupt way is fat to slow for it.
You need to implement the DMA transmition with the data end detection features. Run your USART in the DMA mode in the circular mode. You will have two events to serve. The first one is the DMA end of thransmition interrupt (then you copy the data from the current tail pointer to the end of the buffer to avoid data override) and USART IDLE interrupt - this will detect the end of the receive.
As we all know,the Hal Lib provides some callback function to manage hardware interrupt.But i don't know how them work?
Te fact is that I am using HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) this function so as to receive other devices' data and check those data.So I use the usart interrupt to receive them.
But I don't know when the callback function will be executed,is it depends on the receive buffer's length or the data's buffer?
I guess the hardware interrupt will be triggered while a character has been received,but the callback function will be executed after the receive buffer is full.
PS:I am using the stm32-nucleo-f410 development board to communicate with an AT commend device,and I am a novice about it.
(So sorry for my poor English!)
Thanks a lot.
The callback you are referring to is called when the amount of data specified in the receive functions (the third argument to HAL_UART_Receive_IT). You are correct that the UART interrupt service routine (ISR) is called every time a character is received, but when using the HAL that happens internally to the library and doesn't need to be managed by you. Every time the ISR is called, the received character is moved into the array you provide via the second argument of HAL_UART_Receive_IT, and when the number of characters specified by the call is reached, the callback will be called in that ISR (so make sure not to do anything that will take too much time to complete - ISRs should be short, and the ISRs in the HAL library are already pretty lengthy to handle every possible use case).
Further, if you find that the callback is not being triggered even if you are sending enough data to the peripheral, make sure the interrupt is actually enabled - the HAL_UART_Receive_IT function doesn't actually enable the interrupt, that has to be done during initialization of the peripheral.
Following is the definition of the probe function in the standard GPIO based MDIO bitbang driver
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,const struct of_device_id* match)
I can't figure out the purpose of __devinit in the above code.
Secondly when is the probe function called by the driver? May be when the driver is loaded itself. But it's not the part of driver init functions. Correct me if I am wrong?
There are lists maintained at the bus driver structure for the available devices on the bus and also the available drivers in the system which can support the devices on that bus.
Now when insert the module in the kernel. Only init_module will be called to do basic initialization w.r.t your driver, but when you insert your device, a match function which is part of the bus structure is called to check if the list of drivers has any driver which supports your device. Upon successful match the probe of your driver is called.
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.