embedlets-developer Mailing List for Outpost Embedlet Container (Page 34)
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer — Outpost Embedlet container developer list
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-04 00:13:37
|
Chris says: > One way to address this would be to have Embedlets designated as > thread-aware or unaware. The guidelines for thread aware Embedlets would > be set out based on RT requirements. It seems that that the container > would not have to be concerned with RT threading. Am I right?? Yup...that is one way to deal with it. But I don't like the idea of Embedlets that are thread aware or not. I would prefer to see Embedlets not have to worry about that, and the Outpost Build system to add any extra thread-based requirements depending on whether the Container was build to support threads or not (based on the platform's capabilities). That is, the design contracts and patterns that an Embedlet has to abide by should be of such a nature that whether the container was threaded or not should (ideally) be transparent to the Embedlet code. One benefit of this is the KISS principle for developers of Embedlets. Most Java developers have trouble with threads....so it would be much nicer if (like with Servlets) threading was transparent and you never had to use them directly. It may be possible to design the Embedlet base classes and Outpost Services so that even though they support the same invocation signatures, one version supports threads under the covers (using synchronized methods under the covers for instance) and another version just uses a co-operative approach without threads. There would probably be two different versions of the Scheduler/Event Manager Services as well. My gut feel is to implement in a 3 phase process: to first get a non-threaded implementaton of the Container working. Then learn from that and add threads. Then look at how to handle the RT requirements. If we try to do threads and RT off the bat, it will probably take way too long to get the first implementation out the door. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-04 00:04:28
|
>Ant is basically an automation system, that can automate the creation of >dists, jars, setting classpaths, etc. It's the most common build system >in Java. > >If you have a project with source tree and libs, you need to still add >them to the classpath. With ant it's just "ant", and it's so in >Jbuilder, Eclipse, Netbeans, Jedit, Jext, etc. Yes, it is an automation tool. And, just like CPP is an automation tool, ant can be abused to do configuration management because it's possible. The postgresql dist includes the use of Ant for no reason at all. The build process is stricktly Linux/Make based, and Ant is not necessary when Make is already in place. My IDE includes the ability to do all the things that Ant does, so I don't need to use Ant for my projects. Running unit tests and other such tasks is a good use for running these tests portably. The Ant task in postgresql does textual substitutions into the .java source files before building. The same things can be done at runtime with properties. I just want to make sure that complexity is only a necessity, not a chain reaction. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Christopher S. <cs...@oo...> - 2003-02-04 00:03:53
|
Here are some products that are addressing the Embedlets issues in proprietary ways. <http://www.jcontrol.org/> <http://www.ergotech.com/html/embedded_solutions.html> Gentlemen, we need a concerted effort to get an accepted Embedlet standard in place and convince these and other emerging vendors that it is in their interest and the market as a whole to embrace a standard, otherwise our efforts will amount to just a lot of email traffic and the industry will disintegrate into another 'my standard is best' scenario. I emphasize that we need a solid action plan based on Andrzej's architectural outline and at start to get some roadbed down in preparation for actual track. As the Vulture said to his buddy: "Patience my ass, I'm going to kill something!" Christopher Smith OopScope cs...@Oo... |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-03 23:36:57
|
Gregg G. Wonderly wrote:
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
>
>>Topic tags:[Arch][Wiring][Doc][HW][PM]
>>_______________________________________________
>>Gregg suggests:
>>
>>
>>>ndeed! My personal feeling is that any project that I can't load into my
>>>IDE, (in different projects if command line limits are an issue), and push
>>>the build button on, is not correctly designed. Clearly, building without
>>>an IDE is an advantage. But, I would strongly suggest that the project
>>>really should be buildable with some simple form of
>>>
>>> javac -d classes `find . -name '*.java' -print`
>>
>>Trust me on this one....we're gonna need Ant!
>
>
> And what build tasks are going to be so complicated? Odd jar packaging?
docs build
unit tests
distributions (with proper signing)
webapps
anything that is not just "javac blah blah"
> Building jar files with odd sets of files is about the only thing that seems
> plausible. That is a production issue and shouldn't appear in the project
> structure. Here's my desire... You should always be able to unpack the
> source tree into a directory, and make it know to your IDE. Adding your own
> source files, you should be able to compile into a single directory with
> 'javac -d' command line(s). You should be able to package this directory into
> a jar, and 'go'. You should also be able to provide this directory in your
> classpath to JEMBuilder like tools and get a linked product.
And does Ant make this impossible?
> It should not be necessary for developers to do any kind of manual steps to
> develop with the platform. Now, they might also just put the jars in their
> classpath using the distribution jars. But, if the want/need to customize
> classes therein, or otherwise recompile from source, that should be trivial,
> and just require unpacking the tree.
>
> I am really against leaning against Ant for any configuration management that
> can also be done in the code itself where late binding can yield some other
> advantages.
Who ever said that with Ant based projects you cannot get the sources to
build in an IDE?
Ant is basically an automation system, that can automate the creation of
dists, jars, setting classpaths, etc. It's the most common build system
in Java.
If you have a project with source tree and libs, you need to still add
them to the classpath. With ant it's just "ant", and it's so in
Jbuilder, Eclipse, Netbeans, Jedit, Jext, etc.
I don't see the problem, sorry.
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-03 23:36:26
|
Fellow Outpost Lookouts and Embeletites:
As I had promised/alluded earlier, the Outpost/Embedlets Architecture
Discussion Document, ver 1.2 (in .pdf format) has been posted in the
embedlets CVS repository on sourceforge in the following directory:
embedlets/dev_docs/architecture
Ted...there have been a few minor changes since the 1.1 version you were
copied on the other day (the one that never showed on the list ;-{ ). Check the
Revision History page (which was added in 1.2) to see what changed.
The purpose of this document is to provide an initial starting point for the
discussion of the Outpost Container architecture, the components (Embedlets)
that are hosted inside the container and the contracts provided by the
architecture (interfaces, services, etc.)
It is expected that this document will change and evolve over time, as the
design and architectural concepts are evaluated, refined and adopted, and will
eventually be a comprehensive overview of and introduction to the
Outpost/Embedlet architecture.
This initial document is my personal "architectural vision", and as such, is not
the "be all and end all" of what the Outpost architecture should look like. It is
simply intended as a starting point (since we need one), and will hopefully
result (eventually) in a final architecture that we can all use for guidance as the
various modules, services and tools that make up Outpost are defined,
documented, developed and implemented.
I hope everyone finds this Discussion Document to be a useful starting
point.
I suggest we start using some message subject prefixes to denote what
thread/area a message is pertinent to. You'll notice I prefixed this email with
[Arch] and will continue to do so for "Architecture" discussions. We might want
to use some others as the threads proliferate.
[Wiring] - Graphical Wiring aka: Ted's Topic ;-)
[Doc] - Documentation discussions (formats, word processors, etc.)
[HW] - Hardware discussions
[PM] - Project Management stuff
Go download the document and let the discussions begin!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
|
From: Gregg G. W. <gr...@sk...> - 2003-02-03 23:22:53
|
>Topic tags:[Arch][Wiring][Doc][HW][PM] >_______________________________________________ >Gregg suggests: > >> ndeed! My personal feeling is that any project that I can't load into my >> IDE, (in different projects if command line limits are an issue), and push >> the build button on, is not correctly designed. Clearly, building without >> an IDE is an advantage. But, I would strongly suggest that the project >> really should be buildable with some simple form of >> >> javac -d classes `find . -name '*.java' -print` > >Trust me on this one....we're gonna need Ant! And what build tasks are going to be so complicated? Odd jar packaging? Building jar files with odd sets of files is about the only thing that seems plausible. That is a production issue and shouldn't appear in the project structure. Here's my desire... You should always be able to unpack the source tree into a directory, and make it know to your IDE. Adding your own source files, you should be able to compile into a single directory with 'javac -d' command line(s). You should be able to package this directory into a jar, and 'go'. You should also be able to provide this directory in your classpath to JEMBuilder like tools and get a linked product. It should not be necessary for developers to do any kind of manual steps to develop with the platform. Now, they might also just put the jars in their classpath using the distribution jars. But, if the want/need to customize classes therein, or otherwise recompile from source, that should be trivial, and just require unpacking the tree. I am really against leaning against Ant for any configuration management that can also be done in the code itself where late binding can yield some other advantages. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-03 23:06:48
|
Jac Kersing wrote:
...
> Call me a wimp, but I'm not to fond of LaTeX, troff or any other document
> production systems that forces me to mix content and formatting. (That's
> why I use XmlmindXmlEditor with stylesheets for docbook editing)
>
> Mixing content and formatting tends to draw focus to the formatting, not
> the content. But that's just my problem of course...
That's also a concern of all Forrest developers. The Forrest DTD is
purely semantical, no presentational tags. Just to let you know you're
not alone ;-)
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Nicola K. B. <nic...@ap...> - 2003-02-03 23:05:33
|
Jac Kersing wrote:
...
> Ok, if OO is able to output PDFs and HTML we should be set, shouldn't we?
There is a very simple way of making PDFs out of *any* document: print
to a PS printer and redirect to file. Then run Ghostscript on it and you
get the PDF. For Wintel there is FreePDF that automates these steps, so
you print and see the PDF right away.
But one thing is producing a document, another is making a site...
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Nicola K. B. <nic...@ap...> - 2003-02-03 23:02:44
|
Jac Kersing wrote:
,,,
>>I find CVS diffs to be really better because of the way CVS works with
>>multiple committs, merges, etc.
>
> Have you tested OpenOffice merging?
I mean in a shared environment. Are you able with OO to browse the
previous diffs in time, or branch? Simple merging is just one aspect.
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Andrzej J. T. <an...@ch...> - 2003-02-03 22:23:02
|
Gregg suggests: > ndeed! My personal feeling is that any project that I can't load into my > IDE, (in different projects if command line limits are an issue), and push > the build button on, is not correctly designed. Clearly, building without > an IDE is an advantage. But, I would strongly suggest that the project > really should be buildable with some simple form of > > javac -d classes `find . -name '*.java' -print` Trust me on this one....we're gonna need Ant! No point in creating a custom build system, since this would take a lot of work and would detract from the Embedlets development. We'll just package Ant (and other prereq's like Xerces, Xalan, etc.) libraries with the Outpost distribution. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-03 21:55:23
|
>Call me a wimp, but I'm not to fond of LaTeX, troff or any other document >production systems that forces me to mix content and formatting. (That's >why I use XmlmindXmlEditor with stylesheets for docbook editing) > >Mixing content and formatting tends to draw focus to the formatting, not >the content. But that's just my problem of course... Well, only the artists have this problem :-) If you have control, you will exercise it if you have a preference to adjust formatting. Latex has some really simple structuring tags, and once you go past those, everything you do is about layout adjustment. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Christopher S. <cs...@oo...> - 2003-02-03 21:42:31
|
Is this a commercial product? If so we should talk about how to proceed with obvious high priority. If it is professional interest I would release an evaluation copy to you and other group members to act as a basis for the discussion of convergence to the Embedlet standard. Christopher Smith cs...@oo... -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Jac Kersing Sent: Monday, February 03, 2003 12:22 PM To: Christopher Smith Cc: emb...@li... Subject: [Embedlets-dev] RE: [Embedlets-developer] a challenge... Topic tags:[Arch][Wiring][Doc][HW][PM] _______________________________________________ On Sun, 2 Feb 2003, Christopher Smith wrote: > The X10 interface would be a matter of wrapping any existing code in a > Component interface. Shouldn't be a problem. > Things start communicating immediately. We are preparing to present > applicable portions of OPC as a 'quick start' to the Embedlet code base > at this time. Sounds great. When can I start? :-) > I will keep you and the group updated as things progress with the > convergence effort. If you are anxious to get going with something now, > that has a good chance of conformity with Embedlets in the future, let > me know. You know of any developers not anxious to start using cool new technology??? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Jac K. <j.k...@th...> - 2003-02-03 21:34:18
|
Hi, Seeing the last few messages on the list I've got the feeling I'm missing something. What are the [Arch], [HW] tags in the subjects refering to? And the Topic tags suddenly in the new messages? Teds 'Re:[Arch] Architecture discussion document...' message seems to refer to a message/document I seem to have missed?? I'm confused, could someone please help me regain context???? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-03 21:22:14
|
Topic tags:[Arch][Wiring][Doc][HW][PM] _______________________________________________ >James raises a good point: > >> I think it is the real-time nature of Embedded programming that puts >> people in a bit of a spin. > >I've been thinking about this. Creation of a container implementation that can >support real-time (in the strict, embedded sense of the word) is a very difficult >task. >>Scheduling of multiple threads is the only place that predictable latencies >>get shot down. Realtime only requires predictable latencies to design a >>system that provides the required functionality. RTSJ is primarily about >>resolving this issue. GC is another problem that RTSJ addresses by making it >>possible to designate threads as non-garbage generating. Thus, the scheduler >>will still allow them to meet their schedules because the GC process won't >>need to lock them out of the CPU... >>So, if you design with RTSJ in mind, you should have no problems putting >>embedlets into an RTSJ compatible VM... ----- gr...@cy... (Cyte Technologies Inc) That was my thought as well. I have been sucessful integrating RT events such as the AJile GPIO interrupts within an Embedlet-like process component. A high priority thread reads an ADC into and int variable, then signals a lower priority thread that is waiting. This second thread is less sensitive to GC interruption so does not have to be as tidy. One way to address this would be to have Embedlets designated as thread-aware or unaware. The guidelines for thread aware Embedlets would be set out based on RT requirements. It seems that that the container would not have to be concerned with RT threading. Am I right?? ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Jac K. <j.k...@th...> - 2003-02-03 20:32:04
|
On Mon, 3 Feb 2003, Gregg G. Wonderly wrote: > Your favorite text editor, and LaTeX? It is really a serious document > production system, including a PDF generator. The fact that it is > simple text makes diffs work. The fact that it has elaborate page > layout control makes it good for graphics. I haven't used it in about 3 > years, but I have a javadoc doclet that generates LaTeX... Call me a wimp, but I'm not to fond of LaTeX, troff or any other document production systems that forces me to mix content and formatting. (That's why I use XmlmindXmlEditor with stylesheets for docbook editing) Mixing content and formatting tends to draw focus to the formatting, not the content. But that's just my problem of course... Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Jac K. <j.k...@th...> - 2003-02-03 20:14:32
|
On Sun, 2 Feb 2003, Christopher Smith wrote: > The X10 interface would be a matter of wrapping any existing code in a > Component interface. Shouldn't be a problem. > Things start communicating immediately. We are preparing to present > applicable portions of OPC as a 'quick start' to the Embedlet code base > at this time. Sounds great. When can I start? :-) > I will keep you and the group updated as things progress with the > convergence effort. If you are anxious to get going with something now, > that has a good chance of conformity with Embedlets in the future, let > me know. You know of any developers not anxious to start using cool new technology??? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Jac K. <j.k...@th...> - 2003-02-03 20:10:00
|
On Sun, 2 Feb 2003, Ted Kosan wrote: > Why do you say the DTDs are proprietary? I thought they were open? Is anyone (apart from OpenOffice) using them? > Also, OpenOffice outputs in PDF format out of the box. Just go to File > -> Printer Setup, select PDF as the print format and then select Print > To File when you print. This generates very nice PDF files of both text > and graphics! I seem to remember the StarOffice 6 manual refering to some commercial tool needed for PDF creation, but I'm unable to find the reference right now. Just tried it with SO and it refuses to write the output to a file. It's always using the printer, so I'm unable to verify if it's outputting PDF or PS. This is probably a problem in my setup, so I'll have to fix it. :-/ Ok, if OO is able to output PDFs and HTML we should be set, shouldn't we? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Jac K. <j.k...@th...> - 2003-02-03 20:03:08
|
On Sun, 2 Feb 2003, Nicola Ken Barozzi wrote: > In opensource? A date? ;-) It happens, sometimes. And in a few cases projects actualy meet those deadlines :-) > If it's an important point for you, I'll bump it's priority. Not at this moment. Might become one if we start using Forrest for documentation. > In the pages they can automatically render as PNG. > FOP is capable of rendering to PDF too IIRC, I can enable it. FOP does PDF and if the input is well a well defined (broken) subset of FO it even works well... > I find CVS diffs to be really better because of the way CVS works with > multiple committs, merges, etc. Have you tested OpenOffice merging? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-03 14:41:13
|
>I'm not sure we'll need anything more than just Ant (or want anything more). >JBoss is built using Ant, so it should be more than enough for us. I would >hesitate to build in any more dependencies than absolutely necessary. Indeed! My personal feeling is that any project that I can't load into my IDE, (in different projects if command line limits are an issue), and push the build button on, is not correctly designed. Clearly, building without an IDE is an advantage. But, I would strongly suggest that the project really should be buildable with some simple form of javac -d classes `find . -name '*.java' -print` ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-03 14:30:24
|
>>>Any further suggestion about editors and formats they save in? Your favorite text editor, and LaTeX? It is really a serious document production system, including a PDF generator. The fact that it is simple text makes diffs work. The fact that it has elaborate page layout control makes it good for graphics. I haven't used it in about 3 years, but I have a javadoc doclet that generates LaTeX... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-03 14:24:57
|
>James raises a good point: > >> I think it is the real-time nature of Embedded programming that puts >> people in a bit of a spin. > >I've been thinking about this. Creation of a container implementation that can >support real-time (in the strict, embedded sense of the word) is a very difficult >task. Scheduling of multiple threads is the only place that predictable latencies get shot down. Realtime only requires predictable latencies to design a system that provides the required functionality. RTSJ is primarily about resolving this issue. GC is another problem that RTSJ addresses by making it possible to designate threads as non-garbage generating. Thus, the scheduler will still allow them to meet their schedules because the GC process won't need to lock them out of the CPU... So, if you design with RTSJ in mind, you should have no problems putting embedlets into an RTSJ compatible VM... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Ted K. <tk...@ya...> - 2003-02-03 12:37:22
|
Andrzej, My initial impressions are very favorable and the system as you have laid it out is very close to what I imagined it would be like. I especially like the transport and protocol adapter ideas and your build process has nicely solved a number of problems that I was uncertain about. At this point I do not see anything obvious that would prevent the types of operations that I envisioned for the Wiring Tool and in fact your XML Embedlet configuration file seems like it would allow for much more detailed information to be presented to a graphic Embedlet assembler than what is provided by the JavaBeans Introspection mechanism. For example, Introspection exposes Properties and Event Registration methods using very terse descriptions but the availability of an XML configuration file would allow quite detailed descriptions of an Embedlet's public interface that would be very helpful to a graphic component assembler. It is interesting how this discussion document deals with the Embedlets specification and its Outpost reference implementation materials concurrently but I think this does help one envision how the whole system fits together. I am looking forward to digging into this document much further over the next couple of days. Thank you very much for putting this all together! Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-02-03 11:19:41
|
Andrzej, >From the hardware perspective, the only thing >I can think of is having a company like Systronix >provide some standardized connectors and >components so that the assembly of the sensors >and components is more akin to slotting in boards >in a PC or wiring CAT5/Serial/Parallel cables. That >would make the hardware assembly less forbidding. >I think designing and marketing such hardware is >beyond the scope of the Embedlet list/group/project >though. But if someone wants to get into the >fabrication business, it might be a viable business model. > >Any other thoughts? The thoughts I have here are that between the Embedlets project and the Cork project we seem to be in the interesting position of being able to help design a PnP hardware specification which conforms to the needs of the software instead of the other way around. I agree that we would not market the hardware but I can see us working with vendors like Systronix to help develop the open specifications that the hardware would need to adhere to. As an example of this, if a company were interested in building a PnP I/O module that was designed to work with an Embedlet container, then the specification might state that this module had to have a tagging device installed on it which would contain the fully qualified name of the JAPL peripheral that the module implemented. When the module was plugged into the system its tagging information would be read and the appropriate JAPL object would automatically be loaded which is designed to communicate with the module. Since a 1-Wire cabling and connector standard has already been defined, 1-Wire devices already have memories that can be used for tagging purposes and the 1-Wire Java API automatically senses 1-Wire devices entering and leaving the network, I thought that this technology would be a good place to start for experimenting with the PnP module idea. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-02-03 10:28:13
|
Andrzej, >> I think it is the real-time nature of Embedded programming that puts >> people in a bit of a spin. >I've been thinking about this. Creation of a container >implementation that can support real-time (in the strict, >embedded sense of the word) is a very difficult >task. My current thinking is that Embedlets won't be able >to support pure real time (with the millisecond response >times and prioritizations this requires) in it's first few >incarnations, and that this would be too ambitious a goal for us >to try and tackle out of the gate. > >Thoughts? The initial research that was done with the JAPL idea indicates that a poor man's realtime capability could be made available to the Embedlet container by adding something like a Determinism interface to the appropriate JAPL peripherals that would allow their determinism capabilities to be queried and configured. For example, a PIC based muvium device that was implementing a SquareWaveGenerator JAPL peripheral could indicate that it was capable of producing square waves with periods as short as 1 microsecond. The strategy for developing Embedlet based systems with realtime capabilities would then be to move as much of the deterministic code as possible to the implementation side of the JAPL peripherals and then implement it with whatever technology works best. As an example, if a speed controller Embedlet was developed against a JAPL SquareWaveGenerator interface, at build or run time it could query the deterministic capabilities of the specific JAPL instance that implemented the interface in order to determine if it was capable of meeting its temporal requirements. If the peripheral indicates it is capable then everything should work OK. If it is not capable then the Embedlet could either reduce the level of service it can provide or force the developer to implement the interface with a more capable piece of hardware. It is not quite RTSJ but it seems to be 'straight forward' and it might prove to be good enough for a number of uses. A side thought here is that a JAPL interface which also had temporal requirements attached to it would be an interesting way for a company developing an Embedlet based embedded system to post their JAPL peripheral needs on the net and then let third party developers compete for the contracts to implement them. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-03 07:11:41
|
Jac, We have a solution available now, OopScope Process Components, that we intend to converge with the Embedlet standards. The one wire interface has been integrated. Persistence and transport are both simple and operational with demonstration Swing, Web and handheld user interfaces. The X10 interface would be a matter of wrapping any existing code in a Component interface. Things start communicating immediately. We are preparing to present applicable portions of OPC as a 'quick start' to the Embedlet code base at this time. The demonstration of two Embedlet applications in a short period of time would be a real boon for the standard! I will keep you and the group updated as things progress with the convergence effort. If you are anxious to get going with something now, that has a good chance of conformity with Embedlets in the future, let me know. Chris Smith OopScope cs...@oo... -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Jac Kersing Sent: Sunday, February 02, 2003 3:40 PM To: emb...@li... Subject: [Embedlets-developer] a challenge... Hi, I've got a real life problem and was wondering how this would be solved using our (currently imaginary) embedlets. The situation: hardware: 6 X10 lamp switches, some X10 remotes, X10 gateway (CM11), Couple of 1-Wire devices, some PIR motion sensors, handfull of TINIs, some JStamps, one Sun Ultra10 (Solaris 9), a couple of PCs (WinXP Prof and Linux) and a SaJe board, plenty of networking cable and hubs/switches to connect everything equiped with RJ45s, a couple of J2ME phones, one iMode phone. software: all the development tools needed to create software for the listed hardware. SUN ONE Application server (platform edition) & Directory server. And everything legally available on the Internet of course... goal: - record the status of the X10 switches (according to the info provided by the CM11 [all actions with remotes are available this way]) - present the current status of the X10 devices (on at xx% of max capacity/off) to both J2ME and iMode (chtml can be used for browser as well) - detect arrival of 1-Wire ID on network (signals one of the PIR detectors detected movement) - store all state changes of X10 and 1-Wire in persistant storage for reporting etc In the (near) future a couple of 1-Wire temperature and/or humidity sensors will be added to the setup and I want to extend the software to control the X10 devices. I've got code to sample all of the sensors at this moment and monitoring infrastructure is up and running already, but a redesign is in order to add the temperature sensors and X10 control, so I'm offering to become a test site for our effords. (If you guys promise to behave I might even allow remote access to the system :-) ) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
11 messages has been excluded from this view by a project administrator.
