embedlets-developer Mailing List for Outpost Embedlet Container (Page 3)
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: Kelly S. <be...@ea...> - 2003-12-08 02:25:11
|
Dear Ted - Re: "please let us know if it looks like it will fit." I did a cut'n'paste of the boards gif image, and it (by luck!) is 1-to-1 as the same "JSIMM Proto-Board" that Bruce Boyes (Systronix) sells. The 1/20" grid thru-holes for the connectors came out exactly correct, when I printed the gif image. Re: "What kind of a system will the stepper motors be controlling?" Take a look at: http://www.motiongroup.com/mmc.htm#mmc4s http://www.motiongroup.com/mmc.htm They work quite well! They are intend for MS-DOS QBASIC control of CNC machines, and any old "legacy" PC will do. I was challanged to make this product controllable over the WWW, (or local Ethernet). A piece of cake (in no small way, thanks to YOU and your Java/TINI/1-Wire classes, a few years back). Thanks! Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Sunday, December 07, 2003 6:12 PM To: emb...@li... Subject: [Embedlets-dev] Re: Embedlets /JackNet "bus expansion" for the Systronix TStik/TILTPro400 Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ Kelly wrote: > Take a look at: http://dontronics.com/dt204.html If a populated one of these would actually fit on the TStik socket board that would certainly be great. When you get one in, please let us know if it looks like it will fit. > The > "target" application is for controlling multi-axis stepper motors, with a > "smart controller" via RS-232, and will include motor temperature monitoring > (via 1-Wire DS18S20's). What kind of a system will the stepper motors be controlling? Ted __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-12-08 02:12:07
|
Kelly wrote: > Take a look at: http://dontronics.com/dt204.html If a populated one of these would actually fit on the TStik socket board that would certainly be great. When you get one in, please let us know if it looks like it will fit. > The > "target" application is for controlling multi-axis stepper motors, with a > "smart controller" via RS-232, and will include motor temperature monitoring > (via 1-Wire DS18S20's). What kind of a system will the stepper motors be controlling? Ted __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ |
|
From: Kelly S. <be...@ea...> - 2003-12-08 01:35:16
|
Dear Ted and all on the Embedlets/JackNet list: This looks ideal for some Systronix TStik/TILTPro400 "bus expansion". It looks like it will take two 30-pin JSIMM I/O boards, and leave space for RJ45/RJ11 connector height in a "stack" of boards (right angle to the TStik, but parallel to the TILTPro400). It might be a nice $9.00 USD solution, where additional "JackNet" I/O might be needed. Take a look at: http://dontronics.com/dt204.html I wandered into this looking for a solution to add two Systronix JSQS (JSIMM/HSIO Quad Serial) ports, to a project for stepper motor control. The "target" application is for controlling multi-axis stepper motors, with a "smart controller" via RS-232, and will include motor temperature monitoring (via 1-Wire DS18S20's). Ref: http://www.motiongroup.com/mmc.htm#mmc4s The first go will be with a Tynamo servlet... Ref: http://tynamo.qindesign.com/ ...then, JackNet! Best regards, Kelly Smith |
|
From: Ted K. <tk...@ya...> - 2003-12-04 19:20:09
|
Kelly wrote: > I get the following error when using 'run.bat': [snip] Thanks for letting me know about this Kelly! A file was absent from the distribution .zip archive which was causing the error. I fixed the problem and uploaded a new 0.41 release. Let me know if it works for you now, Ted __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Kelly S. <be...@ea...> - 2003-12-04 15:48:25
|
Dear Gregg - I agree with all that you state here, and in a previous email by myself, I implied that a Systronix JStik/JStamp could _MAYBE_ "cut-the-mustard. But the real problem is that you have no metric for what a particular platform "can do best"...and I am not eager to spend endless hours to do "Thread Tuning" to find out! And, benchmarks are meaningless when the "rubber meets the road" (i.e., when you start to discover the limitations). IMHO - Somewhere between a TINI and a CRAY, is a solution, but finding that out can be a bitch! Its kind of like discovering that "Blackboard Pascal" can't do I/O in the real world without extensions (after spending a semester to find that out; saying to yourself, "Well, Pascal is useless!"). Maybe that's not a good analogy, but it was the first I could think of... 8D Thank you in advance, for allowing me the time to offend all of the Pascal Programmers out there. Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Gregg G. Wonderly Sent: Thursday, December 04, 2003 7:12 AM To: emb...@li... Subject: Re: [Embedlets-dev] JINI SmartHome framework Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ >But determining what they may do best, may be a lesson in frustration (as I >found out with the _MAXIMUM_ number of X10 modules that were "usable"), >where a considerable amount of development time may have to be (actually >was) trashed, just to find out "what that _CANNOT_ do best". One of the important things it sounds like you learned is that there are in fact classes of problems that particular platforms are not good for. A Java programming environment that supports realtime (soft or hard, or near) is much different from a Java programming environment that does not. The TINI appears to have a lot of overhead in its JVM implementation that creates unpredictable behavior for certain classes of problems. I've not had a chance to use the TINI that I have yet, but I keep trying to make a point to play with it. The muvium environment and the JStamp environment have a lot more potential for predictable behavior it seems. I've used the aJ100 processor via the PC-104 board and the dev board to develop some fairly serious applications. One was a remote alarm isolation multiplexor that included telnet/serial port management console, SNMP management and FTP file access. The other was an attitude indicator that read a serial stream from an attitude indicating device at 19200 and drew a nice color display (like you'd see in an airplane cockpit) of the ground reference, bank and pitch indication. It worked fine on the aJ100. I could easily use the threading model of Java to manage both the data input and the drawing so that the data rate was independent of the rendering. The use of the Java threading model, and monitors/semaphores make it possible to provide semi realtime rendering in a Java environment without realtime constraint support. But, you have to learn how to always provide a consistent data model based on data flow in, and data use by the rest of the application. If you have soft-realtime and non-realtime constraints that need nearly 100% of the CPU to be effective, then you have to learn how to segmentize those threads so that you provide your own quanta management within the system, allowing each thread to do the minimum that it needs to do to arrive at the next safe point. The RTSJ efforts remove this burden from the programmer. If more Java programming environment vendors provide implementations of RTSJ, then it will become trivial to write complicated timing-constraint based applications as long as the processor has enough power to satisfy the needs of the system. ----- gr...@cy... (Cyte Technologies Inc) ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Gregg G. W. <gr...@sk...> - 2003-12-04 15:12:10
|
>But determining what they may do best, may be a lesson in frustration (as I >found out with the _MAXIMUM_ number of X10 modules that were "usable"), >where a considerable amount of development time may have to be (actually >was) trashed, just to find out "what that _CANNOT_ do best". One of the important things it sounds like you learned is that there are in fact classes of problems that particular platforms are not good for. A Java programming environment that supports realtime (soft or hard, or near) is much different from a Java programming environment that does not. The TINI appears to have a lot of overhead in its JVM implementation that creates unpredictable behavior for certain classes of problems. I've not had a chance to use the TINI that I have yet, but I keep trying to make a point to play with it. The muvium environment and the JStamp environment have a lot more potential for predictable behavior it seems. I've used the aJ100 processor via the PC-104 board and the dev board to develop some fairly serious applications. One was a remote alarm isolation multiplexor that included telnet/serial port management console, SNMP management and FTP file access. The other was an attitude indicator that read a serial stream from an attitude indicating device at 19200 and drew a nice color display (like you'd see in an airplane cockpit) of the ground reference, bank and pitch indication. It worked fine on the aJ100. I could easily use the threading model of Java to manage both the data input and the drawing so that the data rate was independent of the rendering. The use of the Java threading model, and monitors/semaphores make it possible to provide semi realtime rendering in a Java environment without realtime constraint support. But, you have to learn how to always provide a consistent data model based on data flow in, and data use by the rest of the application. If you have soft-realtime and non-realtime constraints that need nearly 100% of the CPU to be effective, then you have to learn how to segmentize those threads so that you provide your own quanta management within the system, allowing each thread to do the minimum that it needs to do to arrive at the next safe point. The RTSJ efforts remove this burden from the programmer. If more Java programming environment vendors provide implementations of RTSJ, then it will become trivial to write complicated timing-constraint based applications as long as the processor has enough power to satisfy the needs of the system. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Kelly S. <be...@ea...> - 2003-12-04 14:59:30
|
Dear Ted - I am probably being an idiot (again), but I get the following error when using 'run.bat': [error] java.io.FileNotFoundException: C:\JXTA Embedlets JBasic\jplab\modes\catalog (The system cannot find the file specified) [error] at java.io.FileInputStream.open(Native Method) [error] at java.io.FileInputStream.<init>(FileInputStream.java:106) [error] at java.io.FileInputStream.<init>(FileInputStream.java:66) [error] at org.gjt.sp.jedit.jEdit.loadModeCatalog(Unknown Source) [error] at org.gjt.sp.jedit.jEdit.reloadModes(Unknown Source) [error] at org.gjt.sp.jedit.jEdit.main(Unknown Source) [error] java.lang.NullPointerException: Mode must be non-null [error] at org.gjt.sp.jedit.Buffer.setMode(Unknown Source) [error] at org.gjt.sp.jedit.Buffer.<init>(Unknown Source) [error] at org.gjt.sp.jedit.jEdit.openFile(Unknown Source) [error] at org.gjt.sp.jedit.jEdit.newFile(Unknown Source) [error] at org.gjt.sp.jedit.jEdit.newFile(Unknown Source) [error] at org.gjt.sp.jedit.jEdit$2.run(Unknown Source) [error] at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) [error] at java.awt.EventQueue.dispatchEvent(EventQueue.java:454) [error] at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja va:201) [error] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :151) [error] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) [error] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) [error] at java.awt.EventDispatchThread.run(EventDispatchThread.java:100) It appears that this is looking for some setup in 'catalog': <?xml version="1.0"?> <!DOCTYPE MODES SYSTEM "catalog.dtd"> <MODES> <!-- Add lines like the following, one for each edit mode you add: --> <!-- <MODE NAME="foo" FILE="foo.xml" FILE_NAME_GLOB="*.foo" /> --> </MODES> ...ahh, just what do you mean by edit mode? I get the splash screen, and of course... it just hangs (due to the error above). Best regards, Kelly -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Monday, December 01, 2003 12:08 AM To: emb...@li... Subject: [Embedlets-dev] JBASIC 0.4 alpha release (Java basic, JackNet basic, we'll see ;-) Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ As promised a month or so ago, JBASIC has been added to the CVS and an official release has been placed on the embedlets sourceforge site: http://sourceforge.net/projects/embedlets JBasic's primary mission is to bring as many developers as possible onto the Embedded Java platform by removing the following barriers to entry: 1) The need to know Java. 2) The need to use difficult tools like TiniConverter, BuildDependency, JemBuilder, Charade, etc. 3) And relatively soon (through the use of JXTA) the need to use JavaKit, FTP, Telnet or other low-level Internet utilities to configure or program almost any Embedded Java device. JBasic's target audience includes: 1) BasicStamp users. 2) PICBasic users. 3) IT support personnel that will be required to configure, install and maintain Enterprise Outposts. 4) Newbie programmers who are interested in learning how to program with a simple language which is also capable of running on internet-connected embedded systems The JBasic 0.4 alpha release consists of a GUI-based builder and a version of the interpreter that will run on a TINI/TSTIK. JBasic does not currently have any I/O capabilities but these will be added soon through the use of JAPL peripherals that will be usable across all Embedded Java systems I am pre-releasing JBasic to the Embedlets developer list so that everyone here can get a first-look at it before I start advertising it on the major Embedded Java lists (which should happen within a week or so). I have created a new 'embedlets-jbasic' list to handle all of the jbasic related list traffic. Anyway, this is a 'heads up' to the Embedlets group that our membership will be increasing in the near future and it should prove to be an interesting time. Ted __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Kelly S. <be...@ea...> - 2003-12-04 14:25:03
|
Dear Greg - Re: "do simply what they do best". But determining what they may do best, may be a lesson in frustration (as I found out with the _MAXIMUM_ number of X10 modules that were "usable"), where a considerable amount of development time may have to be (actually was) trashed, just to find out "what that _CANNOT_ do best". There is no really good way to determine such limitations in advance, of actually trying it out in the development cycle. And only to find out that "You can't get there from here". So, you find out the hard way... My only saving grace, was that I developed the code (and found the limitations out of interest only), and was not under-the-gun to actually produce a viable product, that worked not just some of the time, but _ALL_ of the time! It would be great to have some sort of "metric" to really find out what platform can "do best"; but I don't have a crystal-ball, that would tell me (i.e., after its too late in the project). What I wound up with was a "potential" (but working) _EXAMPLE_ONLY__ for TINI\X10 code, that falls apart "in the real world". That is, when you hit the maximum number of "devices" (such as the X10 power modues), as the limitation. To say that it was a disappointment to find this out (after a year), is an understatement. Comment? Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Gregg G. Wonderly Sent: Wednesday, December 03, 2003 3:34 PM To: emb...@li... Subject: Re: [Embedlets-dev] JINI SmartHome framework Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ >That pretty much precludes the usage of TINI/TStik... A Systronix JStamp or >JStik "might" cut it though... Not enough "Horse-Power"; just a thought, >IMHO. > >I didn't get enough TINI "Horse-Power" when trying to keep track of eight >(or more) X10 power modules... I abandoned that idea (after a year of trying >to optimize the code), and used a Dell laptop instead. 8D (I would have >preferred a Systronix TStik!). Hi Kelly! The important thing is that the surrogate model lets devices such as the TStick and JStamp and muviem devices do simply what they do best. They just need a comms path back into the house network so that they can 'see' the surrogate host using whatever protocol. So, the devices could use blue tooth, or a simple manchester coded fsk over 400mhz/900mhz. There are lots of possibilities. In this way, the work is distributed to be done by devices that can do a particular job the best. The low cost devices can be deployed in larger numbers to meet economy of scale, and the comms path can be whatever it takes to make it happen (flashing lights or otherwise :-) ----- gr...@cy... (Cyte Technologies Inc) ------------------------------------------------------- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Gregg G. W. <gr...@sk...> - 2003-12-03 23:33:37
|
>That pretty much precludes the usage of TINI/TStik... A Systronix JStamp or >JStik "might" cut it though... Not enough "Horse-Power"; just a thought, >IMHO. > >I didn't get enough TINI "Horse-Power" when trying to keep track of eight >(or more) X10 power modules... I abandoned that idea (after a year of trying >to optimize the code), and used a Dell laptop instead. 8D (I would have >preferred a Systronix TStik!). Hi Kelly! The important thing is that the surrogate model lets devices such as the TStick and JStamp and muviem devices do simply what they do best. They just need a comms path back into the house network so that they can 'see' the surrogate host using whatever protocol. So, the devices could use blue tooth, or a simple manchester coded fsk over 400mhz/900mhz. There are lots of possibilities. In this way, the work is distributed to be done by devices that can do a particular job the best. The low cost devices can be deployed in larger numbers to meet economy of scale, and the comms path can be whatever it takes to make it happen (flashing lights or otherwise :-) ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Kelly S. <be...@ea...> - 2003-12-03 17:09:53
|
All - Re: "The number one issue though is still having to have a J2SE1.4 capable computer somewhere in the network to provide the surrogate host at a minimum, and the remainder of the Jini tools too." That pretty much precludes the usage of TINI/TStik... A Systronix JStamp or JStik "might" cut it though... Not enough "Horse-Power"; just a thought, IMHO. I didn't get enough TINI "Horse-Power" when trying to keep track of eight (or more) X10 power modules... I abandoned that idea (after a year of trying to optimize the code), and used a Dell laptop instead. 8D (I would have preferred a Systronix TStik!). - Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Gregg G. Wonderly Sent: Wednesday, December 03, 2003 8:43 AM To: emb...@li... Subject: Re: [Embedlets-dev] JINI SmartHome framework Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ >Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >_______________________________________________ > >Gregg, > >What do you know about this JINI based smarthome framework?: > >http://www.sun.com/br/comms_1021/feature_homes.html This was shown in the Jini Fest at JavaOne this past spring. I did not look at it in depth at that time. They had a lot of foundation stuff in place, but were still tying it all together. It sounds like they've made some progress towards getting it all working together. They were talking about open source and sharing at Jini Fest. Technical stuff: They are using a number of powerful features of Jini. ServiceUI allows the user interface to be provided by the server via downloaded code. This is similar to the applet model, but a local Java application is the host of the interface, not your web bowser. ServiceUI includes the notion of toolkit specific UIs so that the client can ask for a UI that supports its toolkit (such as swing vs AWT, and with CDC/RMI a J2ME toolkit too). They have Javaspaces in use for holding the current state of things and for managing leased access to resources. They've got X-10 interfaces for simple controls. There is, as alluded to, some nice layering of responsibilities to allow differing devices and protocols to be plugged into the system. The use Jini services extensively, and I think they are using the Surrogate stuff for some of the services related to stupid devices. This means that devices and controls dynamically find and recognize each other to adapt to changes in the system quickly and easily. I can't draw a very exact picture of the system that I saw then, it's been a while. But, nevertheless, they have used Jini extensively, and their application shows a lot of the power associated with it. The number one issue though is still having to have a J2SE1.4 capable computer somewhere in the network to provide the surrogate host at a minimum, and the remainder of the Jini tools too. ----- gr...@cy... (Cyte Technologies Inc) ------------------------------------------------------- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Gregg G. W. <gr...@sk...> - 2003-12-03 16:43:08
|
>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >_______________________________________________ > >Gregg, > >What do you know about this JINI based smarthome framework?: > >http://www.sun.com/br/comms_1021/feature_homes.html This was shown in the Jini Fest at JavaOne this past spring. I did not look at it in depth at that time. They had a lot of foundation stuff in place, but were still tying it all together. It sounds like they've made some progress towards getting it all working together. They were talking about open source and sharing at Jini Fest. Technical stuff: They are using a number of powerful features of Jini. ServiceUI allows the user interface to be provided by the server via downloaded code. This is similar to the applet model, but a local Java application is the host of the interface, not your web bowser. ServiceUI includes the notion of toolkit specific UIs so that the client can ask for a UI that supports its toolkit (such as swing vs AWT, and with CDC/RMI a J2ME toolkit too). They have Javaspaces in use for holding the current state of things and for managing leased access to resources. They've got X-10 interfaces for simple controls. There is, as alluded to, some nice layering of responsibilities to allow differing devices and protocols to be plugged into the system. The use Jini services extensively, and I think they are using the Surrogate stuff for some of the services related to stupid devices. This means that devices and controls dynamically find and recognize each other to adapt to changes in the system quickly and easily. I can't draw a very exact picture of the system that I saw then, it's been a while. But, nevertheless, they have used Jini extensively, and their application shows a lot of the power associated with it. The number one issue though is still having to have a J2SE1.4 capable computer somewhere in the network to provide the surrogate host at a minimum, and the remainder of the Jini tools too. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Ted K. <tk...@ya...> - 2003-12-03 03:51:00
|
Gregg, What do you know about this JINI based smarthome framework?: http://www.sun.com/br/comms_1021/feature_homes.html Ted __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Ted K. <tk...@ya...> - 2003-12-01 08:08:09
|
As promised a month or so ago, JBASIC has been added to the CVS and an official release has been placed on the embedlets sourceforge site: http://sourceforge.net/projects/embedlets JBasic's primary mission is to bring as many developers as possible onto the Embedded Java platform by removing the following barriers to entry: 1) The need to know Java. 2) The need to use difficult tools like TiniConverter, BuildDependency, JemBuilder, Charade, etc. 3) And relatively soon (through the use of JXTA) the need to use JavaKit, FTP, Telnet or other low-level Internet utilities to configure or program almost any Embedded Java device. JBasic's target audience includes: 1) BasicStamp users. 2) PICBasic users. 3) IT support personnel that will be required to configure, install and maintain Enterprise Outposts. 4) Newbie programmers who are interested in learning how to program with a simple language which is also capable of running on internet-connected embedded systems The JBasic 0.4 alpha release consists of a GUI-based builder and a version of the interpreter that will run on a TINI/TSTIK. JBasic does not currently have any I/O capabilities but these will be added soon through the use of JAPL peripherals that will be usable across all Embedded Java systems I am pre-releasing JBasic to the Embedlets developer list so that everyone here can get a first-look at it before I start advertising it on the major Embedded Java lists (which should happen within a week or so). I have created a new 'embedlets-jbasic' list to handle all of the jbasic related list traffic. Anyway, this is a 'heads up' to the Embedlets group that our membership will be increasing in the near future and it should prove to be an interesting time. Ted __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Gregg G. W. <gr...@sk...> - 2003-11-25 04:11:11
|
>The reason I am interested in this issue is that my vision for how I think an >Enterprise Outpost should work includes using a standardized 'intelligent' >serial bus for I/O expansion (either SPI or I2C). If a network protocol could >be standardized for these expansion modules, and if their connector and >electrical interfaces were also standardized, then the expansion modules and >driver software could be used with almost any kind of Outpost implementation, >not just a TStik. > >The 'intelligent' part of the bus indicates that since many of the the I/O >modules are microcontrollers, then the bus could be used as a multimaster >collaborative network which should be able to ease the processing burden on the >main controller. > >Does anyone have any ideas on what kind of protocols would be good to use for >an intelligent expansion bus like this? What we have been doing in our projects is just not trying to simplify this issue. In most of our projects, there is only one reasonably close to standard two way comms protocol that goes over serial, and that is MODBUS. If we have devices that do MODBUS, we have tools ready to apply. If not, then we just bill for custom development. This pushes customers towards standards to some degree. This will be the hard part about any new protocol. It has to appear at the I/O point source first. Then the backend support can be provided for it, and eventually, we can push customers and vendors both towards adoption. But, even modbus has problems with adoption because of hard limits on sizes. We need to try and separate the actual application protocol from the transport choices. The protocol must provide a version number as a base so that it can be enhanced. But, more than that, it should have some compartmentalization that allows optional parts to be specified. This might allow for signatures, encryption, routing (fan out control), QOS and other necessities to be optional so that minimal bandwidth could be achieved for each application. Bandwidth will become an issue, no matter what the transport media is, believe me. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Ted K. <tk...@ya...> - 2003-11-24 17:17:25
|
I have been researching what it would take to leverage JXTA technology in our Enterprise Outpost 'Wide fanout' pattern and here is a diagram I put together which shows this: http://tkosan.javadevices.org/misc/embeddedjava/wide_fanout_pattern.jpg Earlier, Bruce had stressed that CAN was where a lot of the industrial sensor/actuator market was heading and these two sites seem to confirm this position: http://www.canopen.us http://www.odva.org We had also had a significant amount of discussion on creating a multidrop microcontroller network in order to interface to sensors and actuators but after researching this issue again over the past few weeks it is my opinion that our original 'wide fanout, protocol neutralizer' concept is the technology that will be easiest to market initially. For those newer people on the list, the 'wide fanout, protocol neutralizer' concept consists of attaching existing industrial sensor/actuator networks to backend enterprise systems in the most efficient way we could think of. This original concept is what is shown in the diagram. Also, earlier we had talked about using SLIP as the base protocol for a multidrop microcontroller network but SLIP is just a simple point-to-point protocol which is not capable of addressing multiple endpoints. If multiple endpoints need to be addressed then at least the equivalent of an IP layer would need to be implemented on each microcontroller on the network. The reason I am interested in this issue is that my vision for how I think an Enterprise Outpost should work includes using a standardized 'intelligent' serial bus for I/O expansion (either SPI or I2C). If a network protocol could be standardized for these expansion modules, and if their connector and electrical interfaces were also standardized, then the expansion modules and driver software could be used with almost any kind of Outpost implementation, not just a TStik. The 'intelligent' part of the bus indicates that since many of the the I/O modules are microcontrollers, then the bus could be used as a multimaster collaborative network which should be able to ease the processing burden on the main controller. Does anyone have any ideas on what kind of protocols would be good to use for an intelligent expansion bus like this? Ted __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Ted K. <tk...@ya...> - 2003-11-24 16:27:21
|
Kelly wrote: > Dear Ted - I left everything on your server (including the CM11A) over two > weeks ago now. Did you look there? Ok Kelly, I see it. I saw the FireCracker code in there but I did not realize that you had CM11A code in there too. I will start playing with it after Thanksgiving. Thanks! Ted __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree |
|
From: Kelly S. <be...@ea...> - 2003-11-24 08:25:34
|
Dear Ted - I left everything on your server (including the CM11A) over two weeks ago now. Did you look there? Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Monday, November 24, 2003 12:06 AM To: emb...@li... Subject: [Embedlets-dev] X10 CK11A module Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ I have been working on putting together an X10 based demo for the JackNet project with the FireCracker but I am finding the need to receive X10 commands as well as send them. Earlier, Jac had mentioned the CK11A computer interface: http://www.x10.com/automation/x10_ck11a_ci.htm Did someone say that they had Java code to control this module too? If not, I will go ahead and develop something myself. Thanks, Ted __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Ted K. <tk...@ya...> - 2003-11-24 08:05:32
|
I have been working on putting together an X10 based demo for the JackNet project with the FireCracker but I am finding the need to receive X10 commands as well as send them. Earlier, Jac had mentioned the CK11A computer interface: http://www.x10.com/automation/x10_ck11a_ci.htm Did someone say that they had Java code to control this module too? If not, I will go ahead and develop something myself. Thanks, Ted __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Ted K. <tk...@ya...> - 2003-11-19 08:16:58
|
Marc wrote: >> In fact, maybe we could even use actual PC expansion slot cover >>plates? The plates are very cheap and a wide variety of pre-punched >>I/O connector opening styles are already available. > > You mean the 'finger' plates? Yeah, I just measured one and with the bottom and top cut off it is about 4" wide. I will try to post a sketch of what I am thinking of in the next day or two. Ted __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree |
|
From: Bruce B. <bb...@sy...> - 2003-11-19 06:22:01
|
At 08:07 PM 11/15/2003 -0800, you wrote: >From: "Christopher Smith" <cs...@oo...> >To: <emb...@li...> >Subject: RE: [Embedlets-dev] Enclosure for TStik >Date: Fri, 14 Nov 2003 21:10:13 -0800 >Reply-To: emb...@li... > >Schroff has this kind of Euro-card packaging as well. I have used them for >some time with success. > >http://www.schroff.us/home.asp > >The SaJe product line fits this standard nicely. Unfortunatley JStik does >not seem to conform from what I can see (Bruce?). > >Chris It does, when mounted in the JSimm backplane which is a 100x100 mm euroboard. Bruce |
|
From: Jac K. <j.k...@th...> - 2003-11-18 23:05:32
|
On Mon, 17 Nov 2003, Ted Kosan wrote: > But, if the messages were digitally signed, then only those messages > signed by an authorized entity (our cell phone) would be considered > valid. Sure, I've been thinking some hash value based on data, shared secret, PIN (in case cell phone gets lost) and transaction number (to prevent replay attacks). Bouncy castle crypto should have some code for this. Will look into this some time next week... Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Jac K. <j.k...@th...> - 2003-11-18 22:53:12
|
On Mon, 17 Nov 2003, Ted Kosan wrote: > Kelly wrote: > > As I stated before... I would not trust'em to run a coffee pot. As you sit > > there pondering that one, consider your house burning down... Kelly, as I stated before, We're not running coffee pots on them, just lighting and on two seperate locations we did not have your problems. May-be we're just lucky, may-be it has something to do with the 220V we're using or the difference in building regulations? Anyway, it works. > > I vote for an iButton DS1996 64kbit EEPROM RAM to hold my XML device > > and ID tags (sitting in a Systronix 8x1-Wire board), and running CAT5 > > around the house (in the walls) using Systronix 8x1-Wire boards and > > relays (which I am doing). Bob Hinton has a very nice "House Monitor" > > implementation for TINI (or TStik) w/1-Wire devices that works great, > > is secure, and most important RELIABLE. Running CAT5 in walls might be nice if the walls are hollow, but given concrete walls and floors (with steel inforcements) of 25 cm where one needs a special drill when something needs to be hung makes running CAT5 hard to say the least. And we might not mind ugly cables running all over the office (or even the house), Joe Average (and his wife) most certainly will mind. > But, the foothold must come first... And anyway, if houses burn down, > this is not our responsibility because the X10 vendors and installers > have already taken the responsibility for this and all of the modules > are already FCC and UL approved ;-) Ted, you are right, using these modules actually allows us to ignore the regulations for connecting stuff to dangerous voltages. That has been taken care of by the X10 people. (Another reason I've been using X10 for years now, 220V sacres the * out of me after having touched life wires once) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Gregg G. W. <gr...@sk...> - 2003-11-18 20:49:53
|
>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >_______________________________________________ > >Gregg wrote: > >> Well, I use a 3ft serial cable extension from my PC to my desktop so that I >> can plug the firecracker in, or my programming cable for my j2me phone or >> whatever else. I was setting there trying to decide what to call it, and I >> thought "Hey, that cable looks like a fuse on the firecracker" And so, the >> name was... > >:-) > >Ok then, would it be ok if we dropped the Fuse part of the class name? Yes, pick a better name, please :-) ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Marc N. <ma...@ge...> - 2003-11-18 20:43:15
|
Ted et al... > If I can come up with a way to sell 100 TStik based OutPosts, would you be in > a position to re-design your enclosure to do the following: > > 1) Accomodate JSIMM cards. If Hammond have an existing extrusion, then it's just a matter of doing new CAD drawings for new end panls. > 2) Allow for the addition of extra I/O connectors to accommodate any extra I/O > circuits that might be added to the JSIMM slot or to the 'Embedlets' expansion > slot? That could be done. > In fact, maybe we could even use actual PC expansion slot cover plates? The > plates are very cheap and a wide variety of pre-punched I/O connector opening > styles are already available. You mean the 'finger' plates? -marc |
|
From: Christopher S. <cs...@oo...> - 2003-11-18 20:37:28
|
This sounds like a sensible strategy that does not interfere at all with other developments around power line control, wired and wireless Embedlet interfaces. > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Kelly wrote: > > > As I stated before... I would not trust'em to run a coffee pot. > As you sit > > there pondering that one, consider your house burning down... I > vote for an > > iButton DS1996 64kbit EEPROM RAM to hold my XML device and ID > tags (sitting > > in a Systronix 8x1-Wire board), and running CAT5 around the > house (in the > > walls) using Systronix 8x1-Wire boards and relays (which I am > doing). Bob > > Hinton has a very nice "House Monitor" implementation for TINI > (or TStik) > > w/1-Wire devices that works great, is secure, and most > important RELIABLE. > > Rule #2 of the Fundamental Laws of Marketing states: > > "If your marketing strategy requires you to educate your market > before you can > sell products into it, you are going to starve." > > This has been the main thing that has been killing us in the Embedded Java > space because one of the toughest things in the world to do is to teach > something new to somebody, let alone a whole market of somebodys. > > Imagine if one were required to teach some Algebra to the > McDonald's worker who > takes your order before you could get your food. ;-) > > > I think that X10 is universally considered to be an extremely klunky > technology, but a million+ dollar market exists around it and at > this point in > time, Embedded Java needs to start moving into lucrative markets ASAP. > > > As I have had a chance to study the X10-based Home Automation > market more in > depth during the past week, I am becoming more convinced that > ever that Java > and Embedded Java can do wonders for this market starting right now. > > Once a foothold is obtained in this market, the doors should then > start to open > up for increasing the reliability of the technologies used in > this space. The > Home Automation space is eventually going to really love the > technologies we > have been playing with like Embedded Java, XML and 1-Wire. > > > But, the foothold must come first... And anyway, if houses burn > down, this is > not our responsibility because the X10 vendors and installers have already > taken the responsibility for this and all of the modules are > already FCC and UL > approved ;-) > > > In order to succeed in this market, we do not need to fix all of > it problems, > all we need to do is to give them more capabilities then they > currently have. > And there must be a 100 ways for Java to start doing this right now. > > All we need to do is to discover them... > > > Ted > > __________________________________ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > _______________________________________________ > 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.
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X