On Fri, Jan 15, 2021 at 10:01 PM Aaron Olivarez <aaron_at_olivarez.info> wrote:
> There are two adapter workers in projects/assets/components/misc_comps/ ;
> one called iqstream_to_cswm and cswm_to_iqstream. cswm is short for
> ComplexShortwithMetaData, these allow you to hook up legacy workers. A good
> application to reference is fsk_dig_radio_ctrlr/fsk_modem_app.xml
>
Thanks for the quick response. I'll try using the cswm_to_iqstream and
iqstream_to_cswm components, but when I look at the example, they seem
commented out:
https://gitlab.com/opencpi/opencpi/-/blob/develop/projects/assets/applications/fsk_dig_radio_ctrlr/fsk_modem_app.xml#L121
There's also some DRC component (digital radio controller?) that is listed
but doesn't rely on the other slaves yet? Lastly, this seems to be called
an Application and not an HdlAssembly? Is that something new? Should I be
calling them applications and not HdlAssemblies?
My main confusion, now, is how the HDL was created and a bit file generated
when the protocols weren't matched up. I would imagine the mismatch at the
HDL level would cause tons of errors, but I only ran into an error when
running the actual FSK application on the host. Is it normal that the bit
file generated can have two components with different protocols connected
to each other?
Sorry for my confusion, but I thought part of the point of OpenCPI was to
not run into these issues at runtime but more at build time to ensure
compatibility.
Thanks,
Brian
Received on Sat Jan 16 2021 - 18:01:13 CST