Ok, back from vacation, and drinking less single-malt in the highlands...
I looked at the adat info. I spent about 3 years in the early 90s
writing operating systems, linkers, drivers, etc. for the original Sharc
processors.
We actually make a version of gcc for sharc for which CHAR_BIT was still
8, and sizeof(int) was 4.
I can't believe they are still making that architecture without byte
addressing...
I think the right model is indeed to define a "worker" to control each
interesting functional unit. Some of them will have dataplane I/O as well.
Imagine that the DSP was another OpenCPI-capable processor. Then those
workers would end up executing directly on the DSP container (someday).
The workers for functions that have dataplane connections would
fill/empty their buffers using some talk-to-Sharc APIs initially.
Our RCC model has essentially no "byte" aspects to it except that buffer
and message lengths are in bytes.
(We hoped never to live with a system where CHAR_BIT was not 8...).
And it is specifically designed to not require threads. So it is
definitely possible to implement a container on the Sharc.
Jim
On 6/13/11 4:55 AM, Frank Gönninger wrote:
Hi Jim,
no hurry! - Enjoy your vacation! ;-) Scotland, yes, on my list also ...
Yep, DSP and GUI currently are not available directly for OpenCPI access. I am working on
that, though. First step will be to make the TRX controllable via an outside
"relay" application that translates incoming requests via CORBA to the
proprietary protocol. Also, firmware upload should be feasible via OpenCPI.
Idea currently is to write that relay/proxy up using OpenCPI making the TRX look like a
controllable (but not yet executable) device being capable of responding to
"commands" (which I thought to model as Protocol Operations in OpenCPI).
Thanks in advance for your help and advice!
Frank
Am 13.06.2011 um 10:41 schrieb James Kulp:
I'll try to give you a response in a day or so.
I'm on vacation in Scotland.
So it sounds like you are suggesting that the GUI processor and the DSP
processor are not available to OpenCPI for running components?
It sounds like an interesting platform...
Jim
On 6/11/11 5:44 PM, Frank Gönninger wrote:
Dear OpenCPI gurus -
In my attempt to wrap my head around OpenCPI I am stuck with the following task:
I have a SDR transceiver (TRX) (see http://www.adat.ch - that's the device in
question) that I like to control via OpenCPI-based control software.
The TRX has four independent VFOs (variable frequency oscillators) for RX
covering 0.1 to 30 MHz. In addition there's one TX (sender) covering the same
range.
The TRX is comprised of three logical components: The DSP board, the Channel
Memory, and the Graphical User Interface (GUI). The GUI has its own processor.
The DSP board and the GUI require firmware to be loaded into the respective
processor's flash memory.
The TRX sports a USB interface with its own high-level protocol. Example: "$FRA!
30.0000" -> Set frequency of VFA A immediately to 30 MHz. Other commands are
available for uploading the firmware packages.
Now ... What would be a suitable start in formulating properties and operations ? I can't
seem to find a "good" way ... Any hint/advice/direction really appreciated...
Thanks !!
Regards
Frank
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
--
C o n s e q u o r C o n s u l t i n g A G
Frank Goenninger
E-Mail: [email protected]
Phone: +49 711 781 181-10
Fax: +49 711 781 181-11
Consequor Consulting AG
Liebknechtstr. 33
D-70565 Stuttgart
Vorstand: Frank Gönninger (Vors.), Martin Melcher
Aufsichtsratsvorsitzender: Dipl.-Kfm. Matthias Filbinger
Sitz der Gesellschaft: 70565 Stuttgart, Deutschland
Registergericht Amtsgericht Stuttgart HRB 727446
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
