Save CSV missing in Logic Analyzer about la104 HOT 6 OPEN

File system operations in logic analyzer app are not implemented. I am currently not planning to implement them, instead of it I would like to make completely new logic analyser app with custom FPGA image... (neither this is planned in near future)

from la104.

I fully understand. But I figured I could contribute by adding this so I have successfully built the project. Then i looked at some of the apps that do file writing and added a similar code in test17_official but the results are either that the app crashes on start or that the file I write contains junk. I obviously missing something fundamental. Can you provide some guidance?

from la104.

For new applications I use following approach:
https://github.com/gabonator/LA104/blob/master/system/apps_featured/test33_temper/logger.h

When you use filesystem routines in read only mode, everything works fine. But when you need write access, there is one tricky part. You need to provide the FS library extra buffer with size of disk sector. That means you will waste extra 4kB of ram. Now I can't remember exactly, but I think that I already had to reduce size of some of the internal buffers in official app to be able to run it in my OS. My guess was that by reducing the buffer sizes by 4kb would make the analyser app useless. But you can try...

From the building script the "Files.c" source code is completely removed, you need to add it there
https://github.com/gabonator/LA104/blob/master/system/apps/test17_official/build.sh

And in AppBios.c there are just blank implementations, you should comment them out:

// stubs!
u8  Save_Bmp(u16 FileNum){ return 0;}
u8  Save_Buf(u16 FileNo){ return 0;}
u8  Save_Csv(s16 FileNo){ return 0;}
u8  ReadParameter(void){ return 0;}
u8  SaveParameter(void){ return 0;}
u8  RestoreParameter(void){ return 0;}
u16 Load_File_Num(u8 Tpye){ return 0;}

So the only issue is that I could not fit the DiskBuf buffer into RAM, see the original code:
https://github.com/Ralim/LA104/blob/master/LA104_APP/LA104/Src/Disk.c

u8   DiskBuf[SECTOR_SIZE+32+28];  

You cold possibly alter the linker script to use as much ram as possible. Or the other option is to switch to 512 byte sectors.

Building the application shows that it uses 22kB of ram, OS uses 11kB, in total the device has 48kB of RAM, so it could possibly fit even with the disk buffer. But we must count with the RAM occupied by BIOS provided by miniware. Looking at the original source code:

https://github.com/Ralim/LA104/blob/master/LA104_APP/LA104/STM32F103_APP.icf

shows that we have 41kB RAM available for user apps/os, so the BIOS seems to take just 7kB of RAM, so final calculation: 22+11+7+4=44, and 44<48 so we have 4kB for stack. Looks feasible.

from la104.

Thanks! Did some quick test runs and if I reduce the sample buffer I get the file write working.
One more question: Would unloading the USB driver before launching the app free up any memory?

from la104.

When you build the OS, it will produce symbols_ram.txt in Build folder. It shows the list of largest blocks placed in RAM:

20001504 00000004 B pUser_Standard_Requests **
2000136c 00000004 B px
20001370 00000004 B py
200014fc 00000004 B sharedPixel
200026bc 00000005 B Page00_Inquiry_Data **
200026c1 00000008 B ReadCapacity10_Data **
200026d0 00000010 B CSW
20000320 0000001c B BIOS::FAT::g_directory
20002750 0000001c B massDevice_Info
200013b8 0000001c B pEpInt_IN **
200013d4 0000001c B pEpInt_OUT **
200026e0 00000020 B CBW **
2000279c 00000020 B common_Callback **
2000276c 00000020 B masspCallbacks **
200002fc 00000024 B BIOS::FAT::g_file
2000270a 00000040 B Bulk_Buff   **
20001374 00000040 B BIOS::OS::strGlobalArgument
200013fc 00000100 B gBuffer
20001528 00000134 B BIOS::GPIO::UART::mUartBuffer
2000033c 00001030 B BIOS::FAT::g_fatfs
20001680 0000103c B DiskBuf        **

But this is not 100% accurate, "B" means bss section, we should look for all entries marked with "B" or "D" after calling:

nm --print-size --size-sort -gC output_la104.elf

The largest are DiskBuf and g_fatfs for filesystem access. The first one is used for USB driver and the later one is necessary for the FAT filesystem access. So yes, we could save some ram (marked with two asterisks)

But considering that BIOS has its own filesystem functions which I do not use, it means it will have similar full-sector-size buffer somewhere in its RAM. So I had idea to reuse this buffer and point BIOS::MEMORY::gSharedBuffer to it, so we would have 4kB extra...

So the answer is yes, we could save 4kB by swithing off the SUB mass storage when the application is running. We could expose the address of DiskBuf through BIOS::SYS::GetAttribute, then set BIOS::FAT::SetSharedBuffer to use it and disable the USB with BIOS::USB::Disable() at the beginning of the app. At the end we could turn on the USB support by calling BIOS::USB::Enable() and hope that it will work (maybe BIOS::USB::InitializeMass will be necessary as well)

from la104.

Some news

Good: I managed to implement the CSV export by reducing the recording buffer. It was set to 4x4096 bytes. I have found that 4x1200 bytes is the limit for working file operations. I think this is sufficient for most use cases. If more is needed one could read the rest from the FPGA when writing the CSV file.

Bad: The IN menu is broken I cant understand why...

Note: The actual usage of the buffer was limited to 4x500 bytes compared to ~4x4k the official implementation.

Changes are on my branch. I also have BMP export working but it is not pushed yet.

from la104.