|
|
6670031bcc
|
implemented simple dataprocessor function. It (in TRANSPARENT mode) takes averaged data and copies it to the FFT_buff.
|
2025-10-06 16:08:42 +03:00 |
|
|
|
9b02f0af1c
|
somehow averaging fails (avg cycle stops too early. So in the result of avg there is sum of all runs in the start and some values in line are forbidden at the end of avg cycle). Fixed avg cycle numbering -> averaged value have the same amplitude as raw value
|
2025-10-06 15:26:24 +03:00 |
|
|
|
0ddc00750c
|
old commented mess was deleted. Implemented SEMITRANSPARENT (puts data to the TX_buff and then sends it) and TRANSPARENT (sends data by hdma directly) modes
|
2025-10-02 16:22:38 +03:00 |
|
|
|
99cc783f82
|
fixed transmitting to PC via HDMA. Clue: copy data to shadow array and check if it was sent via hdma_send_done()
|
2025-08-13 18:27:27 +03:00 |
|
|
|
d446e010f8
|
implemented transparent mode and simplest AVG mode: no average, identical to transparent
|
2025-07-22 17:45:22 +03:00 |
|
|
|
1555adc25b
|
Have been trying to force LARGE array allocation in SDRAM. Due to a bug somewhere in compiler or configuration, arrays defined in l502_user_process.c with '#include l502_sdram_noinit.h' or '__attribute__((section('.sdram_noinit')))' directives (that should allocate array in SDRAM) wrongly allocates in MEM_L1_DATA_A and overfills it. Workaround: define large arrays with these directives in l502_streams.c and include them via 'extern'.
|
2025-07-18 17:48:29 +03:00 |
|
|
|
63d839924e
|
firmware is working and compiling! modified cmd L502_BF_CMD_CODE_GET_PARAM (aka f_cmd_get_param()). Added param 87, which returns specific number 0xADEF (decimal 44527).
|
2025-06-27 17:50:46 +03:00 |
|
|
|
c73ead2643
|
git init of an empty project
|
2025-06-27 15:12:44 +03:00 |
|
