Anemometer Weekly Reports

Week 2

I’ve received the hardware, except for the ADC. Unfortunately school was finishing up and required most of my attention so I didn’t get to spend much time with the board. I’m pretty much done now, so that shouldn’t be an issue in the future.

Last week:

  • Got the BBG working well with my Windows machine.
  • Assembled a case for it. I probably wouldn’t have mentioned this, except it me a couple hours… The Built-to-Spec BBG case could do with a bit of a rework for assembly. Otherwise seems pretty nice. I suggest lots of tape, and mostly ignoring the official instructions.
  • In the middle of getting temperature and humidity data.

Issues:

  • Does not play so well with linux. I can get in via screen, but the networking side doesn’t work. Can’t SSH in or access the webserver.

This week:

  • Get an updated image on it. If I’m really lucky this will fix the problems with linux, but I doubt it.
  • Fix the networking issue on linux. My laptop runs Arch, so this will be relevant as work progresses.
  • Get temperature, humidity, and compass data.
  • Start working on speed of sound calculations.
  • Play with the ultrasonic transceivers. I can should be able to use the on-board ADC for this.

Week 3

I’ve received the ADC. I’m not particularly happy with the way this week progressed. I spent a lot of time dealing with auxiliary issues, and probably went down a few rabbit holes I didn’t need to.

Last week:

  • Updated the image.
  • Sorted the network issues on linux.
  • nerdboy is able to get temperature, humidity, and pressure data using Adafruit python libraries for the respective sensors.
  • (Just) started working out a setup for the ADC.

Issues:

  • Intermittent issues with ability to talk to the board. Mostly this manifests as SSH not working after a reboot. Eventually (up to 4 or 5 hours later, after multiple reboots) it does come back. Virtual serial tends to work during this period, but I have had problems with both methods being down at the same time. I’m thinking it might be a power issue, but it’s certainly not clear cut. It seems like this mostly started popping up once I added both the temp/humidity sensor and the imu, but it has worked many times in this configuration. Reseating the sensor connectors and/or power cord may help with this but the issue is so unpredictable it’s difficult to say.
  • I spent a lot of time thinking I would need to port an Arudino or Pi library for the sensors. That is all the Grove pages mention, and while the parts Grove used for the components are sold by Adafruit, Adafruit mostly list Arduino libs on their product pages. As a result I kind of fell down the device tree rabbit hole, and ran into a lot of outdated (to various degrees) write ups. Eventually nerdboy found the Adafruit python libraries, which fortunately use an abstracted comms layer. The libs seem to detect the Beaglebone and load the Adafruit BB comms lib, rather than the Pi comms libs.
  • I can’t actually get the aforementioned libs to work yet. I get a remote I/O error 121.

This week:

  • Get the setup for the ADC sorted, and talk to it.
  • Figure out the sensor problem.
  • Play with the ultrasonic transceivers.
  • Start working with the PRUs.
  • If/when further ssh/virtual serial problems arise, try to figure out what actually solves the problems.

Last week:

  • Working on getting the ADC up.

Issues:

  • Either I’m terrible at reading datasheets or the ADC eval board isn’t super well explained. Could be both. I probably need to focus more on the schematics.

This week:

  • Settle the ADC for real.
  • Architecture

Bit of an update to the week 3 report. After talking to nerdboy and Wormo I’m going to go ahead and focus on the data capture side of things this week. The main thrust will be writing the code to interface the PRUs to the ADC, but I’ll work from the datasheet and ignore the hardware for the moment. This should be a solid framework for the project to build off of.

Last Week:

  • Got a first pass of the ADC firmware(s) done. Theoretically it should be capable of initializing and running the ADC, collecting batches of results, and then shipping them off to the ARM with RPMsg. So far untested on the actual ADC, so I’m sure it has some problems there.
  • Added/improved documentation of the overall project architecture, and specifics for how the PRUs interact with the ADC and the ARM.

Issues:

  • So far the main issue is that I’m having trouble getting (fake) results from the firmware back to the ARM processor. There were some issues with RPMsg that I’ve resolved, but the data transfer is still having problems. I’ve built up a separate prototype using similar communication patterns and it all works as expected. I’m looking into other possible areas now.

This Week:

  • Get the data transfer working, as described in the above issue. I’ll probably have to resort to LED debugging for now. I think CCS can do some kind of simulation/debugging, but I ran into licensing issues there. Maybe it’s a matter of configuration though, or it can debug the actual hardware?
  • Build a userspace program to collect the data from the PRUs and run it through a simple processing pipeline. I’ll use the fake data for this, for now.
  • Start looking into testing on the actual ADC. Unfortunately I don’t have a scope, so I’ll probably want to look into getting access to one. A local hackerspace or something should work fine.

Last week:

  • Chased down some issues in the ADC firmware and improved some things, although rpmsg stuff still isn’t functional. One particularly strange issue I found was that I apparently couldn’t set a bit in R30 with a simple function for it, but a similar function for clearing a bit in R30 was fine. It wasn’t an error in the (simple one line) code, as copy/pasting it directly into the source worked fine. I ended up just macroing all of it and that works. I didn’t dig into it too much, but my best guess would be an overly aggressive optimizer… although that doesn’t really explain why clearing bits was fine.
  • Completed a first pass of the userspace software to consume the raw ADC results and calculate a time of flight. I’m just using the provided rpmsg character device module rather than writing my own kernel module. The only minor complication is that I’m sending back 16-bit results, but it’s easy enough to stick the bytes back together.

Issues:

  • rpmsg is the major one. I’ve fixed a few potential problems but while the PRU is getting through the rpmsg sections successfully, I’m not getting results back on the ARM. Cutting things down hasn’t helped, even when it’s down to the point of matching working examples. I suppose it could be another issue with function calls (working examples are just in main, functionally identical cutdowns are still in a separate function) but that would be a fairly major problem.

Next week:

  • Get this rpmsg stuff sorted. I’ll probably need to get a debugger going or something.
  • Convert a working example to produce fake adc reads so work can continue on the userspace ADC consumer without waiting on the real ADC firmware rpmsg problems.
  • Potentially start working on the higher level sensor fusion stuff, depending on how the rpmsg stuff goes.

Last week:

  • Chased down some issues in the ADC firmware and improved some things, although rpmsg stuff still isn’t functional. One particularly strange issue I found was that I apparently couldn’t set a bit in R30 with a simple function for it, but a similar function for clearing a bit in R30 was fine. It wasn’t an error in the (simple one line) code, as copy/pasting it directly into the source worked fine. I ended up just macroing all of it and that works. I didn’t dig into it too much, but my best guess would be an overly aggressive optimizer… although that doesn’t really explain why clearing bits was fine.
  • Completed a first pass of the userspace software to consume the raw ADC results and calculate a time of flight. I’m just using the provided rpmsg character device module rather than writing my own kernel module. The only minor complication is that I’m sending back 16-bit results, but it’s easy enough to stick the bytes back together.

Issues:

  • rpmsg is the major one. I’ve fixed a few potential problems but while the PRU is getting through the rpmsg sections successfully, I’m not getting results back on the ARM. Cutting things down hasn’t helped, even when it’s down to the point of matching working examples. I suppose it could be another issue with function calls (working examples are just in main, functionally identical cutdowns are still in a separate function) but that would be a fairly major problem.

Sounds like you’ve been having this issue with rpmsg for a couple weeks now, and I haven’t actually seen any error logs or test results as you’re working on it.

You sound pretty sure that it’s an issue with rpmsg itself and not your implementation - how did you arrive at this conclusion? What are the potential problems you’ve you’ve fixed?

You really need to be pushing your test code and documenting the issues you’re having in detail, along with test results, errors, etc., somewhere like on a Github wiki page on your repo. More eyes are a good thing - other students are working with rpmsg, and someone may in fact know exactly what’s going on. (Plus, that’s part of that content being pushed 5 days/week requirement - if you ain’t pushing commits you need to be publicly documenting what testing, debugging, etc. you’re doing).

A bunch of stuff came up this week, so I didn’t get so much time in.

Last week:

  • Determined there seems to be a hardware issue preventing the Green from even seeing the Grove 10dof IMU at all. Uncertain if the issue is with the green or the sensor. The cable and connections seem fine.
  • Looked into using DMA instead of rpmsg for transferring ADC reads back to the ARM.
  • Added the ability to configure the ADC to the firmware to non-defaults.

Issues:

  • DMA info is fairly sparse and seems to all be pretty old.

This week:

  • Get the data transfer stuff sorted. This has been hanging on way too long.
  • Depending on how it gets done, convert basic userspace consumer and analysis to fit.

Last week:

  • Finally got the rpmsg stuff nailed down. Turned out to be kind of a nasty combo of compiler bugs (well, one, which mostly impacted debugging methods rather than rpmsg itself), inconsistent errors from stack smashing, some small stupid things, and some false negatives I have no explanation for.
  • Determined the issue with the IMU was due to a faulty IMU (and received a new one).
  • Got a secondary board mostly setup… still working out a few problems here, but I’m mostly ignoring it until the original board locks me out for awhile. Hopefully there won’t be too many more forced restarts now that rpmsg is sorted, so lock outs shouldn’t be such a frequent problem.
  • Confirmed my first go at reading adc values in userspace works.

Issues:

  • Nothing really.

Next week:

  • Improve some of the build stuff for the userspace side and also add more scripts to make it easier to work with the software/firmware combo. Right now when the firmware is active the board slows rather noticeably, which isn’t ideal when trying to quickly move through software changes.
  • Add some synchronization between the ARM and PRU1. Since the PRUs can’t control the pinmux, and the ADC uses the same lines for configuration and sending results, there will need to be some cooperation to get it going.
  • Start testing the ADC firmware on real hardware.

Alright so it’s probably past-due for me to catch up on these…

Going back a few weeks…

  • I added a basic request/response control scheme between PRU1 and the ARM, as the driver requires pin configuration changes, which the PRU cannot do. PRU1 makes all requests and awaits acknowledgement from the ARM that the request has been carried out.
  • This reorganized the PRU1 driver a bit and ended up creating a separate communications system.
  • Added a basic project-wide makefile and some other build-related stuff.
  • Initial versions of some project-wide scripts to easily start everything up.

Issues: The previous week I had some family stuff pop up, so I was out of town for a bit at the start.

This last week… (well week and a half I suppose)

  • Filled in some extra commands and fixed some glaring oversights in the PRU1/ARM req/resp system.
  • I redid some of the ADC control scheme. Made initialization dumber (and simpler) in some ways and smarter in others. It’s still pretty application specific but it’s a little closer to being a more general driver.
  • Added a (rather) simple way to use the built-in test functionality of the ADC.
  • Now the ARM side of the ADC software/driver (right now it handles both the req/resp stuff as well as more general results analysis - in the name of a general solution it should be broken up) publishes the determined tof over zeromq.
  • Implemented the non-ADC sensor side of things. It uses temp, humidity, and pressure sensors to estimate the current speed of sound.
  • It also pulls tof from zeromq and determines wind speed.
  • Brought PRU0 up to speed in terms of synchronizing with PRU1 and firing pulses.

Issues: The board won’t boot when the ADC is attached. After talking to some mentors it seems a few of the pins I need on PRU1 are also used for the emmc. Working on booting from SD now which will hopefully fix.

These may get dumped in the not-finished pile, but are worth mentioning:

  • Currently just supports one axis of measurements.
  • Look into some ways to get the timing on PRU0 a little more accurate. Right now there is probably some drift in the clock it provides, although theoretically that depends on what the optimizer is doing.

Upcoming (rather quickly…):

  • Get the board booting with the ADC and ensure the firmware is using it correctly.
  • Final report.
  • Other docs.