Hi Tony
Thanks for responding to my post! My project requires a lot of
explaining and could bore people to death but here are the basic goals
and an outline of the problem:
Goals
1)To enable scientists to control their instrumentation, to collect data
and to process that data
2)To make a revenue stream out of this
3)to use technologies I like
4)To use technologies I am competent with.
Outline of the Problem
The normal scenario for this is:
1)A company writes windows based software and uses a proprietary
interface board(usually GPIB)
2)A company does the same but uses an off the shelf board and suffers
with a lot of piracy
3)The same as above but they use serial
The market is now moving towards ethernet but there is still millions,
if not billions of dollars worth of equipment that uses GPIB/RS232.
Ethernet based vendors are moving towards remote authentication, like
Microsoft. I don't want to employ this.
I switched from Windows to Linux about 10 years ago. Windows does not
seem stable for anyone and I would have a hard time providing technical
support on this platform.
For the longest time, I thought about doing the same as these other
companies but doing it on Linux. However I can't see a revenue model.
There are other options but I would prefer the GPIB card option and that
requires linking code to the kernel and that means GPL which is the
worst thing for me as I will obey it but I cannot enforce it afterwards
due to the locations of my customers.
I have thought about an all eLua device but I can't see how the
scientists could crunch their data afterwards. I have thought about SBC
computers running Linux or BSD but the I/O is a problem.
Now I am thinking of writing a desktop application to crunch the data
and a SBC + eLua solution for instrument control and data collection,
splitting the problem in half.
I could link the SBC and eLua via I2C or SPI as it would ship a neat
tidy product. However I am concerned that the GPIB portion will overflow
the data abilities of these protocols.
Your idea of mixing already existing devices could work, I think I would
just have to work out the packaging of it. Creating an eLua based board
would also help the revenue model though as there would be one more
thing that would have to be re-engineered and not just purchased off the
shelf, and that could slow down competitors.
Thanks again
P.S
I would like to mention that Quentin sent me an incredibly detailed
overview of a variety of devices. I hope to get back to the tutorial
series I was not able get done. I am armed with much more information
this time around.
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev