|
|
235fa386d2
|
FFT work mostly correctly with sin signals
|
2025-10-09 22:13:54 +03:00 |
|
|
|
b6636a0e83
|
implemented FFT amplitude dump. Somehow FFT is working, but now it is buggy. FFT results are connected with input signal, but this connection is not straightforward.
|
2025-10-09 22:04:31 +03:00 |
|
|
|
0dee57de4d
|
FFT is somehow working. FFT results are dumped to the PC as: 0xF1 -- Re, 0xF2 -- Im. But results are still weird: for both sin and DC signals from ADC it returns periodic waves in FFT results.
|
2025-10-09 21:42:17 +03:00 |
|
|
|
417285990e
|
FFT is correctly calculated for dummy (DC = 1.0) data!
|
2025-10-09 20:24:49 +03:00 |
|
|
|
2a30945bee
|
fixed angle and cos generation. Problem was in diffrent declaration of DATA_L and other defines in different files. Solution: fixed include tree
|
2025-10-09 20:00:48 +03:00 |
|
|
|
c12ae1f521
|
twiddle generation is defifintely wrong. Proved by flushing it to PC
|
2025-10-09 19:21:40 +03:00 |
|
|
|
2f6f7d9793
|
enabled FFT. But somehow it makes random-looking result. My next step -- flush twiddles to the PC and check them
|
2025-10-09 18:40:56 +03:00 |
|
|
|
eafa833ed6
|
introduced FFT into dataprocessor func. But it FFT is not enabled yet
|
2025-10-09 16:15:19 +03:00 |
|
|
|
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 |
|
|
|
42f53ae5a5
|
working averaging!
|
2025-10-02 20:46:27 +03:00 |
|
|
|
95cf79b61f
|
fixed and approved trigger searcher logic in AVG module
|
2025-10-02 20:01:11 +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 |
|
|
|
03cd22ef4b
|
backup
|
2025-09-16 13:23:11 +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 |
|
|
|
f19d963f09
|
working processing and transferring data to PC via TX_buff. TX_buff is still limited in size because it is located in a small L1, not in SDRAM
|
2025-07-17 19:08:56 +03:00 |
|
|
|
25742203e9
|
Succesfully transmits adc data to PC
|
2025-07-02 18:53:27 +03:00 |
|
|
|
9f7a38581f
|
working ADC and SPORT0 interface. Some SPORT0 data can be obtained by 0x8006 command.
|
2025-07-02 15:45:45 +03:00 |
|
|
|
9d2fb6760b
|
implemented BF_exec_cmd_simple() and BF_exec_cmd_with_arr() functions
|
2025-07-01 17:35:48 +03:00 |
|
|
|
d3d10dabaf
|
successfully executing multiple user commands
|
2025-06-27 19:16:51 +03:00 |
|
|
|
a86de4eece
|
successfully executing user cmd from file l502_user_process.c
|
2025-06-27 18:25:44 +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 |
|
