FreeCalypso > hg > freecalypso-tools
view rvinterf/include/limits.h @ 1014:961efadd530a default tip
fc-shell TCH DL handler: add support for CSD modes
TCH DL capture mechanism in FC Tourmaline firmware has been extended
to support CSD modes in addition to speech - add the necessary support
on the host tools side.
It needs to be noted that this mechanism in its present state does NOT
provide the debug utility value that was sought: as we learned only
after the code was implemented, TI's DSP has a misfeature in that the
buffer we are reading (a_dd_0[]) is zeroed out when the IDS block
is enabled, i.e., we are reading all zeros and not the real DL bits
we were after. But since the code has already been written, we are
keeping it - perhaps we can do some tests with IDS disabled.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Tue, 26 Nov 2024 06:27:43 +0000 |
| parents | ca6e969be6ee |
| children |
line wrap: on
line source
/* * For sizing our buffers etc in the rvinterf suite, including the local * UNIX domain socket protocol between rvinterf and fc-tmsh etc, we need * to have some limits on the message sizes in both host->target and * target->host directions. * * For the host->target direction, the choice of message size limit is * easy: the packet Rx code in RVT on the target side also has a limit * (quite naturally, as it needs to use a static buffer to reassemble * incoming packets as they arrive at the UART in unpredictable interrupt- * sized chunks), so we set our limit to match that in RVT. */ #define MAX_PKT_TO_TARGET 255 /* * In the other direction (target->host), there is no fixed limit * definition easily visible in the target fw code: any fw component * can call rvt_send_trace_cpy() or rvt_mem_alloc() followed by * rvt_send_trace_no_cpy(), or some higher-level API that reduces to * these functions, with a message of any size, subject only to memory * limits, which obviously aren't as strict as a #define'd maximum * message size. * * With current FreeCalypso fw, unchanged from classic TCS211 in this * aspect, the largest RVTMUX packets emitted by the fw are G23M PS * primitives forwarded externally via GPF routing mechanism, and some * of them exceed our previous arbitrary limit of 512 bytes. However, * the largest output packet size that can be generated via this * mechanism equals the largest partition size in GPF partition pool * configuration, and that largest size is 1600 bytes. Hence we have * our answer as to what maximum packet size we need to support. */ #define MAX_PKT_FROM_TARGET 1600 /* * Both limit definitions above counts all bytes between the opening and * closing STX flags, but not DLEs inserted for binary transparency. */