No announcement yet.

Java Applet Serial Write Capability

  • Filter
  • Time
  • Show
Clear All
new posts

  • Java Applet Serial Write Capability

    Hi All,
    I apologize in advance for my lack of understanding to date. I'm definitely much more of a firmware guy than a software guy.

    I'm attempting to use a Matchport b/g Pro to wirelessly communicate to a PIC via the Matchport's serial port (RS-232, Port 1):

    Networked Machine <=> Wireless Network <=> Matchport b/g Pro <=> PIC

    The ultimate goal of this project it to be able to be able to send serial data originating from a user-selectable, java-based applet stored on/served up by the Matchport. I'm aware of the SDK sample C-code (namely, tunnel.c) and associated header files, but I'm unaware how to implement this code within my applet.

    The ultimate question is, seeing as the established Applet is Java-based, how exactly do I send serial data from the applet code? I'm sure there's is a Java alternative to the SDK sample C-code, but my newb-status prevents me from knowing exactly where to start looking! As this is my first dance with Lantronix products and programming, I welcome any code snippets, example programs, or suggestions, especially if someone has any experience with this applet-based application! At least I see this is as a more up-front, general question, but if anyone needs any additional specifics, don't hesitate to ask for clarification.

    Thank you for your help and for your time! (go easy on me, now! lol)

    Best regards,
    Last edited by MacGyver; 03-26-2010, 11:49 PM. Reason: clarification

  • #2
    Hi Robert,

    We have a tutorial for our older, Cobos based products that details this type of thing. I have not studied this document, but I believe it will be a starting point for you as the techniques should apply to Evolution based devices also.



    • #3
      Here's a couple of clarifying comments on the FAQ referenced in the previous post:

      Evolution based device servers (the focus of this forum) support CGI, allowing you to leverage that technology in addition to the Java Applet if needed.

      There is no need to use the web2cob utility to create COB files. Web content is uploaded (via FTP) to the device server's file system. The root directory for the HTTP server is /http, so place all your HTML and hosted Java applet in /http (and/or subdirectories).

      Last edited by mattmc; 03-29-2010, 06:49 PM.


      • #4
        Robert, tunnel.c is an excellent place for you to start. From tunnel.c you can learn how to pro grammatically set the baud rate (and other serial settings) and disable the standard tunneling protocol.

        As far as communicating with the Java Applet, that is the easy part. Both tunnel.c and the standard tunneling protocol use basic TCP sockets. All you need to do is open a socket to the designated port and any data you transmit gets passed directly to the PIC.

        There is one caveat: because the Java applet runs on the client it needs to know the IP address to connect to. I do this using a CGI page that passes parameters to the Java page. Getting the IP address involves reading the XML configuration.

        I can post some example code if you want but there are examples all throughout the forum on getting the current IP address from XML and the cgi is pretty straight forward.



        • #5
          Example CGI Code

          Thanks for the insightful responses, guys! Definitely enough to get me started.

          Actually, I have the Matchport configured with a static IP address, so can I assume I do not need to read the XML configuration?

          If it's not too much trouble, could I take you up on the example CGI code offer? I've yet to do any CGI and I'd like to see the general flow as well as how it is incorporated in the Java code. Naturally, I'll be doing my own research and trial in parallel, but I'd like to see how a pro such as yourself gets the job done

          Thanks again, everyone!


          • #6
            Here is the CGI code that I use. My applet is complied into a jar file. As I mentioned before, I have a seperate function to grab the current IP address from the XML but if you have static IP's then you could hardcode, especially for testing.

            	HttpWriteData(httpClient, "<applet code=\"myapp.class\" archive=\"MyAppJar.jar\" width=\"765\" height=\"540\">\n");
            	HttpWriteData(httpClient,"<param name=\"ip_addr\" value=\"");
            	WriteIPAddressInHTML(httpClient); //writes my ip address to the httpClient
            	HttpWriteData(httpClient,"<param name=\"ip_port\" value=\"");
            	ip_port = SDK_NETPORT;
            	snprintf(tmp_array, sizeof(tmp_array), "%u\"/>\n", ip_port);
            	HttpWriteData(httpClient, tmp_array);
            	HttpWriteData(httpClient, "</applet></body>\n");
            	HttpWriteData(httpClient, "");


            • #7
              CGI Code

              Hi All,
              I was wondering if someone could give me a quick overview of the CGI structure--what files go where on the Matchport b/g Pro and how I send specific data bidirectionally to/from the client applet. I've been able to serve up my applet (consolidated into a JAR file) in an HTML format successfully, so would this CGI route simply take the place of this set of files?

              Thanks for the code, joshjack I think I'm struggling with the larger picture of how I would go about sending a specific set of variables bidirectionally using this method (between my PIC and the client applet). Would it be possible to code a Java tunneling program built into the applet itself?...recalling that the Matchport does have a static IP, is this even remotely viable?

              Once again, I apologize for my much more firmware-centric knowledge base!

              Thanks everyone


              • #8
                I have in the past used a Java applet to send data via TCP and UDP sockets to an XPORT version 3. I believe the concept is the same for Matchport.

                I create a Java applet that opens either a UDP or TCP/IP socket to the IP Address of Lantronix device. I believe I used a call like GetCodeBase or something like that to retrieve the IP address of the Lantronix device that is serving the applet.

                Then on the device side I create either a UDP socket or a passive TCP/IP socket to receive and send data to the applet on request. It is in these routines that I pass data back and forth to the serial port. There used to be a Cobox example of a temperature control that explained this very well.

                Using Netbeans may help speed up the development because you can actually connect to the device from within the IDE without having to upload your applet to device. Instead of using "GetCodeBase" function define the static ip address to connect to when you debug. Then change back to GetCodeBase when you are ready to deploy and update the device with applet and HTML files.


                • #9
                  Ok, the CGI that I gave you was to generate the IP address and include it in the HTML launch page for the Java applet. That way you can pass it in as a parameter. If you want to hardcode a static IP then you DO NOT NEED CGI at all. You just need raw html to launch the applet.

                  Tunneling is just a simple TCP socket, very easy to do in Java. Just connect to the tunneling port on the device server and transmit/receive your data.


                  • #10
                    Thanks for the clarification I've been picking away at the matchport side of my hardware waiting for other components to fall into place, but I have a seemingly basic question about uploading applications to the Matchport b/g Pro...

                    Does uploading application firmware (such as tunnel.c as is) overwrite the configuration data, reverting any modified settings to default? I would especially not want the wireless/network settings to be reverted after an upload? I have backed up the XML configuration data in any case. If this configuration setting reversion does occur during a firmware upload, is there any way to compile the project with the proper configuration data included?

                    Thanks again for all of your help!

                    Best regards,


                    • #11

                      Upgrade is without loss of configuration data if the original and new IMAGE_PARTITION_SIZE_BYTES match. When the IMAGE_PARTITION_SIZE_BYTES changes, the file system must be reorganized, and this can lead to loss of configuration data.

                      The MatchPort-bg-Pro firmware sets IMAGE_PARTITION_SIZE_BYTES to 1572000.
                      The MatchPort-AR sets IMAGE_PARTITION_SIZE_BYTES to 786000.
                      When you build your code, you specify your own IMAGE_PARTITION_SIZE_BYTES.

                      When an upgrade takes place and the original and new sizes match, there will be no loss of data.

                      When an upgrade takes place and the original and new sizes do not match, the position of Bank A and Bank B on the file system change, and Flash is reorganized. In this scenario it is easier to loose the configuration. To avoid loss, perform a "compact" before the upgrade--this will place the current configuration in both Bank A and in Bank B. Also, be aware that the flash reorganization takes some time, and do not kill the power while it is happening.

                      You could choose your value of IMAGE_PARTITION_SIZE_BYTES to match one of the sizes above to avoid this reorganization when you upgrade from the Lantronix image to yours. Or you might choose your value of IMAGE_PARTITION_SIZE_BYTES so as to allow your application suitable room to grow after you release it to the field and maintain it.


                      • #12
                        While network configurations probably don't fit into this category, application specific configurations that won't change (such as serial port settings) can be set in your program during bootup. This way you're guaranteed to have the right settings everytime the device boots regardless of whether the configuration got overwritten.