BeagleLogic Progress

Kumar_Abhishek · May 28, 2014, 11:50am

Update 2, Week 1 [21st May - 28th May]

What has been achieved:

First version of the PRU firmware for both the PRUs: PRU0 PRU1
Proof-of-concept 100 MHz sampling of 16 channels one-shot [8 MB, 4Msamples, 40ms]*
*Actual sample rate is now limited by the memory bandwidth and signal integrity at the PRU Inputs shared with the HDMI framer.- First cut for a continuous sampling firmware, using two 4 MB buffers alternately in the PRU shared RAM
Firmware also tested for 25MHz, 50 MHz and 20 MHz frequencies [inserting NOPs appropriately]

Issues:

UIO kernel driver cannot allocate more than 8 MB shared memory for the PRU
Workaround suggested by Charles Steinkuehler: Boot linux with memmap= option to reduce available physical memory for the kernel- Tradeoff between buffer size and interrupts in userspace while attempting memcpy from the shared area to user area [continuous sampling]:
Small ring buffer size, faster memcpy but interrupts come in faster than they can be handled in userspace
Large ring buffer size [4 MB], interrupts are OK but memcpy is slower, also part in due to bus traffic on L3 [PRU → DDR writes].
Issues with ARM NEON memcpy implementation, stack corruption
Plans for the week ahead:
Explore kernel space implementation of the LA core to address interrupt latency and memory issues. Userspace seems to inappropriate for anything but one-shot sampling.
Prepare the libsigrok bindings with everything but data transfer functions.
RLE implementation in PRU firmware to increase data storage in the same bandwidth [4-count or 16-count RLE depending on the number of bits used].

The update is also posted to my blog: http://www.theembeddedkitchen.net/gsoc2014/beaglelogic-week-1-building-the-pru-firmware/

Kumar Abhishek

jkridner · May 28, 2014, 12:39pm

Update 2, Week 1 [21st May - 28th May]

What has been achieved:

First version of the PRU firmware for both the PRUs: PRU0 PRU1
Proof-of-concept 100 MHz sampling of 16 channels one-shot [8 MB, 4Msamples,
40ms]*

*Actual sample rate is now limited by the memory bandwidth and signal
integrity at the PRU Inputs shared with the HDMI framer.

First cut for a continuous sampling firmware, using two 4 MB buffers
alternately in the PRU shared RAM
Firmware also tested for 25MHz, 50 MHz and 20 MHz frequencies [inserting
NOPs appropriately]

Issues:

UIO kernel driver cannot allocate more than 8 MB shared memory for the PRU

Workaround suggested by Charles Steinkuehler: Boot linux with memmap= option
to reduce available physical memory for the kernel

Tradeoff between buffer size and interrupts in userspace while attempting
memcpy from the shared area to user area [continuous sampling]:

Small ring buffer size, faster memcpy but interrupts come in faster than
they can be handled in userspace
Large ring buffer size [4 MB], interrupts are OK but memcpy is slower, also
part in due to bus traffic on L3 [PRU -> DDR writes].
Issues with ARM NEON memcpy implementation, stack corruption

Plans for the week ahead:

Explore kernel space implementation of the LA core to address interrupt
latency and memory issues. Userspace seems to inappropriate for anything but
one-shot sampling.
Prepare the libsigrok bindings with everything but data transfer functions.
RLE implementation in PRU firmware to increase data storage in the same
bandwidth [4-count or 16-count RLE depending on the number of bits used].

The update is also posted to my blog:
http://www.theembeddedkitchen.net/gsoc2014/beaglelogic-week-1-building-the-pru-firmware/

Are you feeling comfortable with how you will push data to the
browser? Are you looking into a C-based websockets library or using
node.js or ...???

Kumar_Abhishek · June 4, 2014, 3:57pm

Update 3, Week 2 [28th May - 4th June]

In Progress:

Kernel Driver WIP for BeagleLogic as an extension to pru_rproc_driver. Implementation as a char device based on Matt Ranostay’s lighting examples
Experimented with memory allocation from within the kernel, was able to get a handle to 128 MB memory as 16 chunks of 8 MB with dma_alloc_coherent.
Tweaks to the device tree file.
Tweaks to the PRU firmware to handle scatter-gather I/O side-by-side the remoteproc kernel driver implementation.

Issues:

(For this week Karki and my work were in the same direction, so some of the issues highlighted by him applied to me as well)
The maximum I/O bandwidth in any case out of system memory is : Flash [10-15 MB/s], Ethernet [10-11 MB/s] or RNDIS [~82 Mbps = 10 MB/s] is the same. This means samples have to be held in memory as long as possible and justifies shared memory management through the kernel for large sample times.
Still using the PASM-generated bin files to load into the PRU, move the asm code to the new PRU C Compiler [now that things are clear], and switch to ELF firmware

Next Target:

Freeze the kernel driver and the PRU firmware and begin working on the sigrok bindings as early as possible

Best Regards

Kumar_Abhishek · June 11, 2014, 4:21pm

Update 4, Week 3 [4th June - 11th June]

In Progress with the kernel driver:

Memory bandwidth issues almost settled by replacing dma_alloc_coherent [no caching at all] with kmalloc and dma_map functions [manual cache management]. To be tested
sysfs attributes for configuration of the capture settings added [See screenshot]
mmap and ioctl’s for the backend
dd with /dev/beaglelogic will be enough to capture logic data from the PRU
PRU firmware and kernel infrastructure is almost ready for first data capture (by this weekend)

Issues:

To be brought up in PRU firmware tests

Screenshot of the API:

http://www.theembeddedkitchen.net/wp/wp-content/uploads/2014/06/Screenshot-from-2014-06-11-230119.png

Best Regards

Kumar_Abhishek · June 18, 2014, 4:03pm

Update 5, Week 4 [11th - 18th June]

Some good updates for this week

Alpha version of the BeagleLogic Kernel Module is ready and has accomplished its first few data captures**.** YouTube video of a live demonstration is uploading and will be available during the meeting
BeagleLogic module is now separated from the pru_remoteproc module and binds itself to it (and unbinds itself) in order to reroute interrupts and abstracts itself from the low-level rproc operations and structures. Less than 100 LOC additions to the core rproc module noe, the BeagleLogic kernel driver is ~ 1068 lines (841 sloc) .
BeagleLogic is fully controllable with sysfs attributes (for languages like Node.js and Python) and IOCTL’s for native libraries
Exposes the PRU shared circular FIFO as a misc character device accessible at /dev/beaglelogic . This can be mmap’ed as well to access the entire sample buffer.
Bugfixes and thorough testing this week and public release of the kernel module, and the remoteproc driver patch will be handed over to the BeagleBone kernel maintainers for inclusion.
The kernel driver is streaming-ready. I have reached peak speeds of 250 MB/s in copying over data from /dev/beaglelogic to /dev/null using the dd command
This opens up potential for piping the BeagleLogic data through a fast compression algorithm like LZO or LZ4 before saving it to disk. At lower speeds like 25MHz or below, it seems achievable. More tests on this later.
Noting that the maximum speed of any link outside BeagleBone Black is ~10 MB/s [both RNDIS and Ethernet]. Gigabit Ethernet on the AM335x might make it possible to stream real-time data to PC over a Gigabit Ethernet link.

Follow up:

sigrok bindings.
Kernel module documentation
Patch Preparation for the kernel tree (just the glue code in pru_remoteproc)
Quick whipping up a streaming web application in Node.js using file I/O with /dev/beaglelogic

Cheers

Abhishek

Kumar_Abhishek · June 18, 2014, 7:05pm

For the record, regarding the video mentioned in the status update & code review points in the meeting.

The status video that was posted today: http://www.youtube.com/watch?v=UYRSvTC6VUI
Notes on the video:

In this video, I capture logic data from a test rig of a microcontroller board playing back WAV files from a microSD Card [as seen here] .
I tapped the I2S bus pins there and had attached them to my BeagleBone Black at the time of running the test commands [if the volume is turned a little high/headphones, faint music can be heard while the kernel modules are loaded].
Sampling of the LA is triggered via a read on the /dev/beaglelogic file via dd. The captured data is saved in a binary file, in a raw format
Sigrok [sigrok-cli] is used to process the raw binary data into a Value Change Dump (VCD) file on the BeagleBone Black. This file is then copied via SFTP to my desktop.
I then open the file in a front-end for sigrok PulseView and then I visualize the logic data that had been captured with the PRU.
Note that the aim of this video was a proof-of-concept of raw data capture from this logic analyzer and that it can be operated without sigrok bindings too (via just piping raw data into the readily available sigrok-cli utility which supports raw input file formats), but sigrok bindings are the next week’s target of course.

Regarding the code review, these functions have to be reviewed [the functions link to the code lines]:

[beaglelogic_serve_irq](https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/beaglelogic.c#L408)

beaglelogic_f_read
beaglelogic_f_release
Regards

Kumar_Abhishek · June 20, 2014, 11:36pm

Hi everyone,

I write this mail to announce the specifications of the core of BeagleLogic.
In my presentation I had highlighted that the sample rate would be “best effort”. Here’s what has been achieved from implementing suitable kernel module and PRU firmware now:

Sample Rates: (100 / N) MHz : N = 1, 2, … [100MHz(highest supported, would need proper signal conditioning) & 100kHz (lowest supported)]
Sample Formats: 8-bit and 16-bit uncompressed per sample [maximum 12/14 bits supported by hardware (eMMC/uSD)]
Sample Depth: As much RAM is available on the system. I have successfully filled buffers worth 320 MB on the BeagleBone Black (but possible to fill more), leaving sufficient space for processing applications to run
Streaming support (experimental) at lower sample rates [ < 50 MHz ], assuming data can be moved out fast enough out of the BeagleBone Black. RAM bandwidth is good enough for streaming (buffer copy speeds in RAM ~200 MHz) [At 50 MHz & 100 MHz it is recommended to run in pre-allocated large buffers]. The ARM processor should be capable of compressing the stream in real time using a fast compression algorithm like LZO or LZ4, I am yet to do more tests with this.
Absence of Hardware Triggers [not implemented yet]. This is traded for large buffer depth. 320 MB = 3 seconds worth data @100 MHz, 8bits, which should be enough to analyze and use software triggers on the captured data
[software triggers are being developed in sigrok]
PRU firmware can be modified for trigger support, e.g. capturing a live video stream in which the VSYNC signal can act as the trigger.

Link to the firmware:PRU Firmware directory (GitHub)

Link to the kernel driver: BeagleLogic kernel module

In the coming week, I will be implementing sigrok bindings for BeagleLogic. There’s also a lightweight “libbeaglelogic” (essentially a syscall wrapper in userspace) for ‘/dev/beaglelogic’ in the queue. As of now I am preparing the patch for Pantelis’ pru_rproc driver which enables the BeagleLogic kernel driver to operate the PRUs and receive IRQs from them, the beaglelogic module is independent and communicates with the pru_rproc driver with the patch code.

I will publish the READMEs very soon

Kumar_Abhishek · June 25, 2014, 3:43pm

Update 6 [Week 5]

Accomplished:

Release of v1.0 of the kernel module to upstream BeagleBoard kernel maintained by Robert Nelson. View the thread here. It will be available starting with the bone57 kernel
Wrote the initial documentation of the kernel module and created the project wiki at www.beaglelogic.net [Redirects to the GitHub wiki at the moment, will push for a dedicated site later]
Patchsets and PRU firmware binaries for testing are available for download from this link
Wrote a small syscall wrapper program to test the char device. I was using “dd” so far.
I consider the LA core stable enough to be evaluated standalone by anyone with a BBB or BBW using the instructions available on the wiki and the download links above.
Interacted with Jason and Gerald over the question of the maximum possible speed at which stable sampling is possible, which can be concluded in short as

"The maximum speed on the input pins [P8_27 to P8_30; P8_39 to P8_46] depends upon the signal integrity of the signals to the Bone. Sampling is possible with the software at 100 MHz, but it will only be as good as the quality of signals at the inputs"

In Progress

sigrok bindings are being implemented
libsigrok uses non-blocking I/O, so the necessary poll() and O_NONBLOCK in read() have been initially implemented

Issues

A few usage quirks as libsigrok uses GPollFD to listen for data from files, and till a few hours before the character device model in the BeagleLogic driver was based on blocking I/O
read() in file operations has been rewritten to support O_NONBLOCK and output -EAGAIN and poll() has been added. I am working on fixing them [no regressions on blocking I/O as of now]

On of the patches in the patchset [on pru_rproc.c] can be handed over Deepak to add BeagleLogic hooks into the BotSpeak driver [which is based on pru_rproc.c], and then the BeagleLogic module [beaglelogic.ko] can be run along with it, with the correct firmware and pinmux settings being loaded into it.

Expect sigrok bindings to be ready and sent upstream by this week-end.

Once this is done, I will begin work on the HTML5 frontend and Node.JS backend of the web interface to BeagleLogic. The backend may also be a combination of C code and Node.JS code, specifications of which will be available after work on the sigrok bindings is stable.

Regards

jkridner · June 26, 2014, 12:46am

Hi everyone,

I write this mail to announce the specifications of the core of BeagleLogic.
In my presentation I had highlighted that the sample rate would be “best effort”. Here’s what has been achieved from implementing suitable kernel module and PRU firmware now:

Sample Rates: (100 / N) MHz : N = 1, 2, … [100MHz(highest supported, would need proper signal conditioning) & 100kHz (lowest supported)]

To save buffer size, I can see value in going down to 100Hz. Divisor won’t go that large?

Sample Formats: 8-bit and 16-bit uncompressed per sample [maximum 12/14 bits supported by hardware (eMMC/uSD)]

Sample Depth: As much RAM is available on the system. I have successfully filled buffers worth 320 MB on the BeagleBone Black (but possible to fill more), leaving sufficient space for processing applications to run

Streaming support (experimental) at lower sample rates [ < 50 MHz ], assuming data can be moved out fast enough out of the BeagleBone Black. RAM bandwidth is good enough for streaming (buffer copy speeds in RAM ~200 MHz) [At 50 MHz & 100 MHz it is recommended to run in pre-allocated large buffers]. The ARM processor should be capable of compressing the stream in real time using a fast compression algorithm like LZO or LZ4, I am yet to do more tests with this.

Absence of Hardware Triggers [not implemented yet]. This is traded for large buffer depth. 320 MB = 3 seconds worth data @100 MHz, 8bits, which should be enough to analyze and use software triggers on the captured data

[software triggers are being developed in sigrok]

PRU firmware can be modified for trigger support, e.g. capturing a live video stream in which the VSYNC signal can act as the trigger.

I hope to see firmware triggers added at some point. They should not impact buffer depth if done properly, though I see there can be challenges depending on the streaming strategy and desire to capture ore trigger data.

Kumar_Abhishek · June 26, 2014, 8:54am

To save buffer size, I can see value in going down to 100Hz. Divisor won't go that large?

It was more of a hardcoded limit set in the kernel driver, I've moved
it down to 1 Hz. The kernel driver configures the sample rate divisor
value (which is a 32-bit downcounter on the PRU side), so the PRU
firmware does not need any change.

The minimum kernel buffer allocated is 8 MB (2 x 4 MB ring buffers),
more because a lower buffer size means that the ARM core gets more
IRQs per second from the PRU (depending upon 8/16bit sampling and
sample rate), and that seems to impact performance as I move to lower
buffer sizes. At 4 MB and highest sample rate (100MSa/s, 16-bit), I
get an IRQ every 20ms, which seems to be fair enough. The size of each
kernel buffer can be more than 4 MB and it can be configured with the
bufunitsize=xx parameter at kernel module load time.

I hope to see firmware triggers added at some point. They should not impact buffer depth if done properly, though I see there can be challenges depending on the streaming strategy and desire to capture ore trigger data.

Implementing hardware triggers can be done although I see the
triggering stuff being done on the software side by the ARM core a
viable alternative, considering there's sufficient memory bandwidth
available with the new kernel infrastructure in place. We could
discuss this in detail in the upcoming hangout, once the sigrok
bindings are stable.

jkridner · June 27, 2014, 3:27am

remind me when the hangout is

Kumar_Abhishek · July 2, 2014, 3:27pm

Update 7 [Week 6]

Achieved:

Working libsigrok bindings for BeagleLogic. See the screenshot above.
Non-blocking I/O bug fixed in the kernel driver
mmap() functionality validated using a test application which compared the buffer read back using read() and the mmap()'ed buffer.
Test userspace application that tests both blocking and non-blocking I/O functionality
I also tested the protocol decoder functionality within libsigrokdecode by firing up my self-built audio playback board and decoding a 6 second captured wave audio file directly from the BBB

Issues:

Speed. sigrok-cli is _extremely slow_ on the BeagleBone Black. As can be seen in the screenshot, it took me more than 30 minutes [1600 seconds] to save a 256 MB logic dump.
Decoding a wave file took 10 minutes to process 64MB of dump into a 6sec wave file on the BBB. These values are quite low. Improvement is expected in future versions of sigrok.
This was quite surprising to me, considering I’ve captured 1 GB of a logic dump while compressing it with LZO using just dd if=/dev/beaglelogic | lzop.

TODO:

Build a sigrok-based C application to exchange data with a Node.JS backend via pipes / Explore node-ffi [High priority]
Add software triggers supported by libsigrok to the BeagleLogic driver [not urgent]
Send patch to the sigrok-list.

BeagleLogic Hangout

A Hangout is scheduled on Thursday, 4:00am WIB [2 pm Pacific Time, 5pm Eastern, 11:00pm CEST] with Bert Vermuelen from sigrok having agreed to join in the discussions with me, Jason and Matt.

The blog post would be live in a few moments from now at BeagleLogic and sigrok: The beginning

jkridner · July 2, 2014, 3:32pm

*Update 7 [Week 6]**Achieved:*

<http://s21.postimg.org/xx6bzrvgn/sigrok_cli3.png>

   - Working libsigrok bindings for BeagleLogic. See the screenshot
   above.
   - Non-blocking I/O bug fixed in the kernel driver
   - mmap() functionality validated using a test application which
   compared the buffer read back using read() and the mmap()'ed buffer.
   - Test userspace application that tests both blocking and non-blocking
   I/O functionality
   - I also tested the protocol decoder functionality within
   libsigrokdecode by firing up my self-built audio playback board and
   decoding a 6 second captured wave audio file directly from the BBB

*Issues:*

   - *Speed. *sigrok-cli is **extremely slow** on the BeagleBone Black.
   As can be seen in the screenshot, it took me more than 30 minutes [1600
   seconds] to save a 256 MB logic dump.

Do you know how to profile the code to find the hotspot? 256MB is pretty
big. Do you have an idea of what is a usable size with the current
implementation? (I'd say 30 seconds is a reasonable wait, not 30 minutes.)
Mentors giving you suggestions here?

Kumar_Abhishek · July 9, 2014, 4:00pm

Update 8 [Week 7]

Achieved:

Completed sigrok bindings for BeagleLogic, with software triggering capabilities too.
Modified the first patchset based on reviews from the sigrok developers and sent another patchset addressing a few points raised. It is in the queue for a spin by the sigrok developers.
Release v1.1 patchset (non-blocking I/O) to the BeagleBoard kernel [Merged]
Kernels bone60 onwards, and the next system image should bundle BeagleLogic kernel components out-of-the-box.
ABI freeze [except for bugfixes] for the kernel-userspace part until BeagleLogic is refactored for mainline.
Building a framework for the web application using Express. These are the libraries that are confirmed so far and are in queue for benchmarking:
LZ4
LargeLocalStorage
Socket.IO

Issues

Benchmarking these libraries to evaluate the performance and suitability for real-time over web-browser. I am not able to bring in numbers today as I was busy with some other work, but will provide very soon.
Also to evaluate suitability of WaveDrom as a rendering agent. The first version of the web app will allow binary files to be downloaded over to the desktop directly and can be processed with sigrok on the desktop
Profiling sigrok-cli for the slowness is deferred as we will be dealing with short capture sizes at first.

TODO

Build first iteration of a non-interactive webapp
Bring the mock-up as posted in my proposal live (with a UI library) for design feedback.

I encourage the community to try out sigrok-cli and the kernel drivers with the latest bone60 kernel.

Regards

DrTune · July 10, 2014, 6:39pm

This is an awesome project!

One thing that would be super duper useful would to add an input buffer with variable logic thresholds; on my current logic analyzer I’m often switching between projects running at 1v8, 3v3 and 5v, and it’s essential to have programmable levels.

It appears quite a simple interface cape would do the trick, e.g.:

SN74LVC16T245 - 16 channel buffer with separate in/out power rails, runs from 1.6v to 5v (so probably good for even 1v2 logic!)
AD5320 rail-to-rail DAC, powered off 5V, supplying one power rail to the buffer. The other buffer power rail would be 3v3 for the beagle side.
Should work up to 100Mhz ok (buffer timing varies a little with the voltage chosen)

Conveniently this could work bidirectionally so as a programmable-output-voltage 16-bit bus, although one would have to be careful not to draw too much power on the output pins (as it’s powered by the DAC).
For a couple of bucks more one could have a separate SN74LVC8T245 for output, (perhaps with a two-channel DAC) and have simultaneous in+out at programmable voltage levels, e.g. for a chip tester or whatever; various bells+whistles are imaginable.

Great work, will be following this project.
Thanks,
DrTune

Kumar_Abhishek · July 18, 2014, 4:39am

This is an awesome project!

One thing that would be *super *duper useful would to add an input buffer
with variable logic thresholds; on my current logic analyzer I'm often
switching between projects running at 1v8, 3v3 and 5v, and it's essential
to have programmable levels.

It appears quite a simple interface cape would do the trick, e.g.:

SN74LVC16T245 - 16 channel buffer with separate in/out power rails, runs
from 1.6v to 5v (so probably good for even 1v2 logic!)
AD5320 rail-to-rail DAC, powered off 5V, supplying one power rail to the
buffer. The other buffer power rail would be 3v3 for the beagle side.
Should work up to 100Mhz ok (buffer timing varies a little with the
voltage chosen)

A buffer cape is a stretch goal of the BeagleLogic project, so you can
expect them very soon, now that there is less than a month to meet the
goals set for this period.

In our discussions, it has been repeatedly pointed out that the integrity
of the signals from the user circuit to the Bone is what that determines
the maximum sample rate that can be expected; the software is capable of
100Msps. I have not been able to fully test the maximum speed at which it
is usable, though would be happy to see it being tested with signals of,
say, SPI at 48 MHz which would be quite close to what can theoretically be
expected.

Conveniently this could work bidirectionally so as a

programmable-output-voltage 16-bit bus, although one would have to be
careful not to draw too much power on the output pins (as it's powered by
the DAC).
For a couple of bucks more one could have a separate SN74LVC8T245 for
output, (perhaps with a two-channel DAC) and have simultaneous in+out at
programmable voltage levels, e.g. for a chip tester or whatever; various
bells+whistles are imaginable.

Apart from applications as a logic analyzer, I personally see BeagleLogic
as a reference project for doing high-speed data acquisition with the
Programmable Real-Time units (PRUs). It would be quite interesting to see
the 12 or 14-bit PRU bus being used to interface a high-speed ADC, for
example and let the kernel driver grab the data and process it in real
time. This will probably not work at full 100 MHz capacity but it can be
done at lower speeds.

Great work, will be following this project.

BeagleLogic is usable over the command line for now with rcn-ee's kernel
bone60 and above, the sigrok patches will be merged so you can also use
BeagleLogic with sigrok very soon.

Over the next few weeks, I will be building and releasing a HTML5 client
for BeagleLogic, served by the Bone. I will present a screenshot of the
same in my coming status reports, let me know if you have any feedback for
the UI.

You can read the wiki doc pages at www.beaglelogic.net for more
information.

Best Regards
Abhishek

Kumar_Abhishek · July 23, 2014, 4:02pm

Update 9 [Week 8 and 9]

Achieved:

After 4 iterations of patch submissions, BeagleLogic bindings have been merged into the upstream sigrok repository. link to commit
Basic Socket.IO link is functional between the web server on the Bone and the web page on the client.
Bert helped identify a bug impacting capture sizes less than 512K samples with sigrok using a simple Python script that sent a small number of bytes over the SPI bus on the BeagleBone Black and looping the pins to the BeagleLogic inputs. This was related to some skipped bytes sent in the data packets has been fixed.
With BeagleLogic now in both the BeagleBone kernel and the upstream sigrok, development focus is now the web interface.

Issues: I had to travel back to India to my university as vacations had ended. There were also logistical issues due to relocation; work was disturbed for almost 3-4 days. So there couldn’t be a status update last week.

These non-technical issues have been settled and I have been catching up over the past few days; I expect to be able to show a screenshot in a day or two, and push the initial web interface structure on GitHub very soon.

TODO:

Get data from sigrok-cli on the web page and attempt to render it with WaveDrom
Begin the UI Design as shown in the mockup as seen in my GSoC proposal.

Regards

P.S. BeagleLogic has been featured on HackADay . Thank You Jason!

Kumar_Abhishek · July 30, 2014, 2:44pm

Update 10 [Week 10]

Achieved:

Hooked sigrok-cli using child_process in Node and used the ASCII output interface to build a quick-and-dirty demo which can be seen here (this video was published immediately after the last meeting)
Brought a demo version of the mockup live at beaglelogic.github.io/webapp. This is built using Bootstrap & Socket.IO . The interface looks good enough on mobile devices as well.
All the content at beaglelogic.net will eventually move to beaglelogic.github.io and beaglelogic.net would redirect to the same.

I invite everyone to test the web interface and rate its usability (as-is in its current form) on a scale of 1 to 5 and request feedback on the UI and features.

Issues:

WaveDrom: In my tests, I’ve observed that WaveDrom does not really scale well with large datasets. This is due to it parsing and generating a SVG at once that resides in the DOM, and hence severly impacts resize/scroll performance. If you can view the sources of the page, in the beginCapture function there’s a for loop that generates the wave string that is rendered by WaveDrom, and by changing the number one can see for oneself how the performance scales. With 64K samples datasets, the browser window will remain nonresponsive for about more than a minute. As an example, a 10K sample line generates about 40K XML SVG nodes, so one can estimate the CPU/mem cost.

Possible Solutions:

I looked at alternatives such as jQuery flot, but couldn’t really find something close to WaveDrom. It’s only unfortunate that in its current form, WaveDrom cannot really be used otherwise if I would have combined WaveDrom waveforms with the output received from sigrok-cli in ASCII mode as seen in the video, then it would have been really nice.
Using a Canvas based custom render component/scrolling is the only plausible way out.

Next Steps:

Implement data transport layer using C and libsigrok that communicates with the Node process via stdin/stdout.
Develop the view component

Regards

Kumar_Abhishek · August 6, 2014, 4:14pm

Update 11 [Week 11]

Achieved:

Figured out WaveDrom to render dynamically generated [through JavaScript] wave markup
Chose sigrok-cli itself as the base to build the web interface on for the moment, particularly due to “one-to-one correspondence” between the “ASCII” output format and the WaveJSON input format for WaveDrom
Socket.IO links are stable at the moment. The NodeJS script just streams out the command-line dump over the socket.
The browser-side JavaScript is now able to parse the command line output and render it in WaveDrom

Here’s an example parsed and rendered logic dump.

Issues:

I did not have a very good time sending large raw binary dumps with Socket.IO, it tends to serialize them inefficiently. With base64 encoding of binary data, it was much more stable
The connection resets whenever I receive a logic dump on the browser side. I suspect it is due to the intensive processing inside the socket.on(‘data’, function { … }) which perhaps disrupts an acknowledgement packet.
The backend would still be quite limited in its current state. A better solution in the long-term would be to perhaps implement WebSockets in C and combine it with the backend instead of the JS, it could lead to performance improvements.

TODO:

Add pin selection, labelling and basic soft-trigger support (basically shims to sigrok-cli command line params)
Documentation on the web interface
Packaging it as a systemctl service like the Cloud9 and bone101 demos and bundle it for the latest images

For updates on the project in the future, keep visiting http://beaglelogic.net .

It has been a great journey so far, and I would be very happy to see BeagleLogic live its purpose of use as a learning tool to understand logic protocols, and a powerful yet-cost effective alternative to the plethora of inexpensive LAs and hope it will serve the community the fullest.

Cheers!

Abhishek

Kumar_Abhishek · August 13, 2014, 4:07pm

Final Status Update [Week 12]

Achieved:

Pin selection and annotation is now functional
Sample Rate and number of samples are configurable [Sample limit is fixed at 3000]
Fixed annoying disconnect after data receipt by deferring the CPU-intensive render operation

Issues:

Web client accessible only from BeagleBone server. The web client at beaglelogic.github.io cannot currently connect to the Bone and detects this and switches to “demo mode”
Triggers are currently non configurable in the UI
Save and download functionality will be disabled for now (they do not work well with large dumps as well). The entire web page can be saved to disk if desired to save the captured waveform.

I will make a last pass on the first two issues by this Friday. The resulting package will be submitted (along with the systemd files) for inclusion in the system image this weekend.

The final report (video) will be uploaded this weekend.