Midas2.0 Custom data

Hi Mithun,

Is this when using NFS or SD Card filesystem? Trying to directly access input data in real time via the SD card interface or over NFS can cause this issue. Since we want real-time here, we move the input data to DDR before we start processing instead of trying to access it directly from the SD card or NFS during processing. I will add this note to the wiki too. 

There are 2 files you need to look at to understand and make the change.

1. On your OMAP filesystem, if you see the file '/etc/fstab' (which I assume you have copied to OMAP from 'midas/ultrasound/initscripts' on your Linux host as per setup instructions on MIDAS wiki), you will see that 'tmpfs /var/volatile' is set to 128MB for MIDAS. This is to say that 128MB of the DDR can be accessed through '/tmp' on your OMAP filesystem.

2. If you look at the MIDAS 2.0 code, you will see that in the initialization code in 'main.cpp' we move the color data from OMAP's filesystem (on NFS or SD card) to DDR (/tmp) in the following lines of code.

if (access("/tmp/TI_Carotid_velturbdata_48x256x10x69.bin", F_OK)== -1) {
        system("cp ./userdata/InputData/TI_Carotid_velturb* /tmp/.");
        qDebug()<<"Heart Data to tmp (DDR) successful";   
}
if (access("/tmp/TI_Heart_velturbdata_64x256x8x143.bin", F_OK)== -1) {
        system("cp ./userdata/InputData/TI_Heart_velturb* /tmp/.");
       qDebug()<<"Carotid Data to tmp (DDR) successful";
}

Since we have only 128MB DDR available, and the above 2 files take up over a 110MB, remove the above 2 lines and replace it with one line that copies your custom color data (velocity/turbulence) from its location on OMAP's filesystem to DDR (/tmp), just as done above for the heart/carotid files.

Yes the way the demo is setup (bootargs, /etc/fstab, linux memory map), 128MB has been allocated for input data frames. It is important to reiterate here that our goal with MIDAS is not to build a complete ultrasound end solution, but provide a system-level implementation example that allows customers to evaluate a hardware platform, and also help them see how TI's software framework and libraries can be leveraged to quickly get started on programming these heterogeneous and homogeneous multicore devices for medical imaging. In a real ultrasound system there would be a transducer and front end that sends unlimited data in real-time via some high speed interface (like SRIO or PCI-e) to the DSP-device. With MIDAS, we don't do any front-end implementation (since that's not our aim here). The 69 or 143 or 'n' frames of post-IQ data are enough to showcase real-time processing and help customers evaluate the device. From the DSP's perspective, it doesn't care what the front-end is, so we loop through the same 'n' frames of data continuously to mimic the function of the continuous flow of data coming in from a typical ultrasound front end. The DSP processes these frames in real-time and displays the output at the set display rate.  In Ultrasound v3.0 onwards (as noted in the comparison table on the wiki), in addition to the above, the difference in acquisition and display rates is also handled. The acqusition thread "mimic(s) the function of the ultrasound front-end as in a real system, where input frames would be continuously received at a set acquisition frame rate. The Front End Interface (function block) serves this role, where in it fires an INPUT_RDY event every (1/acquisition rate) seconds. The clock ticks are derived from the SYS/BIOS Timer module." 

Thanks for the details.

Regards,

Mithun