Jeep

Sure I get the concept, it's a good idea to handle the "RDS decoding" in a separate class/dll so it can be used for more than one hardware. (if the hardware gives you raw RDS data).

I stil havent hade time to connect by HQCT yeat but will do soon, then I will dive into this and start testing/codeing.

Evo

Fmode can you make your code available in a Zip please, especially the RadioHal and RDSInterpreter

For people to develop radio.dll's that comply with your RadioHal interface you need to really issue a compiled version of your RadioHal, so that namespaces remain consistent so that consuming applications e.g. centrafuse plugins can safely late bind to the objects.

I'll take a look at doing a Silabs radio.dll in C#.

Cheers

__________________
Life moves fast, so don't get left behind, buy a fast car!

FMode

This is the best posting in the complete forum !


Can you PM me your Email so that I can send you the newest build ?
(this interface (especially RDS Interpreter) is still "fluctuating")

Maybe we have to go on a developing platform like CVS if more people start developing.... So that we can check out the files...

and:
My Interface is a proposal so: discussion welcome...

I am unsure about the namespaces... may be we (the Frontends) can also query the objects if it implements the interface...
I don't know which advantage this has.... may be its useful if the dual-tuner-switching-layer (Senario 4 from my Drawing) has to generate 2 instances of objects with the same interface (FMRadioHal_HQCT and FMRadioHAL_SILABS - to name one example) from 2 different assemblies...

And I hope Centrafuse will consume this interface directly .... instead of its "ICFRadio Interface" which is nearly the same but only 10% of the RDS (FMRadioHAL, RDS Interpreter) functionality.

FMode

so nearly all RDS (expect TMC) features are now included....

My TestGUI represents the object-model inside more or less nice

Attached Images

 

CSharper

and the heavens will shine on it and we shall call it "n-tier architecture"

I'm in... let me know how I can get involved.

FMode

I converted it to an offical open source project with open tasks waiting for unbusy developers (and non developers!) !!!

http://developer.berlios.de/projects/fmradiohal/

TMC interpretation coming soon !

n-tier architecture !
nice word !
So FMRadioHAL is an n-tier architecture driver !

TheLlama

SO, where is the current RDS implementation?

FMode

digging out an old thread

I thought nobody is interested in it....
nobody joined and it was only work to care the SVN repository so I stopped uploading..

Linux:
much better than Windows (embedded) IMHO (more cheaper, opener, flexible)...
I don't know much about Linux but I talked to a Linux professional about the Linux counterpart of ActiveX/COM and he said that there is none. This breaks Linux's neck IMHO especially for car usage (where COMponents have to work with each other -> see Centrafuse). Yes I know MONO - and I think this could be the break-through-the-wall for Linux....

You know that my RDS Interpreter is an isolated (.NET) component (not baby mashed with radio driver stuff) that I think should run on MONO (because it uses only System Namespace stuff).

My RDSInterpreter component is now around 4000lines of code. Missing is (still) TMC interpretation...

My intention/idea for the future was not to give away the code because I don't want to support baby-mashing-programming (mixing everything) style - copying out my code instead of using the interface. (I have a 2. version with the same interface of the RDS interpreter which feeds its data to a COM(hardware) interface mixing with NMEA from another Port - this is already working - tested with Na..... N.K - this 2. version should be not distributed too public )

And yes I see the Linux/Mac/... community so you can have the code but for windows I don't see a reason why it should be reimplemented again and again (as it also could be used by COM (VB6) Clients).

TheLlama

I think your COM or .NET assembly is a good thing -- for Windows users. Even if we could get it to work with MONO or something, may "Linux purists" such as my self would not want to use it. Why download MONO, and have to convert your project to use .NET, etc; when we could just design it for the common denominator: C? That is why I want to port your RDS component to Linux. What we would have in the Linux Universe is this:

HQCT Kernel Module: Runs as a driver in the kernel. Handles Radio Interrupts and sends low-level commands to the module. Written in C and ASM.

HQCT User Library: A C Library that has useful API functions. This library talks to the kernel module. Other language bindings can either wrap the C functions, or just reimplement the C library (talk direct to the driver).

HQCT RDS Library: Used in unison with the User Library. Provide RDS decoding.

Anyways: I already have parts 1 and 2 done. Part 2 (the user library) is a very nice API IMHO. Much better than in Windows where each frontend has it's own redundant code. Part 1 could use some optimizations

Could I get a copy of the latest RDS source code in order to write Part 3? I don't think we can get a single 'universal driver' that will work on all OSes- Mainly because Windows is áss-backwards. However, we can have a similiar interface on all OSes. What we want, at least, is ONE implementation per OS.

FMode

Because C sucks ... language is something a bit of personal taste... and thats why I like .NET because it frees from the language...

I must agree MONO needs some development before it could be used 100% on Linux.... Until then you have to go "Linux native"...


agree...
I need your emailadress for this

May be you can convert my VB.NET stuff to C# ? This may help porting...
...and you know SharpDevelop ? (should help you for this job - and has a great converter I use a lot of time)

TheLlama

I don't want to get into a language war. However, I do not see how C# "frees from the language". If this were true, then I wouldn't need to write a driver for Linux because everything would "Just Work". Your design choices make great sense on the windows platform, but just doesn't make sense in Linux. Designing the C Library in Linux will allow other developers to write bindings for their favorite language (Python, D, Ruby, Perl, C++, Whatever..) because all of these languages can call C code by some means.

I may help you convert to C#, but what does this help with? Don't you just want ONE version of the .NET driver? Besides, C# is nothing like C, so it isn't like changing 1-2 lines. Anyways, I sent you a PM with my email address - I'll let you know how things proceed. Thanks alot!

FMode

same goes for native Windows DLL's ... they suck (their handling)... datatype troubles (is "Int" 16 or 32bit in this language?) sucks too...
(IMHO)


No That was a hint from me to use the automatic code converter from SharpDevelop to get "C"-style out of my code....

Don't get me wrong: Micro$oft does a lot of crap IMHO - but .NET I would exclude...
I think I really have to install a Linux and tryout MONO ?

TheLlama

Everything has their ups and downs. However, we simply cannot require MONO/.NET for our Linux driver. Simply - MONO just still isn't supported widely enough. Yes: if written for MONO, everyone with MONO should be able to run it. However: I do not want to require that every Frontend on Linux depend on MONO, that just isn't reasonable. In Windows, this would be reasonable because .NET is so widespread.

The analogy would be if I wrote a driver for windows that required KDE. Who uses KDElibs on Windows?? No one! The same is *almost* true on Linux.

So- how about sending the RDS source to my email address. I promise there will be no babymashing

FMode

this gets a little Off topic...
But I think the users could be "forced" to install a (free) application.




Look into your SPAM folder of your lama_at_gmail Acount

TheLlama

FMode, I have 3 gmail addresses (at least). Two of them have llama in the name (at least). I sent you a PM with an email address I check. Thanks again.