search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Column: Embedded design


Using Tracealyzer with Yocto-based Linux distribution


Mohammed Billoo, founder of MAB Labs, charts his experiences with the new Linux support by Percepio’s Tracealyzer v4.4 tool through real-world projects


I


’ve recently worked on a custom Linux driver with data streaming from an external device. Whilst the Linux kernel has native mechanisms to ensure the correctness of my driver’s


functionality, evaluating its performance is not straightforward. Percepio updated its Tracealyzer support


for Linux, which was a good opportunity for me to try it and help assess the performance of my custom driver in this project; see Figure 1. Tracealyzer for Linux takes advantage


of LTTng, an open-source tracer and profiler that allows developers to evaluate performance of the kernel, including drivers. It also supports userspace


applications, but in this series we’ll focus on the kernel. Ultimately, Tracealyzer parses the output of


LTTng and provides visualisation and detailed statistics. Te external device has three main interfaces (Figure 1): I2


C for control, SPI for


streaming data to the Linux device, and GPIO as an interrupt line to indicate when there’s data ready to be used. When my device asserts the GPIO line, the Linux driver will send an I2


C command to


instruct it to begin streaming, over the SPI interface. Te driver will instruct the DMA controller (DMAC) of the embedded Linux system to manage the data transfer between the SPI bus and system RAM, to ensure that the CPU can manage other tasks. While the driver will simply instruct the DMAC to perform the necessary transfers, it will need to periodically check in, to ensure there are no problems. Finally, application code exists on the Linux device to retrieve the streamed data from RAM and store it in non-volatile memory. I used Tracealyzer to validate two important


metrics: First, that the time between the GPIO being asserted and the I2


C command


issued is kept to a minimum, and, second, that the Linux kernel provides the driver with sufficient execution cycles to allow it to periodically manage any problems encountered by the DMAC. My ultimate goal is to guarantee that minimal data is lost in the streaming process, and Tracealyzer should help quantify this.


Figure 1: Diagram of the driver


Configuring the development kit Since Tracealyzer uses files generated by LTTng, before getting started with any implementation, the embedded Linux platform must be appropriately configured to support LTTng. Te platform I chose for this was the Phytec i.MX 6ULL development kit. I’ve used other Phytec development kits in the past, so I’m comfortable with their Yocto- based Board Support Package (BSP). Te BSP must be customised to support LTTng, since the standard BSP for this board doesn’t include LTTng. For this, I created a layer on top of the “poky” layer and the custom Phytec layers. I’ve called this layer


10 February 2021 www.electronicsworld.co.uk


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44