-
Notifications
You must be signed in to change notification settings - Fork 25
Home
BeagleScope, a project that aims to empower your beagleboard by providing with generic ways to use all the nifty features of the board, specially, the PRUs.
Would like to contribute ? Please head onto this link.
Open source hardware based organization beagleboard.org offers some cool embedded Linux boards. These boards are far more superior than most of the other boards in terms of specifications, the only downside being, the boards lack generic software support to use some of its nifty features.
Here comes the BeagleScope project to rescue. Beaglescope project was started as one of the Google Summer of Code-2016 projects, under beagleboard.org. The aim is to offer with generic software stack that would provide with ready to use softwares and examples for developers to use some of the boards' great features. The final product of the project is expected in the form of generic chunks of code that would allow you to use the PRUs on beaglebone black/green as parallel data interface.
Imagine the case you want to do some real-time testing with high speed ADC or some image sensor module. You can do this either with the help of an FPGA or high-speed differential serial data interfaces. Both of these options are expensive and you will still need to do quite a amount of setup to get this working.
The project uses real-time processors, AKA PRU, on the beaglebone black/green to provide with a parallel interface for the device. It further offer all the software support you need to get data out of the device straight to the user-space. What you would need is just the device driver for that device.
Though the main aim of the project is the parallel interface, but as a use-case of this software stack, the project also proposed developing a 40MSPS Oscilloscope using the DC782A-P ADC evaluation board. This would make the project more exciting and useful as it is.
Well, the Linux kernel has good support for serial buses like SPI, I2C etc but it still do not has support for a parallel-data-transfer subsystem. There might be some custom support for specific purposes, but no well-documented support.
The project aims to expose a friendly and well-documented interface for device-drivers and platform drivers to use the PRUs as a parallel bus. In order to be friendly, the interface will be implemented to offer APIs similar to those exposed by well know buses like the SPI and the I2C.
The generic part of the project is important. The code that will be developed has to be reusable to masses, and therefore needs to be in form of modules. For the best integration and to make it easy to use, the kernel side of the project can be implemented the way all other buses like the SPI, I2C etc are implemented. This in-turn means that the software stack will be as :
- The platform specific driver - This driver will be the closest to the hardware and will differ from platform to platform. More details can be found on the platform driver page.
- The core bus driver - An all-inclusive, bus core driver that would provide with APIs for the platform driver and the device driver for all the data transactions.
- The device driver - The device driver that would be for specific to the device that has to be connected onto the bus. The device drivers will use APIs exported by the core bus driver, as is the case with all other bus drivers. More information can be found on the device driver page.
This further will become clear with the following diagram :
Yeah, GSoC is a 3 month program and the 3 month time period ends on 23rd August 2016 as the time-line says. The project will still be under development and I will keep on contributing to it to achieve all of its goals. I will further try to get the code mainlined to the Linux Kernels.
As of now, following things have been developed :
-
BeagleScope
- Notes :
- clpru_and_C_usage.notes : Highlighting some limitations and usage information about the clpru - PRU C compiler
- current_remoteproc_driver.notes: Highlighting some of the current capabilities and insight into working of the remoteproc driver.
- Programmable Real Time units
- firmware : The firmware that can sample 8bit wide data at frequencies lower than 25MHz. It can sample continuously in cycle and transfer data in form of data blocks using BLOCK_READ mode or can take a single sample using RAW_READ mode.
-
Various examples :
- pru_blinky : The example to make a blinky on PRUs
- pur_logic_replicate : To input logic on an input pin and reproduce it on an output pin.
- pru1_to_pru0_to_arm : example in which pru1 interrupts pru0 which further sends a message to arm.
- PRU_inline_asm_blinky : Example to make a blinky using inline assembly.
- pur_pi_state_reader : example to send logic-state of an input pin as a message to the userspace
- Linux kernel
-
Example :
- n-blinky : an example to show development of an rpmsg-client driver and associate a firmware with it.
- The project has to be developed in 2 steps:
- Step 1 - beaglescope_driver : A single driver that registers itself as a rpmsg-client driver, it configures the PRU according to the given sampling frequency and starts sampling the data. The driver samples at 50% duty cycle and can sample at max 20MHz of sampling rate.
- Step 2 - Parallel interface
- A platform driver pi-bus, specific to this platform. The driver That register itself as a rpmsg-client driver and then as platform driver and binds with the platform-device associated with the pibus0 node (the node that represents a virtual parallel host in the device tree).
- A generic core-bus driver named as parallel_interface. The core-bus device provides all the APIs required to register a device and a driver, except the devm_* based, managed APIs. It thus provides a mechanism to register a device driver and a platform-driver to provide device-to-driver bindings.
- Some modifications in the beaglescope_driver to make it register onto the parallel_interface core-driver with some dummy probe and remove functions.
-
Example :
- Testing work The ADC EVM DC782A-P was tested with PRUs being a clock source with a clock driver circuit and the it was found to be working.
- Notes :
Though the project is quite young, 0.1 version has been released. To use this release, please head on to this link.
The next release with the bugs/problems of v0.1 solved, has already been developed with this commit. Further testing is in progress and till now, data integrity at a sampling rate of 5MHz has been checked. Hence, its for sure that you will get the correct data at any frequency less than or equal to 5MHz. The next release will be released once the data testing is complete.
If you would like to see how this project came up, you can find weekly project reports on this link. Also, along the project, I have been able to develop posts on my website 'https://zeekhuge.me' to make kernel development on BeagleBone boards easy. New posts will be added soon, along with new examples for PRU programming.