FreeRTOS Real Time Kernel (RTOS) Discussion; FreeRTOS Real Time Kernel (RTOS) Market leading real time kernel for 35+ microcontroller architectures. PIC32 UART Driver Accessing From Queue Task Forum: Open Discussion and Support. Creator: Scott Olson. ChibiOS Free Embedded RTOS. Skip to content. FAQ; Logout; Register; Board index Support Section STM32 Support. I general, when using the UART driver, I don't see any reason to change interrupt settings, you should focus on the protocol you want to implement not on the low level details.
Hi All: I am unable to communicate with UART A & UART B on the Easy MX Pro v7 Board. Any help would be greatly appreciated. I am using TI's Code Composer and am able to successfully debug the code running on the board. Thus, communications from Code Composer to the Board is fine.
I configured UART 2 in Code Composer and enabled the PINS PD4 & PD5 for UART A. I configured UART 7 in Code Composer and enabled the PINS PC4 & PC5 for UART B. On the MX Pro v7 board: SW-5 1,2,3,4 are set to the ON Position. SW-12 1-8 are set to the OFF Position.
(Although I have toggled 3 & 4 just to see what happens.) I am using an 'internet' USB Serial Terminal program. I have used the program quite successfully with MicroChip and other TI processors. When I hit a key on the keyboard, I see the RX LED flash on the MX Pro board on each UART. I have to move the cable; but, each RX LED does lights up. Thus, it 'seems' that the program, driver and connection that I am using may be OK. I would expect to see the TX LED light for both UARTS constantly flashing. They are not.
Connected to the USB cable to not. The program is set up to constantly output 'Hello, World'. Thus, I 'think' TX should constantly flash. In checking the Returns from UARTopen and UARTwrite, there are no invalid return codes. Needless to say, I am using TIRTOS along with the TI UART drivers. The board is being powered by the USB cable.
The program was compiled/liked using TM4C129XNCZAD settings. As another test, I used the actual PORT PINS on the MX Pro to see what would happen. I made changes to SW-5 and SW-12 as needed. I connected them to a TTL 'chip'. As I have with other chips. I stole the +5V from the Micro Bus power port. I have been using an older Tiva board quite successfully.
I have had very similar code running on the TM4C123X chips/boards. I ran out of ports and needed more power. I thought I would try the MX out.
![Uart Driver Free Rtos 8051 Uart Driver Free Rtos 8051](https://www.bing.com/th?id=OGC.371bfa474ecc4e031a5a376043f534d3&pid=1.7&rurl=https%3a%2f%2fexploreembedded.com%2fwiki%2fimages%2f7%2f73%2fADC.gif&ehk=%2bN66DCz49fd4SIUm0t2A7g)
I'm not seeing the problem. Is there a switch on the board that I missed? Is there a Code Composer system variable that I need to set for the MX Pro board? Again, any thoughts would be greatly appreciated. I'll be more than happy to post the code that I am using. Hi Rick, Welcome to mikroE forum.
Unfortunately we don't use Code Composer. I can recommend you to try USB UART examples from our compiler: Mikroelektronika mikroC PRO for ARM Examples TI Development Systems EasyMx PRO v7 for TIVA Examples USB UART A Mikroelektronika mikroC PRO for ARM Examples TI Development Systems EasyMx PRO v7 for TIVA Examples USB UART B This simple examples demonstrates usage of UART on EasyMx Pro for Tiva through a 'loopback' interface. When you write some data Through UART it will be back to you. Note that you should turn USB Uart switches on board(SW5.1. For UART A and SW5.3. Regards, Darko. Hi Darko: I ordered and received the TM4C1294XL board from TI.
It has a TMC4129NCPDT chip installed. I have no problems with this board using the proper compiler settings and a MAX232 TTL/UART converter chip. It runs great. I used 3 UARTS at the same time with no issues. I was able to get this running within an hour. The MX Pro Board chip that I am using is a TM4C129XNCZAD chip.
I re-wrote the same program and I used proper compiler settings. SW.1 through SW.4 were set to the 'ON' position. I can get the RX lights to light when I hit the keyboard; but, the TX lights do nothing. I can not get USB UART-A nor UART-B to work. I turned SW.1 - SW.4 OFF and tried to use the Port C and Port D Pins directly with the MAX232. The issue that I had here was that I could not find a 5V+ on the MX Pro Board to power the MAX232 chip.
I used the Miko Bus +5V; but this were only putting out 4.2V. I'm not sure I had enough power for the MAX 232 chip. I can download the CodeComposer program to the MX Pro board and debug it normally.
This works as desired. I can not debug in to the TI UART drivers. The returns from the driver calls (Open, Write, etc.) all appear to be fine. The MX Pro hardware provides some very nice features that the TI LaunchPads do not. However, I like the TI-RTOS CodeComposer environment. I'm just not sure I like the idea of switching development environments in order to line up with the hardware manufacturer.
It seems like I should be able to use the Code Composer with the MX Pro Board. Do you have any thoughts about next steps? Would you like to see the.out and.map files? Hi Aleksandar: Thank you for the tip on trying to use the example provided.
The Mikro example provided 'appears' to be a.cproject or a TI Code Composer project. I really do not understand how you can say that Mikro is not familiar with Code Composer. From the.cproject files: // CodeComposer 6.10 Example // EasyMXPro Example The release versions are fairly different and the Mikro example appears to be very old. The problem with the example is that the code provided does not compile when using updated Properties for the chip that I am using. Do you have a compiled UART example, with my chip, that I can use for Testing?
The example can definitely be a Mikro compiled program. I'll use the MikroProg utility to program the chip. I just want to see the UARTS on the board running. I do not have confidence that I can use the TI Development environment even though your marketing says that I can.
My options are: A. Mikro tech support digs a little deeper to figure out what is going on. I doubt that Mikro will do this since the answers provided thus far have been generic and basic. I sell the Easy MX Pro Board on eBay and stay with generic TI hardware and software. I rewrite all of my code using the Mikro compiler. I am open to Option 'C'; but, I want to talk to Sales directly about this.
Can we take this out of the public forum to talk about this directly? You should have my email address. I appreciate your consideration in this matter. // CodeComposer 6.10 Example // EasyMXPro Example I tested this example for UART on EasyMx PRO v7 board and TM4C129XNCZAD MCU and all worked well. In attachment you will find.hex file for testing both UART's.
Just download.hex with mikroProg Suite for ARM and program your MCU with board programmer. Do not forget to turn on switches on SW5 from 1 to 6. Regards, Aleksandar Attachments: 6.69 KiB Downloaded 83 times. Hi Aleksandar: In the EasyMXUART.zip file there is a file called.cproject. I found the lines in question in that file.
With you saying that the example works and the TI support forums saying to 'strip out TI-RTOS', I am pretty sure TI-RTOS may be the offender here. I need a bit of time to validate. I really like the various TI drivers and I do not know if I can use them without TI-RTOS. In other words, if I stop using TI-RTOS, will I have to also take the drivers out? (probably) Thank you for your help and your quick reply. Hi Filip: The program is running fine with Code Composer. TI replaced the SysCtlClockSet function with SysCtlClockFreqSet for the TM4C129 chip sets.
I used the SysCtlClockGet return as input into the UART routine. Another mistake. This routine will not work either. Thus, the EasyMXUART example will not work with the MX Pro board if it has a TM4C129 chip. I had to strip out the TI-RTOS code to get this running. Many thanks to Mikro team!
I just needed a few hints. Please close this ticket.
This site required JavaScript to be enabled. Below is a static menu. How FreeRTOS Works. FreeRTOS Interactive!
Hello FreeRTOS forum! I am in the process of designing a platform using FreeRTOS, and I am scratching my head about how to best implement the serial communication. There are going to be as many as five UARTs live, and potentially communicating simultaneously. The baud rates are however not very high, typically 9600 baud, but I would like to have the opportunity to go faster one day. The chip is a HCS12XET256 with cpu clock = 73.7 MHz and 8 KB ram (without paging), and most time will be spend waiting for activity on UART(s). I would like to have a modular design, such that I can hook my high level drivers to any of the UARTs.
My first thought was to simply implement the lowlevel UART drivers with FreeRTOS message queues. That would mean five transmit queues, and five receive queues that simply transfers the data bytes directly. I would get deferred processing and UART abstraction out of the box with minimum effort. But then I read in the FreeRTOS book on page 89 that 'passing individual characters through a queue is extremely inefficient. And not recommended for production code' and I began thinking about other ways to implement the lowlevel driver. In any case I need to have a buffer that the receive ISR can dump bytes in. And, in any case, I need to make the ISR let other tasks know that there is fresh data in the buffer.
So if I roll my own receive buffer and use a semaphore for signalling (which is a minimal message queue), am I not back to the same amount of overhead as the original message queue idea? Any comments would be appreciated:) Best regards, Lars RE: Best way to implement generic UART driver. I'm not sure what is available on your HCS12, but an efficient way would be to have a DMA pass data to and from the UART and a circular buffer. Then have the DMA interrupt use a semaphore to unblock tasks when there is enough data to make it worth processing.
If no DMA is present then hopefully there are at least some FIFOs. The best approach to take is naturally dependent on the characteristics of your application, these are just suggestions.
RE: Best way to implement generic UART drivers? I'm trying to use FreeRTOS port for PIC18F devices for past couple of weeks now.
PIC18F65J50 has two UART's and code I wrote for low and high level drivers works with no problems on 19200 on both ports using queues in two stages. First stage writes/reads single characters from Tx/Rx ISR to queue. Second stage writes/reads strings (ended with CR/LF or just CR) from one queue to corresponding queue on the first stage. One ISR and two separate tasks for handling asynchronous serial communication works fine on PIC18F with 48MHz internal clock (12MIPS). Besides this there is USB driver task, IO processing task and work dispatcher task that coordinates everything. The only thing that really slows down development are some FreeRTOS internal 'bugs' probably related to PIC port, i.e.
TaskYIELD not working, timeout in queuesend and queuereceive not working etc. I have lost a lot of time assuming these, and some other things, work as expected.
Anyway, I might post code for UART driver when I get time, best thing is that it is not platform specific (except in 3-4 lines of code) since it relies entirely on FreeRTOS architecture.