A.J.'s Notes
| Day | Description |
|---|---|
| 1-6-15 | Setup Workstations |
| 1-7-15 | Beaglebone kernel |
| 1-8-15 | Delfino UART/DMA |
| 1-9-15 | Xenomai on the Beaglebone |
| 1-11-15 | Beaglebone Kernel |
| 1-12-15 | Beaglebone Xenomai |
| 1-13-15 | Delfino Bootloader |
| 1-14-15 | Delfino Bootloader |
| 1-15-15 | Delfino Memory Layout |
| 1-16-15 | Delfino Base Project |
| 1-20-15 | Delfino Base Project |
| 1-22-15 | Delfino Base Project |
| 1-26-15 | Delfino ADC |
| 1-27-15 | Delfino ADC Sampling |
| 1-28-15 | Delfino ADC Sampling |
| 1-29-15 | Delfino ADC Sampling |
| [2-2-15] (#2-2-15) | Replacing the Delfino |
| [2-3-15] (#2-3-15) | Replacing the Delfino |
| [2-5-15] (#2-5-15) | PIC32 Data Processing |
| [2-9-15] (#2-9-15) | PIC32 Data Processing |
| 2-10-15 | PIC32 Data Processing |
| 2-11-15 | PIC32 UART |
| 2-12-15 | Replacing the Delfino |
| 2-17-15 | PIC32 Processing |
| 2-25-15 | PIC32 Processing |
| 3-12-15 | DAQ Configuration |
| 5-2-15 | DAQ Deployment Notes |
##5-2-15 ##DAQ Deployment Notes
Currently the receive script assumes everything is aligned. If this is not the case, which it often isn't we run into weird potential data loss issues where "END" can be counted as data and data is counted as "END". We in the future should validate this and look for alignment, maybe read into a buffer until we see END?
CRC: we probably should move to CRC32 since we're using 32 bits for it anyway. I'm still super confused what's wrong but can't easily test fixing this without pants because of above. The same data (say all A's) will give different CRCs different times. Won't be easy to fix until we get pants because of above.
Timer:
I decided to use pthread instead of using timer_create so that the file operations are done entirely on a different thread.
##3-12-15 ##DAQ Configuration These past two weeks I've ran into a lot of issues while trying to get configuration of the DAQ working. I should not use my home machine to work with our PIC32 since MPLABX loves giving me errors to do with being unable to power the device.
The configuration works but I'm now working on dealing with an issue with the Acquire code.
Currently we do occasionally get corrupted data. This is due to latency issues on the host machine. It is unable to read the data fast enough. To deal with this I'll look into utilizing a realtime kernel.
Another issue I'm having is some form of overflow randomly happening after running the script for >3 minutes. Sometimes it doesn't happen at all. I'm pretty sure this is due to an unchecked read into a statically sized buffer with FT_Read. We should ensure that the actual read size is less than the size left in the buffer.
##Fixing the Beaglebone Aquire
We started having a problem of the beaglebone not being able to utilize the d2xx driver.
Here's the related error:
/usr/bin/ld: error: largeread uses VFP register arguments, /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../libftd2xx.a(ftd2xx.o) does not
##2-25-15 ##PIC32 Processing
After getting everything working I investigated doing calculations too see how many clock cycles a single RMS calculation would take. This is using very generous numbers: We are assuming 300 clock cycles for all multiplication and square root operations. 6 clock cycles for everything in the loop other than the one multiplication. This means 306 clock cycles per data point in the window size. Then a extra 3 more square root/multiply operations at the end so 900 more clock cycles. So with our current window size of 1562 it takes: 3061562 + 3003 clock cycles or 478872 clock cycles.
##2-17-15 ##PIC32 Processing While working with the PIC32 to process data I noticed that the byte order isn't exactly as expected so I'm going to document the data ordering here: With the original byte order 0 is a filler 00 1-3 is channel 0 4-6 is channel 1 7-9 is channel 2 10-12 is channel 3
Due to differences in endianness though there's quite a bit of byte swapping that's happening. Here is code that's used when working with these numbers:
ch0 |= (tmpBuff[i+2] << 16); ch0 |= (tmpBuff[i+3] << 8); ch0 |= (tmpBuff[i]); ch1 |= (tmpBuff[i+5] << 16); ch1 |= (tmpBuff[i+6] << 8); ch1 |= (tmpBuff[i+4]); ch2 |= (tmpBuff[i+8] << 16); ch2 |= (tmpBuff[i+9] << 8); ch2 |= (tmpBuff[i+7]); ch3 |= (tmpBuff[i+11] << 16); ch3 |= (tmpBuff[i+12] << 8); ch3 |= (tmpBuff[i+10]);
It's important to note though that at this point there was already an endianness swap with each 32 bits being treated as a single 32 bit integer. This means in the actual array we have this layout.
0 CH0
1 0 filler byte
2 CH0 << 16
3 CH0 << 8
4 CH1
5 CH1 << 16
6 CH1 << 8
7 CH2
8 CH2 << 16
9 CH2 << 8
10 CH3
11 CH3 << 16
12 CH3 << 8
##2-12-15 ###Replacing the Delfino In the process of writing the report I realized I made a mistake for my intilial comparison of the alternatives. Even some of the smaller boards such as the Raspberry Pi are too big for our specifications of 4x10x3cm. I'm not sure what to do about this at this point. Only the Intel Edison of the chips I looked at actually fit within the size specifications and it would not be an easy chip to work with.
##2-11-15 ###PIC32 UART I read up on the UART for the PIC32 so we can utilize a UART channel to send configuration information. Here is the reference manual which was helpful
##2-10-15 ###PIC32 Data Processing I spent most of the day looking into getting programming on the PIC32 on the DAQ2 working (before today I never tested anything). I also had an update from Pavlo as to what the code does. It's worth mentioning the LED blinking code was recently re added.
##2-9-15 ###PIC32 Data Processing I got a better look at what we were going to do on the PIC32 and we will not be doing continuous sampling. By doing windowed sampling we can more easily do slower operations such as RMS calculations.
##2-5-15 ###PIC32 Data Processing
Along with Henry we were tasked with making the PIC32 form some degree of processing of the input data before sending it off to the ESP to send the data to the server.
It's worth noting that even a calculation of RMS would be very slow on the PIC32. Squaring, multiplication, division, and square root are all very slow operations on the chip. The most extreme being square root which may take up to 700 cycles. With all of this we must be very careful and lower the sampling rate to a degree where we can handle the data. It's also worth mentioning that all the work required to actually send the data to the ESP (converting to strings) is fairly expensive and will add even more overhead. We're probably looking at a maximum sampling rate of 1KHz.
##2-3-15 ###Replacing the Delfino I'm having a hard time choosing between the Raspberry Pi 2 and ODROID C1. They're both $35. The Pi2 has more support but is harder to get and might be less powerful. The ODROID C1 isn't documented or supported as well but it is readily available and should be somewhat more powerful. The ORDOID claims to use 0.5A (@5V) typical while the Raspberry Pi claims to use 0.6A. Since the ODROID has a higher clock rate CPU using a larger manufacturing technology and DDR3 ram instead of LPDDR2.
##2-2-15 ###Replacing the Delfino I've concluded the Delfino isn't worth using. It's too complicated to use the integrated ADCs to sample data. A flag is required to be toggled every 8 samples. There seems to be no easy way to use DMA to copy the data from the ADCs.
##1-29-15
###Delfino ADC Sampling
It turns out that the base code given by TI did not properly set the acquisition window for bit 8 of the ADC. After fixing this the spikes disappeared. There is still some degree of noise on the ADC.
Here's a sample at 100mVpp.
Moving on to a project with the sampling. I'm currently running into the issue that if I utilize the UART during an ADC sample after a few samples (typically after the 7th one) the ADC doesn't continue to convert. I attempted to add EALLOW after the UART writes to no avail.
Because of that issue currently the UART code for the ADC writes out the data sampled after pulling 256 samples. It then repeats. I should possibly investigate directly reading the sample into the UART FIFO. Or utilizing DMA to copy the ADC data directly to the UART FIFO.
After investigating the issue further changing the number of characters written (I was using one before) changes the number of times it takes until the samples stop working. It appears to happen after at least 7 characters are written. However sometimes it's more. It usually appears to be while on the second buffer but this hasn't always been the case.
##1-28-15
###Delfino ADC Sampling
Worked on getting a full UART based project to sample via the ADC. Right now the problem seems to be unusual spikes appearing in the data.
Here's a zoomed in picture of a sine wave. The general shape is correct but these small spikes appear regularly.
I will need to investigate this issue further before I finish this project.
It's worth mentioning if we plan on using the CLA to process ADC that "[t]he CLA can not access the ADC configuration registers so it can not clear the ADC interrupt flag."
##1-27-15 ###Delfino ADC Sampling I wasted way too much time finding the right pin for this. I need to remember to use TMDSCNCD28377D_180cCARD_pinout_R1_1.pdf not any of the other PDFs when looking as to what pin is correct. I got the ADC to sample data and was able to verify the data appears to be correct. Next up will be getting data for Pavlo to compare with the current hardware he is working on. It'd be a good idea to get the data to be sent out via UART in some usable format.
##1-26-15 ###Delfino ADC I began reading up on the Delfino ADC since this week my plan is to look at the ADC data. I wasn't able to find much in any documentation other than timings and electrical specs.
##1-22-15 ###Delfino Base Project Now that we have a small base project which can run from RAM or FLASH that can debug over the USBUART now the next feature that is needed is DMA transfers to the UART. Today I got the interrupts for the UART added to the base project. Now I need to add a DMA to directly transfer instead of doing it inside interrupts.
##1-20-15 ###Delfino Base Project Got the base project fully working, fixing issues with pin multiplexing on the LEDs. First commit of the base project to the GitHub.
##1-16-15 ###Delfino Base Project Set up the base for the initial Delfino project using the knowledge gained in the past week. Will be able to debug from USB UART and to DMA over data via UART.
##1-15-15 ###Bootloader Goals The attempt of the bootloader is to load up a .out file from the microSD for a project for both CPU1 and CPU2 and launch them as if they were being launched from RAM via the debugger. This will make it so that we do not need to worry about our code working differently when we run it away from the debugger. Instead of developing a bootloader and using a microSD it should be possible to develop a program for FLASH. That program can copy vital functions to ram. We can still upgrade the device via a small program that loads up into RAM and reprograms the flash. Additionally if we run from RAM there is the problem that there is much less RAM than there is FLASH. 10k of usable RAM for a program vs ~50k of usable flash (or more). Due to this reason I've concluded we're just going to use FLASH.
###Delfino Memory Layout Relinking this valuable page Our bootloader will need at least some memory to run. It is a good idea to make it share stack/bss space with the loaded program. (Info leak, security issue but probably not a big deal).
For RAM This appears to be the location of the more important segments:
| Segment | CPU1 (RAM) | CPU2 (RAM) | CPU1 (FLASH) | CPU2 (FLASH) |
|---|---|---|---|---|
| .text | M0 D0 LS0-4 | D0 LS0-4 | B-E | B |
| .stack | M1 | M1 | M1 | M1 |
| .ebss | LS5 | LS5 | LS5 GS0 GS1 | LS5 |
| .econst | LS5 | LS5 | F G H | B |
| .esysmem | LS5 | LS5 | LS5 | LS5 |
The important difference is that CPU2 isn't using M0 for the .text. No idea why this actually is. It's probably safe to just do everything the CPU2 way and we will only use M0 if we need the extra space.
The general plan for now is to use D0 and LS0-4 for our .text. The stack will be in M1. The bss/const/sysmem will all be in LS5.
As for the flash program the biggest issue appears to be the fact that CPU1 uses more banks than CPU2. All that means is we will need to possibly allocate more banks if we run out of space. For the flash program we can plan to do it as CPU1 does.
###Reading in the file While reversing the binary format so we can actually load it is still on my todo list here are some remarks on actually getting the file in.
As mentioned earlier the microSD will need to be 2GB or less since I don't want to program in SDHC support. It's not worth the time just for more space than we need. It is probably a good idea to separate everything into different files and read them as needed. The goal for now is to just copy the .out files from CodeComposer on to the root of the microSD. One project per core, for now to be simple we'll just do everything as is in that project. If we end up caring more about performance we can move on to building a basic OS with multi threading.
Questions that need to be answered:
- Can we access the debug USB from CPU2?
- Can we access the microSD from CPU2?
- If we can is the a problem reading from it from both CPUs at once? (probably)
Likely the plan will be to load up the binary file for CPU2 from CPU1. CPU1 will talk to CPU2 though IPC and send the actual binary file by using shared ram.
###Making a Delfino Project Everything in the samples is directory dependent making it really difficult to switch to a more
##1-14-15 ###Delfino Bootloader A:SW1 can be used to turn off UART. Look at it if UART breaks. The provided microSD code does not support SDXC. Should investigate if it supports SDHC or not. If it doesn't we'll have to use a microSD that's 2GB or less. Noticing that random characters are being dropped. I should be aware of this in the future. I plan on reversing the format more on Friday over the weekend so I'm going to start building the basic structure for the bootloader now.
##1-13-15 ###Delfino Bootloader I tested a few simple projects from both flash and ram. Because of how slow it takes to program to flash (>3 minutes for a 500kb file) and the fact that we only have about 4MB max of usable space on flash I decided a microSD card is the way to go.
I tested the built in microsd code and it worked without any issues at all.
##1-12-15 ###Beaglebone Xenomai I attempted to install a pre built Xenomai package from rcn-ee.net's package system, both v3.8.13-xenomai-r69 and v3.14.26-ti-xenomai-r44. Unfortunately the Beaglbone would no longer boot when using those kernels. I finally gave up on Xenomai for now, I'll probably want to look more at this page and installing from source more cleanly than the hacks provided in the wiki.
Giving up on Xenomai I switched to the linux-rt image that at least mostly worked.
Before when I got it I was doing apt-get update by doing apt-get dist-upgrade I was able to actually fix the USB to some degree. It shows up as a serial device though the /boot isn't mounted, usb ethernet doesn't work, and when connecting to the serial port we don't get a login terminal. These are all likely software issues and can be fixed.
###Delfino Bootloader Design While all this was going on I worked with the Delfino chip more. I began looking into designing the bootloader. I need to decide between using the on board flash and a microsd card. Page 62 of this provides valuable information needed for designing the bootloader.
##1-11-15 ##More Beaglebone Kernel Unbricked the Beaglebone and ended up re bricking it multiple times while attempting to install Xenomai from source. I downloaded a pre built image which had linux-rt as the kernel. While it worked it broke the usb capabilities meaning the only way to communicate with the device was via SSH. Since this works I'll likely use this if Xenomai ends up not working out.
##1-9-15 ###Xenomai on the Beaglebone Installation attempted again and failed. The problem appears to be that the build scripts are broken and generate files instead of directories. One of the problems being in /lib/modules/3.8.13-bone69 with the folders kernel build and source
Also of an annoyance the build script deleted most of the filesystem.
##1-8-15 ###Delfino UART/DMA I got the sample code for UART and DMA to work and tested doing both in a dual core setting. It's worth noting that the sample code for the UART does not entirely work as stated "Characters typed in one terminal should be echoed in the other and vice versa.". As it originally was only the data from the micro-USB (/dev/ttyACM0) to the mini-USB (/dev/ttyUSB0) was mirrored.
For DMA everything worked great after the pins were discovered, have a look at TMDSCNCD28377D_180cCARD_pinout_R1_1.pdf in F28377D Pinouts-Schematics.tar.gz for what pins are what.
##1-7-15 ###Beaglebone Kernel The current kernel on the Beaglebone, standard Linux, has latency issues and will not respond to interrupts fast enough. Two kernels were investigated linux-rt and Xenomai. Based on this article Xenomai meets our situation better. It additionally is easier to install since there are instructions for installation also see this link. Note: I did not finish compiling the kernel and will have to resume this work later on.
##1-6-15
###Setup Workstations
Installed Ubuntu, core development packages, and Code Composer.
libudev0 doesn't exist in current repositories used a symlink from version 1:
ln -sf /lib/i386-linux-gnu/libudev.so.1 /lib/i386-linux-gnu/libudev.so.0e