embedlets-developer Mailing List for Outpost Embedlet Container (Page 11)
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: Ted K. <tk...@ya...> - 2003-07-05 00:18:39
|
Kelly wrote: > But Ted... Re: "Beyond this we do not have any users using the code we > already do have which makes it difficult to move forward." Hello Kelly, nice to hear from you again! > I have not seen any "published" code. Where is it? http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/embedlets/ The 'releases' directory contains a stable version of the platform and the other CVS directories contain the work-in-progress code. So far, all of the experiemnts that I have done with the Outpost Embedlet container indicate that it is very stable and usable now if we can just figure out a good approach for attaching it to 'hardware things'. If this were a standard pure-software project we would have had an official release already but since Embedlets is a Hardware/Software hybrid project the software is not useful to anyone without it being able to control hardware. As I had indicated in an earlier post, there are still a number of hurdles to overcome before Embedlets is ready for an official release (like JAPL and the Configuration mechanism, etc.) but the core Embedlet container code base appears to be very solid. More than solid enough to pursue the Global Light Blinker and similar projects. So, what do you think about the Global Light Blinker idea? Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-07-05 00:08:40
|
Well Ted, Why didn't you SAY SO!! Well done.. It's a very good point that you don't always hit the target you are aiming for.. I am impressed that you have got so far as to have a manufacturer and working model which is driving your confidence. I must admit I am not paying as much attention as I should be. So this idea is to allow Home automation meaning people can connect to their homes webbrowser and turn lights on and off? BTW - for the dummies.. What is NAT? James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Friday, 4 July 2003 10:19 PM To: emb...@li... Subject: RE: [Embedlets-dev] Global Light Blinker Project proposal Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ James wrote: > This project does get me wondering though.. Wondering > about what happened to outpost. I don't think the graphic wiring tool > was the thing that slowed it down. I think that Outpost is alive and well but the problem is that my version of a Outpost marketing strategy has the following dependencies: 1) Graphic Wiring tool. 2) Deployment/Configuration mechanism. 3) Solid JAPL specification and implementations. 4) Standard way to connect an Outpost to a backend enterprise system. We don't have any of these pieces yet and it looks like it is going to take us a while to build them. Beyond this we do not have any users using the code we already do have which makes it difficult to move forward. > I wonder if we are going to make the effort to build something like > this that it shouldn't be more along the lines of an outpost demo that > might have a commercial impact rather than a hobbyst project. In the process of building something commercial, what happens if a great sub-commercial opportunity is discovered that directly helps build towards commercial-quality code? The funny thing about Java is that it is a very inaccurate (albeit powerful) 'weapon'. Sun initially aimed Java at the Embedded Market and it endedded up hitting the Enterprise market. Here we initially aimed Java at the Enterprise Market (with Enterprise Outpost) and I think there is a very good chance that we are going to end up hitting the Home Embedded market. If we go back to the main reason that the Outpost idea was conceived in the first place, it was to find a large market for Embedded Java. This overall goal supersedes all lesser goals. The Embedlets/Outpost project was designed to be a vehicle to use to help with this discovery. From my perspective the project is meeting its purpose excellently because I know that I have a much better understanding of Embedded Java dynamics than I did when we started this journey back in October. I now think that I have a fairly good grasp of what a good Embedded Java opportunity looks like and what the Embedded Java pitfalls look like. We have all put a heck of a lot of work into Embedlets/Embedded Java over the past year and now I think it is time for some of that effort to pay off. In my opinion, the Global Light Blinker (GLB) project opens the door to the greatest Embedded Java opportunity to come along since the concept of Embedded Java was first developed and the Embedded Java community is currently the only group on the planet which is in a position to pursue it. Here are my reasons for thinking this: 1) The GLB project shows a large number of people what Embedded Java is capable of without having to explain anything to them (the project's visibility potential is enormous!). As soon as they see their lamps turning on and off remotely through the internet they will instantly 'get it'. 2) As soon as people's 'lights go on', how long do you think it is going to take for them to come up with dozens of ideas for things to control inside of the their homes that they can actually use? How many of these people are business people that will instantly see how they can sell devices like this to other people? 3) At this moment in time, the main opportunity for building these devices, and showing others how to build them, is being offered to the Embedded Java Community (as defined by http://embedlets.org/images/flounder.jpg). The Embedded Java developers represent the primary Community in the world that has the correct mix of Hardware/Software skills needed to build these devices. 4) The great thing for us is that the 'remote control of in-home devices' opportunity is in its very early stages because NAT has been an effective roadblock which has prevented it from materializing. JXTA 2.0 smashed this roadblock a few months ago and now, very suddenly, the Embedded Java Community has *secure* access into the home. To get started, we don't need commercial-quality hardware or a finished and commercial-quality Embedlets implementation. As incomplete as it is, the Embedlets implementation that we currently have is more than ready for starting to pursue this opportunity. To summarize, the Enterprise Outpost idea is a great idea, and we are slowly getting there. In the process of building the Enterprise Outpost the Home Device Outpost was discovered, and it has a large market that we can pursue right now. > The other thing we need to be careful of is not to dilute our efforts > to such an extent that progress stalls. I would say that progress on Embedlets is about to make a great leap forward. When viewed from the right perspective, a number of seemingly disconnected efforts can be seen to actually be part of a well-coordinated effort. Some people's style when building a system is to work sequentially and to completely finish the current component before moving on to the next step. A style that contrasts this is to work on all of the components in parallel so that the quality of the interfaces between the components can be maximized and also so that the system can be better tuned to fit its overall purpose. I am definitely a parallel-development-style person so perhaps this knowledge might ease your concerns a bit. Anyway, for the past couple of weeks I have been working 'like a dog' to get my mind around JXTA 2.0 with the goal of remotely blinking a house lamp which is sitting behind NAT in someone's home. I am so close now that I can 'almost taste it' and with any luck the first LightBlinker should go live sometime this weekend. I have also already found a company that is willing to make the beta hardware and I even convinced them to hire our University students to do the assembly. The hardware specification is going to be open so that anyone can implement them but it is my guess that most people would rather just buy a reasonably priced pre-assembled box. But actually, the LightBlinker project is just a proof of concept, the real opportunity is in meeting the demand for all of the other things that people want to monitor and control in their homes. So, is anyone here interested in this idea enough to discuss it further? Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Kelly S. <be...@ea...> - 2003-07-04 22:54:47
|
But Ted... Re: "Beyond this we do not have any users using the code we already do have which makes it difficult to move forward." I have not seen any "published" code. Where is it? Best regards, Kelly Smith (1-Wire/Java/TINI class advocate... your class that is!) Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Friday, July 04, 2003 1:19 PM To: emb...@li... Subject: RE: [Embedlets-dev] Global Light Blinker Project proposal Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ James wrote: > This project does get me wondering though.. Wondering > about what happened to outpost. I don't think the graphic wiring tool > was the thing that slowed it down. I think that Outpost is alive and well but the problem is that my version of a Outpost marketing strategy has the following dependencies: 1) Graphic Wiring tool. 2) Deployment/Configuration mechanism. 3) Solid JAPL specification and implementations. 4) Standard way to connect an Outpost to a backend enterprise system. We don't have any of these pieces yet and it looks like it is going to take us a while to build them. Beyond this we do not have any users using the code we already do have which makes it difficult to move forward. > I wonder if we are going to make the effort to build something like this > that it shouldn't be more along the lines of an outpost demo that might > have a commercial impact rather than a hobbyst project. In the process of building something commercial, what happens if a great sub-commercial opportunity is discovered that directly helps build towards commercial-quality code? The funny thing about Java is that it is a very inaccurate (albeit powerful) 'weapon'. Sun initially aimed Java at the Embedded Market and it endedded up hitting the Enterprise market. Here we initially aimed Java at the Enterprise Market (with Enterprise Outpost) and I think there is a very good chance that we are going to end up hitting the Home Embedded market. If we go back to the main reason that the Outpost idea was conceived in the first place, it was to find a large market for Embedded Java. This overall goal supersedes all lesser goals. The Embedlets/Outpost project was designed to be a vehicle to use to help with this discovery. From my perspective the project is meeting its purpose excellently because I know that I have a much better understanding of Embedded Java dynamics than I did when we started this journey back in October. I now think that I have a fairly good grasp of what a good Embedded Java opportunity looks like and what the Embedded Java pitfalls look like. We have all put a heck of a lot of work into Embedlets/Embedded Java over the past year and now I think it is time for some of that effort to pay off. In my opinion, the Global Light Blinker (GLB) project opens the door to the greatest Embedded Java opportunity to come along since the concept of Embedded Java was first developed and the Embedded Java community is currently the only group on the planet which is in a position to pursue it. Here are my reasons for thinking this: 1) The GLB project shows a large number of people what Embedded Java is capable of without having to explain anything to them (the project's visibility potential is enormous!). As soon as they see their lamps turning on and off remotely through the internet they will instantly 'get it'. 2) As soon as people's 'lights go on', how long do you think it is going to take for them to come up with dozens of ideas for things to control inside of the their homes that they can actually use? How many of these people are business people that will instantly see how they can sell devices like this to other people? 3) At this moment in time, the main opportunity for building these devices, and showing others how to build them, is being offered to the Embedded Java Community (as defined by http://embedlets.org/images/flounder.jpg). The Embedded Java developers represent the primary Community in the world that has the correct mix of Hardware/Software skills needed to build these devices. 4) The great thing for us is that the 'remote control of in-home devices' opportunity is in its very early stages because NAT has been an effective roadblock which has prevented it from materializing. JXTA 2.0 smashed this roadblock a few months ago and now, very suddenly, the Embedded Java Community has *secure* access into the home. To get started, we don't need commercial-quality hardware or a finished and commercial-quality Embedlets implementation. As incomplete as it is, the Embedlets implementation that we currently have is more than ready for starting to pursue this opportunity. To summarize, the Enterprise Outpost idea is a great idea, and we are slowly getting there. In the process of building the Enterprise Outpost the Home Device Outpost was discovered, and it has a large market that we can pursue right now. > The other thing we need to be careful of is not to dilute our efforts to > such an extent that progress stalls. I would say that progress on Embedlets is about to make a great leap forward. When viewed from the right perspective, a number of seemingly disconnected efforts can be seen to actually be part of a well-coordinated effort. Some people's style when building a system is to work sequentially and to completely finish the current component before moving on to the next step. A style that contrasts this is to work on all of the components in parallel so that the quality of the interfaces between the components can be maximized and also so that the system can be better tuned to fit its overall purpose. I am definitely a parallel-development-style person so perhaps this knowledge might ease your concerns a bit. Anyway, for the past couple of weeks I have been working 'like a dog' to get my mind around JXTA 2.0 with the goal of remotely blinking a house lamp which is sitting behind NAT in someone's home. I am so close now that I can 'almost taste it' and with any luck the first LightBlinker should go live sometime this weekend. I have also already found a company that is willing to make the beta hardware and I even convinced them to hire our University students to do the assembly. The hardware specification is going to be open so that anyone can implement them but it is my guess that most people would rather just buy a reasonably priced pre-assembled box. But actually, the LightBlinker project is just a proof of concept, the real opportunity is in meeting the demand for all of the other things that people want to monitor and control in their homes. So, is anyone here interested in this idea enough to discuss it further? Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-07-04 20:18:45
|
James wrote: > This project does get me wondering though.. Wondering > about what happened to outpost. I don't think the graphic wiring tool > was the thing that slowed it down. I think that Outpost is alive and well but the problem is that my version of a Outpost marketing strategy has the following dependencies: 1) Graphic Wiring tool. 2) Deployment/Configuration mechanism. 3) Solid JAPL specification and implementations. 4) Standard way to connect an Outpost to a backend enterprise system. We don't have any of these pieces yet and it looks like it is going to take us a while to build them. Beyond this we do not have any users using the code we already do have which makes it difficult to move forward. > I wonder if we are going to make the effort to build something like this > that it shouldn't be more along the lines of an outpost demo that might > have a commercial impact rather than a hobbyst project. In the process of building something commercial, what happens if a great sub-commercial opportunity is discovered that directly helps build towards commercial-quality code? The funny thing about Java is that it is a very inaccurate (albeit powerful) 'weapon'. Sun initially aimed Java at the Embedded Market and it endedded up hitting the Enterprise market. Here we initially aimed Java at the Enterprise Market (with Enterprise Outpost) and I think there is a very good chance that we are going to end up hitting the Home Embedded market. If we go back to the main reason that the Outpost idea was conceived in the first place, it was to find a large market for Embedded Java. This overall goal supersedes all lesser goals. The Embedlets/Outpost project was designed to be a vehicle to use to help with this discovery. From my perspective the project is meeting its purpose excellently because I know that I have a much better understanding of Embedded Java dynamics than I did when we started this journey back in October. I now think that I have a fairly good grasp of what a good Embedded Java opportunity looks like and what the Embedded Java pitfalls look like. We have all put a heck of a lot of work into Embedlets/Embedded Java over the past year and now I think it is time for some of that effort to pay off. In my opinion, the Global Light Blinker (GLB) project opens the door to the greatest Embedded Java opportunity to come along since the concept of Embedded Java was first developed and the Embedded Java community is currently the only group on the planet which is in a position to pursue it. Here are my reasons for thinking this: 1) The GLB project shows a large number of people what Embedded Java is capable of without having to explain anything to them (the project's visibility potential is enormous!). As soon as they see their lamps turning on and off remotely through the internet they will instantly 'get it'. 2) As soon as people's 'lights go on', how long do you think it is going to take for them to come up with dozens of ideas for things to control inside of the their homes that they can actually use? How many of these people are business people that will instantly see how they can sell devices like this to other people? 3) At this moment in time, the main opportunity for building these devices, and showing others how to build them, is being offered to the Embedded Java Community (as defined by http://embedlets.org/images/flounder.jpg). The Embedded Java developers represent the primary Community in the world that has the correct mix of Hardware/Software skills needed to build these devices. 4) The great thing for us is that the 'remote control of in-home devices' opportunity is in its very early stages because NAT has been an effective roadblock which has prevented it from materializing. JXTA 2.0 smashed this roadblock a few months ago and now, very suddenly, the Embedded Java Community has *secure* access into the home. To get started, we don't need commercial-quality hardware or a finished and commercial-quality Embedlets implementation. As incomplete as it is, the Embedlets implementation that we currently have is more than ready for starting to pursue this opportunity. To summarize, the Enterprise Outpost idea is a great idea, and we are slowly getting there. In the process of building the Enterprise Outpost the Home Device Outpost was discovered, and it has a large market that we can pursue right now. > The other thing we need to be careful of is not to dilute our efforts to > such an extent that progress stalls. I would say that progress on Embedlets is about to make a great leap forward. When viewed from the right perspective, a number of seemingly disconnected efforts can be seen to actually be part of a well-coordinated effort. Some people's style when building a system is to work sequentially and to completely finish the current component before moving on to the next step. A style that contrasts this is to work on all of the components in parallel so that the quality of the interfaces between the components can be maximized and also so that the system can be better tuned to fit its overall purpose. I am definitely a parallel-development-style person so perhaps this knowledge might ease your concerns a bit. Anyway, for the past couple of weeks I have been working 'like a dog' to get my mind around JXTA 2.0 with the goal of remotely blinking a house lamp which is sitting behind NAT in someone's home. I am so close now that I can 'almost taste it' and with any luck the first LightBlinker should go live sometime this weekend. I have also already found a company that is willing to make the beta hardware and I even convinced them to hire our University students to do the assembly. The hardware specification is going to be open so that anyone can implement them but it is my guess that most people would rather just buy a reasonably priced pre-assembled box. But actually, the LightBlinker project is just a proof of concept, the real opportunity is in meeting the demand for all of the other things that people want to monitor and control in their homes. So, is anyone here interested in this idea enough to discuss it further? Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-07-04 13:50:12
|
>Ted Kosan wrote, On 02/07/2003 23.34: > >> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >> _______________________________________________ >> >> Hey Andrzej, >> >> what do you think about this PicoContainer? >> >> http://www.picocontainer.org Nicco Responded >It's still in a very early stage, I'd personally advise to not endorse >it still. On the other hand, it's important that patterns seen there are >also taken into account as possibilities. > >BTW, the "type1,2,3" IOC is totally made up, they invented that strange >definition ;-) This work seems to be a close proximity to the notions of the Configuration class in the Jini2.0 distribution. In the ConfigurationFile implementation, they have provided a Java expression parser so that you can initialize and lace together a deployment with code. my.package.object1 { file = "myfile.ser"; exporter = new JrmpExporter(); } my.package.object2 { cnt = new Integer(42); exporter = new MyJeriExporter(); } The expressions are all evaluated using introspection. The result is that as a developer, you are completely free of all these myriad of decisions about deployment strategies related to protocols, ports, addresses etc. The deployer gets to decide that stuff, and can reconfigure at will. The result is extreme flexibility that is very powerful! ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Nicola K. B. <nic...@ap...> - 2003-07-04 09:50:32
|
Ted Kosan wrote, On 02/07/2003 23.34: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Hey Andrzej, > > what do you think about this PicoContainer? > > http://www.picocontainer.org It's co-written by a longtime Avalon committer, Paul Hammant, and other clever folks. It's still in a very early stage, I'd personally advise to not endorse it still. On the other hand, it's important that patterns seen there are also taken into account as possibilities. BTW, the "type1,2,3" IOC is totally made up, they invented that strange definition ;-) > It appears that containers are popping up all over the place... It took years for avalon to start being understood, after all the flames it got... *sigh* -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: James C. <ca...@vi...> - 2003-07-04 07:17:28
|
Hi Ted, As always lots of good ideas's here. I suppose I should dust up my jxta skills soon also. This project does get me wondering though.. Wondering about what happened to outpost. I don't think the graphic wiring tool was the thing that slowed it down. I wonder if we are going to make the effort to build something like this that it shouldn't be more along the lines of an outpost demo that might have a commercial impact rather than a hobbyst project. The other thing we need to be careful of is not to dilute our efforts to such an extent that progress stalls. James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Tuesday, 1 July 2003 8:11 AM To: emb...@li... Subject: [Embedlets-dev] Global Light Blinker Project proposal Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ Embedlets Group, It has been 9 month since we started the Embedlets project and in my opinion it is time to start letting the world know about our existence. I originally thought that the Enterprise Outpost would be the way that Embedlets would first be introduced to the world but that plan's dependency on a graphic wiring tool has slowed it down just a bit. But the Embedlet Container works now! Even though we still need to work through a number of issues before Embedlets is ready for commercial use, like JAPL, I think we have a solid enough of an implementation to start pursuing noncommercial quality beta projects. And I think I accidentally stumbled upon a killer 'coming out' project for Embedlets! I call it the Global Light Blinker project and the idea was conceived on the newcim list that I am a member of: http://groups.yahoo.com/group/newcim/ These guys want to build an experimental globally distributed CNC light blinker system and so I have been researching how to do this for the past 2 weeks. At JavaOne, Bruce Boyes had convinced me to seriously start looking into JXTA and, as it turns out, a JXTA/Embedlet container combination appears to be a killer technology! Here is a diagram of the light blinker hardware that will be needed for this project: http://tkosan.javadevices.org/misc/embeddedjava/light_blinker_diagram.jp g Here is where things get very interesting. I have spent a large amount of time during the past couple of weeks looking through the jxta.org site and reading the jxta documentation and guess what? None of the current or proposed JXTA projects have any computer interfacing component to them at all. The JXTA group talks a lot about using JXTA to monitor sensors and control actuators but evidently almost none of them have the expertise needed to deal with embedded hardware. But they seem to really want to... IMHO, this would be a wonderful opportunity for the Embedlets Group to propose a partnership with the JXTA group. We would provide them with the Embedded Systems expertise that they need and they would provide us with the peer-to-peer expertise and project ideas that have Embedded Systems components that we need. This is something we can start pursuing now without needing the Embedlet Container to be 100% commercially ready yet. Here is a proposal for how to proceed with this: 1) Hammer out a feasible hardware design that is similar to the light blinker diagram given above. 2) Find a company that is willing to build and sell the physical Light Blinker kits (Serial-to-1-Wire converter and Light Blinker box). 3) Develop a Global Light Blinker joint JXTA/Embedlets project proposal that we can submit to the JXTA group. (I will volunteer to do this). What do people think? In the mean time, the newcim group is very excited about blinking lights across the globe and I am in the process of writing a distributed JXTA/Embedlets application and assembling some test hardware to do this. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-07-02 21:51:01
|
Hey Andrzej, what do you think about this PicoContainer? http://www.picocontainer.org It appears that containers are popping up all over the place... Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-07-01 06:11:04
|
Embedlets Group, It has been 9 month since we started the Embedlets project and in my opinion it is time to start letting the world know about our existence. I originally thought that the Enterprise Outpost would be the way that Embedlets would first be introduced to the world but that plan's dependency on a graphic wiring tool has slowed it down just a bit. But the Embedlet Container works now! Even though we still need to work through a number of issues before Embedlets is ready for commercial use, like JAPL, I think we have a solid enough of an implementation to start pursuing noncommercial quality beta projects. And I think I accidentally stumbled upon a killer 'coming out' project for Embedlets! I call it the Global Light Blinker project and the idea was conceived on the newcim list that I am a member of: http://groups.yahoo.com/group/newcim/ These guys want to build an experimental globally distributed CNC light blinker system and so I have been researching how to do this for the past 2 weeks. At JavaOne, Bruce Boyes had convinced me to seriously start looking into JXTA and, as it turns out, a JXTA/Embedlet container combination appears to be a killer technology! Here is a diagram of the light blinker hardware that will be needed for this project: http://tkosan.javadevices.org/misc/embeddedjava/light_blinker_diagram.jpg Here is where things get very interesting. I have spent a large amount of time during the past couple of weeks looking through the jxta.org site and reading the jxta documentation and guess what? None of the current or proposed JXTA projects have any computer interfacing component to them at all. The JXTA group talks a lot about using JXTA to monitor sensors and control actuators but evidently almost none of them have the expertise needed to deal with embedded hardware. But they seem to really want to... IMHO, this would be a wonderful opportunity for the Embedlets Group to propose a partnership with the JXTA group. We would provide them with the Embedded Systems expertise that they need and they would provide us with the peer-to-peer expertise and project ideas that have Embedded Systems components that we need. This is something we can start pursuing now without needing the Embedlet Container to be 100% commercially ready yet. Here is a proposal for how to proceed with this: 1) Hammer out a feasible hardware design that is similar to the light blinker diagram given above. 2) Find a company that is willing to build and sell the physical Light Blinker kits (Serial-to-1-Wire converter and Light Blinker box). 3) Develop a Global Light Blinker joint JXTA/Embedlets project proposal that we can submit to the JXTA group. (I will volunteer to do this). What do people think? In the mean time, the newcim group is very excited about blinking lights across the globe and I am in the process of writing a distributed JXTA/Embedlets application and assembling some test hardware to do this. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-06-30 01:58:09
|
Ted, One point to be aware of is that the most generic solution is also almost always the hardest to implement. If there are some really good 80/20 wins in there for getting most of way to the ideal for the first round then we should probably consider them to get the project off its feet. Some of the concepts you talk about with dynamically generation automagical wired self described widgets that make swiss army knives look streamline may prove outside the scope of first pass achieveability.. Just a thought. James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Monday, 30 June 2003 1:32 AM To: emb...@li... Subject: [Embedlets-dev] JSIMM Minivan (was peer-to-peer) Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ JSIMM MINIVAN I would like to elaborate on the design goal that I am shooting for with trying to bring 'peer-to-peer' to the JSIMM backplane. What I want is maximum flexibility during the system assembly and configuration stage, not during the operating stage, and I am more than willing to trade speed that I don't need in order to achieve this. What I want to do is to treat the JSIMM backplane like a minivan. The early Chrysler minivan advertisements focused on how many user-achievable configuration options their minivans offered. They would show something like 50 top views of their van with 50 different seat/accessory combinations and then say that in total, 250+ combinations were possible. Minivans are all about solving as many hauling problems as possible as cheaply as possible and for the most part speed, beyond a certain minimum, is not even a consideration. For the market that I am targeting the user is an 'embedded application configurator' just like the minivan owner is a 'minivan application configurator'. I want an embedded application configurator to be able to belly-up to a workbench that has a bunch of JSIMM backplanes, TStiks, muviums, JStamps and JStiks sitting on it, along with a workstation running the Embedlet wiring tool, and just snap together a solution to an embedded problem that they have. A point I want to emphasize here is that the flexibility is only needed during configuration time. For example, after the minivan has been configured to solve the current problem (like take 6 kids to baseball practice) it is frozen in that configuration until the next problem needs to be solved. For the typical family this configuration might change on a daily basis and for a commercial application (like a delivery van) one configuration might last the whole life of the vehicle. The type of embedded JSIMM-based applications I am thinking about need configuration-time flexibility, not runtime configuration flexibility (like a typical peer-to-peer internet application would need). IMHO, the killer market for Embedded Java is the flexible, configurable embedded systems market. EMBEDDED JAVA BASED PEER-TO-PEER A network-based computer is a computer that is made up of networked computing nodes and Java is an operating system for a network-based computer. A Java based application really shines when it has the flexibility to appropriately distribute parts of itself across the network nodes that it is spanning and I want to use a JSIMM backplane to allow the application assembly and configuration software to dynamically place the appropriate Java objects on the appropriate nodes in order to achieve the most efficient solution to the current embedded problem that is being solved. For example, assuming a CNC Mill controller problem, the application assembly software might decide that using a TStik (for the CNC's logic, network connectivity and persistent storage needs), and 2 muvium based JSIMM cards (for its realtime needs), is an efficient solution. If at a later date a robot is added to this system and the robot has realtime PID requirements, then perhaps a JStamp is plugged into the JSIMM backplane and the application assembly software can re-distribute the objects across the nodes to achieve an efficient solution to the new problem. So again, what I am shooting for is maximum flexibility at application configuration time and for this goal, a slower flexible network beats a faster inflexible one. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-06-29 23:31:36
|
JSIMM MINIVAN I would like to elaborate on the design goal that I am shooting for with trying to bring 'peer-to-peer' to the JSIMM backplane. What I want is maximum flexibility during the system assembly and configuration stage, not during the operating stage, and I am more than willing to trade speed that I don't need in order to achieve this. What I want to do is to treat the JSIMM backplane like a minivan. The early Chrysler minivan advertisements focused on how many user-achievable configuration options their minivans offered. They would show something like 50 top views of their van with 50 different seat/accessory combinations and then say that in total, 250+ combinations were possible. Minivans are all about solving as many hauling problems as possible as cheaply as possible and for the most part speed, beyond a certain minimum, is not even a consideration. For the market that I am targeting the user is an 'embedded application configurator' just like the minivan owner is a 'minivan application configurator'. I want an embedded application configurator to be able to belly-up to a workbench that has a bunch of JSIMM backplanes, TStiks, muviums, JStamps and JStiks sitting on it, along with a workstation running the Embedlet wiring tool, and just snap together a solution to an embedded problem that they have. A point I want to emphasize here is that the flexibility is only needed during configuration time. For example, after the minivan has been configured to solve the current problem (like take 6 kids to baseball practice) it is frozen in that configuration until the next problem needs to be solved. For the typical family this configuration might change on a daily basis and for a commercial application (like a delivery van) one configuration might last the whole life of the vehicle. The type of embedded JSIMM-based applications I am thinking about need configuration-time flexibility, not runtime configuration flexibility (like a typical peer-to-peer internet application would need). IMHO, the killer market for Embedded Java is the flexible, configurable embedded systems market. EMBEDDED JAVA BASED PEER-TO-PEER A network-based computer is a computer that is made up of networked computing nodes and Java is an operating system for a network-based computer. A Java based application really shines when it has the flexibility to appropriately distribute parts of itself across the network nodes that it is spanning and I want to use a JSIMM backplane to allow the application assembly and configuration software to dynamically place the appropriate Java objects on the appropriate nodes in order to achieve the most efficient solution to the current embedded problem that is being solved. For example, assuming a CNC Mill controller problem, the application assembly software might decide that using a TStik (for the CNC's logic, network connectivity and persistent storage needs), and 2 muvium based JSIMM cards (for its realtime needs), is an efficient solution. If at a later date a robot is added to this system and the robot has realtime PID requirements, then perhaps a JStamp is plugged into the JSIMM backplane and the application assembly software can re-distribute the objects across the nodes to achieve an efficient solution to the new problem. So again, what I am shooting for is maximum flexibility at application configuration time and for this goal, a slower flexible network beats a faster inflexible one. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-06-29 14:29:20
|
>...only if there is a reliable master, if I understand your idea. In a true >peer-to-peer ad-hoc (I realize I added that just now) network you can't >count on any node being present at any time. In fact, in any realtime >control network I think that is a good assumption. Whatever nodes happen to >be present carry on as best they can, rather than the whole network just >crashing. > >So if a master is required to facilitate all communication amongst slaves >there can be no true peers. Only the master and slave(s), and the network >should not be called a peer network. I won't disagree with the issue of depending on another party. My only comment is that paranoia about dependencies can be a killer for new ideas. Clearly, on the internet, there is no such thing as peer-to-peer because there is wiring and routers (which are the SPI master of this network technology) in between. However, we are getting more and more comfortable with considering the routers and switches and hubs as part of the wire substrate which is always available. IP provides rerouting on failure, independent of efforts of the sender and receiver, which creates a certain magical repair capability. In the world of hardware, there are duplicate busses and other hardware components that you will find in telephony equipment and other high availability environments (such as the space shuttle). So, we have learned ways to deal with certain types of failures in hardware that we may be unable to repair immediately. That is a true enabeling technology. So, if SPI is cheap, and trivial to use compared to I2C, CAN or something else, you might consider the master/slave issue less important. particularly if the master is an important part of the system that defines the system behavior, and without it, there is no reason for the other parts to function. In Teds example CNC application, it sounds to me like the embedlette container is an integral part of the system because it will be dispatching the work orders to the head controllers. So, if it dies, there is no point in going on with 'other work'. In a CNC shop, SPI between embedlette containers would cause the whole shop to stop if the master failed. In a CNC shop's computer network, such an SPI master would be the fileserver that is typically the place where all the programs are stored. My brother is a CNC machinest, so I am very familiar with this issue. He has a backup file server, tape backups to recover from, uses ghost to image the machine etc. This is a reasonable relationship at this level of the network. But, higher cost technologies don't fair well at the bottom of a control heirarchy. My experience has been that The flexibility of any CSMA network technology will create lots of issues to program around and deal with using heuristics which are expensive in code space and create an unnatural secondary control layer around otherwise simple, concise control layers. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: James C. <ca...@vi...> - 2003-06-29 06:26:03
|
Hi All, I2C of course offers peer-to-peer in with multi-master modes and collision detection. It is the natural contender for a true peer-to-peer protocol as it is already an industry standard. I have no problem with Teds idea of using I2C for peer-to-peer when it is absolutely a must. It is also a fast protocol, as fast as SPI, has a specification for collision detection with hardware support for this.=20 I see two things emerging here UART/SLIP for medium performance Master/Slave Client/Server polling applications which will cover about 80% of the application space. It has the huge advantage as Ted noticed of being able to plug into the PC making it easy to test application etc. I2C/SLIP for high performance peer-to-peer networking Client/Server/UDP which allows applications to also have nodes generate asynchronous events. This is of course only the lowest layers of the Networking Stack so toplevel interfaces can be na=EFve about what's going on down below. James Caska www.muvium.com uVM - =91Java Bred for Embedded=92 -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Bruce Boyes Sent: Friday, 27 June 2003 10:31 PM To: emb...@li... Subject: [Embedlets-dev] Peer-to-peer or master/slave Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ At 01:01 PM 6/27/2003 -0700,=20 emb...@li... wrote: >It is just an idea, but it will work just fine. It will provide a=20 >network exactly like you would see with a TCP/IP switched network, in=20 >terms of topology. Broadcast networks are fine for one or two users,=20 >but degrade quickly... There's plenty of experience that says about=20 >20% utilization is all that you can count on before you get a dramatic=20 >degradation for each percentage above that. > >Clearly there is research going on that has shown some ways to make the >degradation less dramatic (search google for 'CSMA degradation'). =20 >LonWorks has a proprietary solution as do others specific to their use. >The easies and simplest is the round-robin, equal time, equal access=20 >mechanism that I described. It will provide dependable, predictable=20 >data transfer from one peer to another. ...only if there is a reliable master, if I understand your idea. In a true=20 peer-to-peer ad-hoc (I realize I added that just now) network you can't=20 count on any node being present at any time. In fact, in any realtime=20 control network I think that is a good assumption. Whatever nodes happen to=20 be present carry on as best they can, rather than the whole network just crashing. So if a master is required to facilitate all communication amongst slaves=20 there can be no true peers. Only the master and slave(s), and the network=20 should not be called a peer network. Bruce=20 ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Christopher S. <cs...@oo...> - 2003-06-28 04:15:28
|
All good suggestions - I will make the changes. Chris > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris wrote: > > > > > I would like to submit the following for your review: > > org > > |_japl > > |_ JaplListener.java > > |_ JaplEvent.java > > |_ network > > |_ MediaController.java > > |_ MediaEvent.java > > |_ MediaListener.java > > > > Hey, good start! A few of thoughts though... > > 1) I just looked through the standard library APIs that come with J2SE and > classes like SAXException, UIDefaults, URLDecoder, etc. and all keep the > letters of their acronyms in uppercase. If we follow this > convention (which I > would vote for) then JaplListener would be JAPLEvent, etc. > > 2) How about shortening 'network' to just 'net' and then putting > all of the > MediaController related classes inside a subpackage called > 'mediacontroller'? > For example: org.japl.net.mediacontroller.MediaController, > org.japl.net.mediacontroller.MediaEvent, > org.japl.net.mediacontroller.MediaListener. This way other > people can place > network related JAPL interfaces inside the 'net' package and they > won't all get > mixed up with other JAPL interface classes. > > 3) Should JAPLListener and JAPLEvent be placed inside of an > 'event' subpackage > or a 'util' subpackage similar to what is done in the standard > library APIs? > > > Ted > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Ted K. <tk...@ya...> - 2003-06-28 03:59:26
|
Chris wrote: > > I would like to submit the following for your review: > org > |_japl > |_ JaplListener.java > |_ JaplEvent.java > |_ network > |_ MediaController.java > |_ MediaEvent.java > |_ MediaListener.java > Hey, good start! A few of thoughts though... 1) I just looked through the standard library APIs that come with J2SE and classes like SAXException, UIDefaults, URLDecoder, etc. and all keep the letters of their acronyms in uppercase. If we follow this convention (which I would vote for) then JaplListener would be JAPLEvent, etc. 2) How about shortening 'network' to just 'net' and then putting all of the MediaController related classes inside a subpackage called 'mediacontroller'? For example: org.japl.net.mediacontroller.MediaController, org.japl.net.mediacontroller.MediaEvent, org.japl.net.mediacontroller.MediaListener. This way other people can place network related JAPL interfaces inside the 'net' package and they won't all get mixed up with other JAPL interface classes. 3) Should JAPLListener and JAPLEvent be placed inside of an 'event' subpackage or a 'util' subpackage similar to what is done in the standard library APIs? Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Christopher S. <cs...@oo...> - 2003-06-28 02:20:18
|
Ok,
I would like to submit the following for your review:
org
|_japl
|_ JaplListener.java
|_ JaplEvent.java
|_ network
|_ MediaController.java
|_ MediaEvent.java
|_ MediaListener.java
No time like today to kick things off!
I am converting the socket based client/server classes for OPC to
embedlet/japl or more precisly outpost/cork, and as a minimum need these
interfaces and classes. When this is converted we should be able to see a
GUI interacting with the reference container.
Thanks
Chris
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Chris wrote:
>
> > I am trying to update japl and do not seem to get anything
> either through
> > cvs or the build.xml - all/cork etc. Any ideas?
>
> Hmmmm, when you say "update", there is nothing to update yet
> because I don't
> think that any JAPL code has been submitted yet. Up to this point we have
> mostly been trying to get our minds around exactly what JAPL was.
>
> We do own the japl.org domain name so any code you submit can be
> placed inside
> of this package. At some point we will need to come up with a reasonable
> subpackages to place under org.japl but up to now we have not
> addressed this
> yet.
>
>
> Ted
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
|
|
From: Ted K. <tk...@ya...> - 2003-06-27 22:58:26
|
Chris wrote: > I am trying to update japl and do not seem to get anything either through > cvs or the build.xml - all/cork etc. Any ideas? Hmmmm, when you say "update", there is nothing to update yet because I don't think that any JAPL code has been submitted yet. Up to this point we have mostly been trying to get our minds around exactly what JAPL was. We do own the japl.org domain name so any code you submit can be placed inside of this package. At some point we will need to come up with a reasonable subpackages to place under org.japl but up to now we have not addressed this yet. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Ted K. <tk...@ya...> - 2003-06-27 22:52:54
|
Chris wrote: > Where you divide things up from there is not as important. It would, I > think, be OK for one JAPL to use another but what you give up is the > flexibility to plug and play, dynamically configure and 'soft-wire' that is > supported by Embedlets. [...] > That being said, there is nothing to prevent one from publishing a complex > control component under JAPL, then providing an Embedlet wrapper to drop it > into an Embedlet container. Ok, I can see this now. I had not really thought about placing a JAPL interface inside of another JAPL interface but I guess being able to use JAPL interfaces anywhere (not just in Embedlets) was the reason we broke JAPL out as a separate entity in the first place. As for publishing a complex control component under JAPL, in my initial vision for JAPL I had imagined them being very similar to JINI Proxy objects where the whole (sometimes very complex) service the client is using is abstracted behind an interface. >If you want me to put the MediaController together, I will do that as well. Yes, this sounds great! I was wondering how I was going to implement the JAPLServoController interface I had in mind but being able to use a JAPLMediaController to do this is going to make this task much easier. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
|
From: Bruce B. <bb...@sy...> - 2003-06-27 21:12:49
|
At 01:01 PM 6/27/2003 -0700, emb...@li... wrote: >It is just an idea, but it will work just fine. It will provide a network >exactly like you would see with a TCP/IP switched network, in terms of >topology. Broadcast networks are fine for one or two users, but degrade >quickly... There's plenty of experience that says about 20% utilization is >all that you can count on before you get a dramatic degradation for each >percentage above that. > >Clearly there is research going on that has shown some ways to make the >degradation less dramatic (search google for 'CSMA degradation'). LonWorks >has a proprietary solution as do others specific to their use. The easies >and >simplest is the round-robin, equal time, equal access mechanism that I >described. It will provide dependable, predictable data transfer from one >peer to another. ...only if there is a reliable master, if I understand your idea. In a true peer-to-peer ad-hoc (I realize I added that just now) network you can't count on any node being present at any time. In fact, in any realtime control network I think that is a good assumption. Whatever nodes happen to be present carry on as best they can, rather than the whole network just crashing. So if a master is required to facilitate all communication amongst slaves there can be no true peers. Only the master and slave(s), and the network should not be called a peer network. Bruce |
|
From: Gregg G. W. <gr...@sk...> - 2003-06-27 20:00:10
|
>I'm lost. Peer to peer either is or isn't. If there is one master then it >isn't peer to peer since there's no peer-to-peer communication ever, only >master-to-peer. I realize I'm stating the obvious but... Which is no diffent that a modern TCP/IP switch. It has been proven and is well recognized that broadcast networks, such as ethernet are not effective for realtime comms. Collisions in CSMA networks just kill dependable performance. >If I grasp your idea (and I'm not sure I do) the master visits all the >intelligent slaves, gets data packets from them, then redistributes any >such packets which are intended to be sent from one slave to another. So >the master is a "mailman". The master has to handle every packet twice, >which could be done but will become a bottleneck at some point. There's no >guarantee that a timely message will get through unless the overall loading >is light and the polling is frequent. > >This could work, I suppose, but how does one node know another exists, and >what services it can provide or consume? What I describe is a wire level mechanism (layer 1 and 2 of the ISO seven layers) which allows a master/slave network to provide peer to peer communications. At layers above this simple mechanism, you might find network protocols or peer to peer routing protocols that can allow peers to find each other, and/or route data appropriately. >This is why there are true peer to peer nets such as CAN which contemplate >such things. CAN is true peer to peer and will run at up to 1 MBit for >short distances. It's also extremely robust. There are CAN protocols which >could have this structure. The best peer to peer one of which I'm aware is >CAN Kingdom. It's not a lightweight protocol. CAN is only suitable for a >small local net. It would require a CAN controller chip such as MCP2510 or >SJA1000. CAN guarantees that urgent messages get through quickly and in a >bounded time. This is why it's used on antilock brake and fuel injection >systems where there is little margin for error. I see that ISO 11898 covers CAN and specifies details at layer 1 and 2. There is stuff about timing, format of packets etc. Nothing about routing, CSMA vs single fabric networks etc. >JXTA also addresses similar issues and that's where we are going: >http://jcx.systronix.com/rfmodems.htm >since it works with or without wires and already scales from embedded >devices to the internet. > >Maybe some subset of a JXTA peer could be used on a party line net like CAN >(preferable) or I2C (less ideal but lower cost) to accomplish what you want? JXTA is a layer 7 protocol that can run on CAN, or a network such as I suggested for making SPI look like peer to peer. My suggestion for SPI would create a dual direction network between the master and the slaves. So, as they are sending, they are also receiving. What this means is that we actually get a net doubling of bandwidth capacity at whatever speed the SPI bus runs at. It is just an idea, but it will work just fine. It will provide a network exactly like you would see with a TCP/IP switched network, in terms of topology. Broadcast networks are fine for one or two users, but degrade quickly... There's plenty of experience that says about 20% utilization is all that you can count on before you get a dramatic degradation for each percentage above that. Clearly there is research going on that has shown some ways to make the degradation less dramatic (search google for 'CSMA degradation'). LonWorks has a proprietary solution as do others specific to their use. The easies and simplest is the round-robin, equal time, equal access mechanism that I described. It will provide dependable, predictable data transfer from one peer to another. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Christopher S. <cs...@oo...> - 2003-06-27 19:36:43
|
Ted, I am trying to update japl and do not seem to get anything either through cvs or the build.xml - all/cork etc. Any ideas? Chris > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris wrote: > > >If we all agree on the MediaController interface then everyone can > >implement their favorite hardware device in their xxxMediaController > >and expect a plug and play deployment. This could be the first > >operational JAPL! Lets go! > > Chris, this is a killer idea! The first question I have is whether the > MediaController is a JAPL interface or an Embedlet Adapter? In > my mind, JAPL > interfaces were designed to represent I/O circuits like a servo > controller, a > temperature sensor, an emergency stop button, etc. > > For example, I want the CNC controller Embedlet that I am > building to use a > something like a JAPL ServoController interface to control the > movements of the > XYZ positioning system. I want to be able to have the Embedlet > send a message > like: > > servoController.moveTo(X, Y, Z, Speed); > > to the servo mechanism and I don't want to know how the > communications between > the JAPL interface and its analogous I/O circuit actually happens > so it appears > that the MediaController is positioned behind the JAPL interface > somewhere. > > The MediaController appears to be a clean communications > mechanism that allows > a JAPL interface to easily communicate with the physical I/O > circuit that it > represents so perhaps it fits the role of Adapter better? > > Ted > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Bruce B. <bb...@sy...> - 2003-06-27 19:10:38
|
At 01:48 PM 6/26/2003 -0700, you wrote: >From: "Gregg G. Wonderly" <gr...@sk...> >Reply-To: emb...@li... <snip> >Slaves in the ready-list are now ready to transfer packets between devices. >The ready-list thread would start clocking bytes from the slaves, and feeding >them any traffic that is destined for them. Each slave in the ready-list >would have a packet queue that would be composed of a several bytes of buffer >(slave count + a few should work). The packets from the slaves would >have, at >the front, a packet type identifier and a destination slave number. The data >would then be clocked, round robin, one byte at a time. The master would >transfer a byte to the slave, and take the return byte and process it. When >the slave indicated end of data, it would be put back in the poll list. > >This would give you a full peer to peer (via the master) and multi session >network that should be able to provide a high degree of flexibility using >SPI... I'm lost. Peer to peer either is or isn't. If there is one master then it isn't peer to peer since there's no peer-to-peer communication ever, only master-to-peer. I realize I'm stating the obvious but... If I grasp your idea (and I'm not sure I do) the master visits all the intelligent slaves, gets data packets from them, then redistributes any such packets which are intended to be sent from one slave to another. So the master is a "mailman". The master has to handle every packet twice, which could be done but will become a bottleneck at some point. There's no guarantee that a timely message will get through unless the overall loading is light and the polling is frequent. This could work, I suppose, but how does one node know another exists, and what services it can provide or consume? This is why there are true peer to peer nets such as CAN which contemplate such things. CAN is true peer to peer and will run at up to 1 MBit for short distances. It's also extremely robust. There are CAN protocols which could have this structure. The best peer to peer one of which I'm aware is CAN Kingdom. It's not a lightweight protocol. CAN is only suitable for a small local net. It would require a CAN controller chip such as MCP2510 or SJA1000. CAN guarantees that urgent messages get through quickly and in a bounded time. This is why it's used on antilock brake and fuel injection systems where there is little margin for error. JXTA also addresses similar issues and that's where we are going: http://jcx.systronix.com/rfmodems.htm since it works with or without wires and already scales from embedded devices to the internet. Maybe some subset of a JXTA peer could be used on a party line net like CAN (preferable) or I2C (less ideal but lower cost) to accomplish what you want? Bruce |
|
From: Christopher S. <cs...@oo...> - 2003-06-27 18:55:35
|
Ted, MediaController is definitely a JAPL interface that surfaces inter-processor communication. I think that it should be available to the Embedlet components directly. Where you divide things up from there is not as important. It would, I think, be OK for one JAPL to use another but what you give up is the flexibility to plug and play, dynamically configure and 'soft-wire' that is supported by Embedlets. My feeling is that JAPL's main mission should be to establish a common ground for the emerging Java board and chip makers to publish their I/O libraries without the encumbrance of the Embedlet infrastructure. Higher level functionality such as a motor controller would seem to fit the Embedlet model a little more closely because of the 'soft-wire' event model, configuration and services that are available. If you start to build these into JAPL then the complexity and weight will deter acceptance. That being said, there is nothing to prevent one from publishing a complex control component under JAPL, then providing an Embedlet wrapper to drop it into an Embedlet container. Time will tell where the most effective deployment strategy lies. For the time being let's get the interface out there and see how it fits. I have built the network package for the Embedlets side and will publish it over the weekend. If you want me to put the MediaController together, I will do that as well. Chris > _______________________________________________ > > Chris wrote: > > >If we all agree on the MediaController interface then everyone can > >implement their favorite hardware device in their xxxMediaController > >and expect a plug and play deployment. This could be the first > >operational JAPL! Lets go! > > Chris, this is a killer idea! The first question I have is whether the > MediaController is a JAPL interface or an Embedlet Adapter? In > my mind, JAPL > interfaces were designed to represent I/O circuits like a servo > controller, a > temperature sensor, an emergency stop button, etc. > > For example, I want the CNC controller Embedlet that I am > building to use a > something like a JAPL ServoController interface to control the > movements of the > XYZ positioning system. I want to be able to have the Embedlet > send a message > like: > > servoController.moveTo(X, Y, Z, Speed); > > to the servo mechanism and I don't want to know how the > communications between > the JAPL interface and its analogous I/O circuit actually happens > so it appears > that the MediaController is positioned behind the JAPL interface > somewhere. > > The MediaController appears to be a clean communications > mechanism that allows > a JAPL interface to easily communicate with the physical I/O > circuit that it > represents so perhaps it fits the role of Adapter better? > > Ted > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: James C. <ca...@vi...> - 2003-06-27 06:01:35
|
> The only way that I can see this happening is if the servo card were >tagged with information that described what it is. This is a standard WebServices task.. Ping the WebService to find out what services it supports. I like your vision on the application :-) Going away for the weekend for a little R&R but back into it next week! Cheers all, James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Friday, 27 June 2003 7:56 AM To: emb...@li... Subject: [Embedlets-dev] A use scenario and I/O device tagging Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ Here is the use scenario I would like to eventually achieve for the assembly of the controller for the CNC Plasma Cutter that I am building: 1) Turn on a PC and launch the Graphic Wiring Tool. 2) Instantiate a new Embedlet Container. 3) Drag a CNCController Embedlet from the Embedlet Pallet and drop it into the container. The CNCControllerEmbedlet has been pre-designed to use a JAPLServoController interface to talk to the servo I/O device that it will be controlling. 4) Plug a JSIMM backplane into a serial port on the PC (The SLIP/UART scheme really shines here!). 5) Plug a muvium-based 3 Axis industrial servo/stepper controller JSIMM card into the JSIMM backplane and the JAPLServoController interface that represents this servo card should *automatically* appear inside of the wiring tool. The only way that I can see this happening is if the servo card were tagged with information that described what it is. (Systronix has been working on tag-enabling their products and I think that we will need to figure out a way to come up with a universal device tagging scheme which can be used to associate any I/O hardware with the JAPL interface that represents it). 6) Drag the JAPLServoController component (that 'magically' appeared) onto the CNCControllerEmbedlet component in order to bind them. 7) Configure the CNCControllerEmbedlet by right-clicking on it and giving it information like the size and resolution of the X, Y and Z axis, maximum axis traverse rate, etc. 8) Power up the servo drives in order to test and adjust the system's configuration on a *live* system. 9) After everything is working as desired, have the wiring tool package the application and then deploy it to a TStik. 10) Disconnect the JSIMM backplane from the PC and then plug the TStik into the backplane. When the TStik powers up, its Embedlet based application should automatically re-bind the JAPL interfaces it contains with the physical I/O devices that are plugged into the backplane. So far there does not appear to be any fundamental reason why a use-scenario like this cannot be realized and we seem to be doing a fairly good job of coming up with the step-by-step subsolutions needed to solve the overall problem. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: James C. <ca...@vi...> - 2003-06-27 05:57:29
|
>An aspect of this that really caught my attention was the ability to >plug the I/O hardware into a PC for development purposes and then >plug it into the target embedded system for deployment. In my opinion >this is an absolutely brilliant concept! Well this is one of the advantages of using standards, and there are others for example the JAPL Remoting infrastructure I am talking about (and have begun implementing) is compatible with .NET Ie you can also plug the uVM controller into a .NET application and invoke remoting services in the controller and connect it via the same UART/SLIP connector. In actual fact what we are talking about here is WebServices in the HttpGet format but then also we can extend this with the XML SOAP (Gregg will like this) format down the track. So then.. be it, a java application or embedlet using the 'JAPLRemotingServices' Stack over a javax.com controlled UART or a .NET application using Remoting over a Windows SLIP direct connection, with packets bounced half-way around the world and back, it can all access the uVM remoted device in the same way. First pass requires a servlet to be implemented in the uVM controller. Second pass I will support WebServices directly in the uVM devices with auto-generated WebServices descriptor files a.k.a .NET P.S Speaking of .NET, soon you will be able to program your uVM device in C# or VB.NET! I have been working on a server side transform tool that makes it all happen. Just send a .NET assembly and get back a .uvm file.. Pretty cool huh. James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Ted Kosan Sent: Friday, 27 June 2003 6:53 AM To: emb...@li... Subject: [Embedlets-dev] RE: SLIP/UART and Peer-to-peer over master/slave Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ James wrote: >I do fully intend to support any* serial transport hardware for muvium >but let me just explain the idea for the SLIP over UART. [...] >I do agree that one limitation of the UART scheme is the lack of the >ability for the remote device to be the master and hence generate >asynchronous events as supported by I2C. However using your idea >of flexibility first, the UART scheme is far simpler to implement >and test using existing UART hardware and will cover the vast >majority of applications. And Gregg wrote: >If you want to create a peer to peer SPI based architecture that >allows arbitrary interconnects, then you would do the following. Ok, after thinking about it for a while I have decided that I very much like the SLIP over UART strategy as a place to start. An aspect of this that really caught my attention was the ability to plug the I/O hardware into a PC for development purposes and then plug it into the target embedded system for deployment. In my opinion this is an absolutely brilliant concept! Also, it seems that both you and Gregg had similar strategies for implementing peer-to-peer on top of a master/slave architecture and this seems to be an excellent idea which addresses a number of concerns that I had with master/slave hardware. Ted __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ 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.
.){kind=link}
Thanks for helping keep SourceForge clean.
X