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.
Related
Im working on a STM32F411CEU6 using STM32CubeIDE, Im making a library that works whit UART interruption, inside the UART interruption Im using the HAL_GetTick function to keep track of time, when I use this function outside the interruption It work properly, but when I try to use it inside the interruption the uwTick halt.
I understand that uwTick is a global variable that is incremented on interruption, my first guess was that the UART interruption had greater priority over the System tick timer interruption (I'm guessing that this interruption is the one that trigger the uwTick increment), but the System tick timer interruption has a higher interruption in the pinout configuration UI.
What is going on?
Should I change my approach and use a timer (reading the counter inside)?
additional information:
-Im triggering the interruption whit the HAL_UART_Receive_IT(&huartx, &USART_receive[0], 1), where USART_receive is a receive buffer
-The function that use the HAL_GetTick function is being call in the void USART1_IRQHandler(void) handler after the HAL_UART_IRQHandler(&huart1) function
Thanks in advance!
A higher interrupt priority is represented by a lower number and vice-versa. Maybe you need to switch the priorities around to do what you want.
However, please note:
It is conventional for systick to be one of the lowest priority interrupts in the system, with only pendsv/svcall lower.
It is generally considered a bad idea to try to delay within an interrupt, especially for several milliseconds. It is probably better to set a flag or something in the interrupt and let your main context carry out the delayed action.
I am a newbie to both FreeRTOS and STM32. I want to know how exactly callback function HAL_UART_TxCpltCallback for HAL_UART_Transmit_IT works ?
Can we edit that that callback function for our convenience ?
Thanks in Advance
You call HAL_UART_Transmit_IT to transmit your data in the "interrupt" (non-blocking) mode. This call returns immediately, likely well before your data gets fully trasmitted.
The sequence of events is as follows:
HAL_UART_Transmit_IT stores a pointer and length of the data buffer you provide. It doesn't perform a copy, so your buffer you passed needs to remain valid until callback gets called. For example it cannot be a buffer you'll perform delete [] / free on before callbacks happen or a buffer that's local in a function you're going to return from before a callback call.
It then enables TXE interrupt for this UART, which happens every time the DR (or TDR, depending on STM in use) is empty and can have new data written
At this point interrupt happens immediately. In the IRQ handler (HAL_UART_IRQHandler) a new byte is put in the DR (TDR) register which then gets transmitted - this happens in UART_Transmit_IT.
Once this byte gets transmitted, TXE interrupt gets triggered again and this process repeats until reaching the end of the buffer you've provided.
If any error happens, HAL_UART_ErrorCallback will get called, from IRQ handler
If no errors happened and end of buffer has been reached, HAL_UART_TxCpltCallback is called (from HAL_UART_IRQHandler -> UART_EndTransmit_IT).
On to your second question whether you can edit this callback "for convenience" - I'd say you can do whatever you want, but you'll have to live with the consequences of modifying code what's essentially a library:
Upgrading HAL to newer versions is going to be a nightmare. You'll have to manually re-apply all your changes you've done to that code and test them again. To some extent this can be automated with some form of version control (git / svn) or even patch files, but if the code you've modified gets changed by ST, those patches will likely not apply anymore and you'll have to do it all by hand again. This may require re-discovering how the implementation changed and doing all your work from scratch.
Nobody is going to be able to help you as your library code no longer matches code that everyone else has. If you introduced new bugs by modifying library code, no one will be able to reproduce them. Even if you provided your modifications, I honestly doubt many here will bother to apply your changes and test them in practice.
If I was to express my personal opinion it'd be this: if you think there's bugs in the HAL code - fix them locally and report them to ST. Once they're fixed in future update, fully overwrite your HAL modifications with updated official release. If you think HAL code lacks functionality or flexibility for your needs, you have two options here:
Suggest your changes to ST. You have to keep in mind that HAL aims to serve "general purpose" needs.
Just don't use HAL for this specific peripheral. This "mixed" approach is exactly what I do personally. In some cases functionality provided by HAL for given peripheral is "good enough" to serve my needs (in my case one example is SPI where I fully rely on HAL) while in some other cases - such as UART - I use HAL only for initialization, while handling transmission myself. Even when you decide not to use HAL functions, it can still provide some value - you can for example copy their IRQ handler to your code and call your functions instead. That way you at least skip some parts in development.
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.
I have a question about a char driver.
A char driver using GPIO pins to communicate with a hardware device, including interrupt interfacing.
The driver's "release ()" method is missing.
What order should function elements put in?
A. Delete cdev and unregister device
B. Free GPIO Resources
C. freeing IRQ resource
D. Unregistrer major / minor number
In which order in the "release()" method?
Thanks
As per my understanding correct order looks like C, B, A and D :-). Explanation: Need to free the IRQ since gpio pin (used as an interrupt pin), IRQ number is got from passing this gpio pin to gpio_to_irq and after this only you can go ahead in freeing up the gpio stuff. After that deletion of cdev come into picture to which file operations, device node info(dev_t, 32bit unsigned integer. In which 12 bit is used for major no and remaining 20 bit is used for minor no) and minor number info (minor no start value and how many minor no's asked for) are associated. At-last go ahead and unregister the driver.
Actually, some of these things may be done in the release() function, and some of these things must be done in the module_exit() function. It all depends on what you do where.
First, some terminology: module_init() is called when the module is loaded with insmod. The opposite function is module_exit() which is called when the module is unloaded with rmmod. open() is called when a user process tries to open a device file with the open() system call, and the opposite function release() is called when the process that opened the device file (as well as all processes that were branched from that original process) call the close() system call on the file descriptor.
The module_exit() function is the opposite of the module_init() function. Assuming you are using the CDev API, in the module init function you must register a major / minor numbers (D) first with alloc_chrdev_region() or register_chrdev_region() before adding the cdev to the system with cdev_init() and then cdev_add().
It stands to reason that when module_exit() is called, you should undo what you did in the reverse order; i.e. remove the cdev first with cdev_del() and then unregister the major/minor number with unregister_chrdev_region().
At some point in the module_init() function you may request the GPIO resources with request_mem_region() & ioremap(), and then the IRQ resource with request_irq(). On the other hand you may request the GPIO resources and the IRQ resource in the open() function instead.
If you request these resources in the module_init() function, then you should release these resources in the module_exit() function. However, if you do it in open() then you should keep track of how many processes have the device file open, and when all of them have released the device file, release the resources in the release() function.
Again, whatever order you requested the resources in, in general you should release the resources in the opposite order. I will say however, that almost always it is incorrect to release the memory resources (in your case the GPIO resources) before releasing the IRQ resource, since the IRQ will most likely want to talk to the hardware, either in the top half or the bottom half handler.
In summary, the order depends on how you implemented the driver to request the resources in the first place, however, if you implement your drivers like I do, then in general, perform C then B in release(), and perform A then D in module_exit().
I am writing a device driver for a custom piece of hardware using the Linux kernel 2.6.33. I need am using DMA to transfer data to and from the device. For the output DMA, I was thinking that I would keep track of several output buffers using the Linked List API (struct list_head, list_add(), etc.).
When the device finished the DMA transfer, it raises an interrupt. The interrupt handler would then retrieve item in the linked list to transfer, and remove it from the list.
My question is, is this actually a safe thing to do inside of an interrupt handler? Or are there inherent race conditions in this API that would make it not safe?
The small section in Linux Device Drivers, 3rd Ed. doesn't make mention of this. The section in Essential Linux Device Drivers is more complete but also does not touch on this subject.
Edit:
I am beginning to think that it may very well not be race condition free as msh suggests, due to a note listed in the list_empty_careful() function:
* NOTE: using list_empty_careful() without synchronization
* can only be safe if the only activity that can happen
* to the list entry is list_del_init(). Eg. it cannot be used
* if another CPU could re-list_add() it.
http://lxr.free-electrons.com/source/include/linux/list.h?v=2.6.33;a=powerpc#L202
Note that I plan to add to the queue in process context and remove from the queue in interrupt context. Do you really not need synchronization around the functions for a list?
It is perfectly safe to use kernel linked lists in interrupt context, but but retrieving anything in interrupt handlers is a bad idea. In the interrupt handler you should acknowledge interrupt, schedule "bottom half" and quit. All processing should be done by the "bottom half" (bottom half is just a piece of deferred work - there are several suitable mechanisms - tasklets, work queue, etc).