Time is flying fast, time for another McuOnEclipse components release on SourceForge with the following main changes and features:
- New component for Segger RTT makes adding a console communication interface super easy (and fast!)
- RTT support for the command line Shell component
- RTT component used for Percepio FreeRTOS Tracing
- Updated USB component, support for USB CDC blocking/waiting and endpoint configuration
- Updated FreeRTOS to V8.2.3, memory heap selection improved and setting for time slicing
- RingBuffer implements a Delete() method
- Extended Kinetis SDK support in components, added by default
Segger RTT Console
Segger RTT Component
A new component has been added to the collection on components: SeggerRTT. This component implements the Segger Real Time Transfer (https://www.segger.com/jlink-rtt.html) in an easy-to-use component. Beside the usual Segger RTT methods (Read(), Write(), WriteString(), GetKey(), WaitKey() and HasKey()) it offers extra methods to be used for Standard I/O redirection and console or shell usage:
SeggerRTT Component
Using the properties, it is very easy to configure the Segger RTT:
SeggerRTT Properties
The Shell component supports RTT out-of-the-box:
Shell Component with RTT interface
If not using it as the default console interface, it can be used as an extra standard I/O like this with the Shell:
/* Segger RTT stdio */
static CLS1_ConstStdIOType RTT_stdio = {
(CLS1_StdIO_In_FctType)RTT1_StdIOReadChar, /* stdin */
(CLS1_StdIO_OutErr_FctType)RTT1_StdIOSendChar, /* stdout */
(CLS1_StdIO_OutErr_FctType)RTT1_StdIOSendChar, /* stderr */
RTT1_StdIOKeyPressed /* if input is not empty */
};
Using RTT, I have a way to communicate with my target without the need for UART, USB CDC or semihosting: I can do everything through the debug connection:
Example RTT Shell Session
This component is now used by the PercepioTrace component:
SeggerRTT in PercepioTrace
USB Component
The FSL_USB_Stack component has implemented a workaround to deal with bug in Processor Expert using the wrong USB_Init template.
Additionally there is now a configuration setting to specify the end point size for the in, out and notify endpoints.
The USB CDC component features now a setting to use a timeout and/or blocking/non-blocking wait in case the output buffer is empty.
USB CDC Additional Configuration Items
FreeRTOS V8.2.3
The FreeRTOS component has been updated to use the latest RTOS v8.2.3. This includes the new method xTaskNotifyClear() in the task notification API.
FreeRTOS V8.2.3
The FreeRTOS memory schemes are now more user-friendly to select, and the default is now Scheme 4:
FreeRTOS Memory Schemes
By default the RTOS is using time slicing in pre-emptive mode: I have added a setting to disable time slicing if this is required by the application:
FreeRTOS Time Slicing
RingBuffer
The RingBuffer component offers a new method Clear() to clear the buffer:
RingBuffer Clear
Extended Kinetis SDK support
To make using the Kinetis SDK possible with non-SDK components (see “Overview: Processor Expert“), it is necessary to add a KinetisSDK component to SDK projects. This component provides the necessary wrappers, defines and typedef’s to use most of ‘legacy’ Processor Expert components with the Kinetis SDK, as the Kinetis SDK uses an incompatible API. To make it easier to use components with the Kinetis SDK, and to make it ‘visible’ if they are supported with the SDK, I started adding the Kinetis SDK component to components by default:
KinetisSDK Component
For non-SDK projects that component has no effect. But it means that even if not using the SDK this component has to be present in the project. So if using the new components, you might need to update the components to reference that KinetisSDK component.
Summary
Adding Segger RTT is now my preferred method over semihosting: it is much faster and has a smaller footprint than semihosting. And having it as component makes it easier to share with other components.
The USB CDC component has now extended settings to customize and integrate it into my applications.
To support better the Kinetis SDK, the KinetisSDK component gets rolled out by default for components supported in combination with the SDK.
I hope these new features and extensions are useful for the many of you using the McuOnEclipse components.
The new components are available on SourceForge: https://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/
Happy Updating 🙂
Links
- Installing releases from SourceForge: McuOnEclipse Releases on SourceForge
- Segger RTT technology: https://www.segger.com/jlink-rtt.html
- Segger RTT Component: Using Segger Real Time Terminal (RTT) with Eclipse
- Segger RTT with Percepio Trace: FreeRTOS Continuous Trace Streaming
MCU on Eclipse 
One issue I’ve run into with RTT Viewer that has plagued me is that it refuses to scroll to the bottom when new text is received from the target. Meaning, I’ll give a command to the target, it’ll reply, and I’ll have to manually click the scroll bar in order to show the reply.
I’ve noticed that this occurs only when the text input bar is in focus – if the terminal window is in focus it will automatically scroll with new text. Have you noticed this, and if so are you aware of any simple fixes?
By the way, I just took five minutes to transition my project from using Segger’s sample RTT code to using your new component; I’m probably a bit too excited by how quick and easy it was to do.
LikeLike
Hi, Erich,
Awesome work on this collection of components. I was also very happy about the RTT component. Just one thing, though – I found that if I added extra channels (I especially wanted channel 1 for logging), the SEGGER_RTT.c file doesn’t get generated properly. The problem is that additional buffers aren’t defined for the extra channels, and of course they also need to be initialized in the _SEGGER_RTT control block. Not a big deal, but if you could fix this little bug, it would be greatly appreciated. Keep up the great work!
Thanks,
Jonathan
LikeLike
Yes, the Segger RTT expects that the application code initializes the buffers. For example my Segger SystemView component uses an extra buffer, and that buffer is initialized by the SystemView code. I think about your idea and maybe I can add some extra settings to initialize additional channels. Would that work for you?
LikeLike
Hi, Erich,
I see. You’re right – the allocation and initialization of the extra buffers doesn’t need to take place in SEGGER_RTT.c. So it wouldn’t be correct to call it a bug, sorry. But I do like your suggestion to add some extra settings to initialize additional channels. It’s not necessary, but it would be a very nice to have feature. If you do decide to do this, could you please consider adding an option to specify the name of each channel (perhaps with default values of Channel1, Channel2, etc)?
Thanks!
Jonathan
LikeLike
Hi Jonathan,
I agree, that would be something useful. I already have added in the properties the name of the default 0 (Terminal) channel and for the Segger SystemView one. They both will be read-only as fixed. But nice to know which names are used.
LikeLike
Pingback: First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder | MCU on Eclipse
Hi Erich,
I’ve tried changing the endpoint sizes for the USB CDC to both 32 and 64 bytes, but I don’t see this change reflected in the actual traffic. Using a Total Phase Beagle analyzer, I still see all the individual data packets at 16 bytes. My main objective is higher data throughput.
I noticed that the cdc.inf driver file did not change at all and I was wondering if this should or not. I’m not familiar enough with USB to know how the OS is aware of this change.
Thanks in advance for any help!
LikeLike
Changing the endpoint size does not necessarily mean that this will affect the transactions. This would require that the USB stack is able to handle different endpoint sizes. The 4.1.1 stack used in this component might not be able to support this. I have not checked the driver in details, but you should be able to see this if you search the stack sources how that endpoint size macro is used? Iâm afraid that for things like this you would have to dig into the USB stack and potentially change the stack yourself.
Erich
LikeLike
I also have a separate, but related CDC question. I have firmware that collects up to 64kB of ADC data using a PIT channel with DMA transfers of converted data to RAM. Instead of waiting for the acquisition of data to finish before sending data to the host PC, I would like to start sending the data right away. The ring buffer adds too much latency, so I’ve been bypassing the buffer and directly calling USB_Class_CDC_Interface_DIC_Send_Data(). I check to make sure this returns USB_OK. This has been working great for me, but every now and then it will not return USB_OK and all further communications are stop. I don’t see any errors in the USB or DMA peripherals either. Looking at the Beagle Analyzer, the data just abruptly stops.
Is there a better approach to my design, or are there some things you would recommend checking?
Thanks again!
LikeLike
The ring buffer has been introduced to de-couple the application logic from the USB driver.
If you want to speed up, then I recommend that you still use the ring buffer (increase potentially the size) and increase instead the processing function which feeds the ring buffer into the USB driver instead.
The other thing to keep in mind: I have been using the Freescale 4.1.1 USB stack in this component. It works great for my needs. But this stack is not maintained by Freescale anymore, so in in case problems, we are on our own. So if the current approach does not work for you, you might need to use the USB stack in the Kinetis SDK v2.0 which is the one maintained by NXP/Freescale.
Erich
LikeLike
Thanks for your reply. The ring buffer is still too costly, and I must bypass this. I found a solution, however, that appears to be working solid so far. I made “transactionOngoing” global and set it in my code before calling the send block command. As you know, this is cleared in the callback. If I understand correctly this limits the queue size to 1 when I ensure that transactionOngoing is cleared before calling the send block method again. This allows me to send my data with a non-blocking call. Thanks again for your component and support!
LikeLike