Messages

16

µTasker general / Re: TFTP Bootloader

« on: May 18, 2010, 04:30:48 PM »

Thanks Mark,

I agree that TFTP can be a hassle, most systems don't even have a client.  Interestingly the Luminary (TI) StellarisWare provided software includes a bootloader with BOOTP/TFTP support, but this requires their special software running on the host PC.  I agree that HTTP Post is a better method.  I might need to utilize an external Flash to maximize the code space for the firmware....

What do you think the smallest basic implementation of bootloader with HTTP server only would cost in terms of code size.  Again, a larger bootloader may be a good compromise so that we can utilize more flash space, and not worry about having to leave room for the uploaded image. 

That is: in this implementation, the bootloader could program the flash on the fly (while it is being downloaded).  If the download fails, the bootloader (with HTTP server) is always there, and a retry can occur.

17

µTasker general / TFTP Bootloader

« on: May 17, 2010, 08:53:25 PM »

The Bootloader document states that TFTP may be added in the future.  I'm wondering if there is any progress on this?  I realize that there may be a code penalty, and some other disadvantages.

18

µTasker general / Starting a new project

« on: May 12, 2010, 10:03:05 PM »

Mark,

I've been on and off from uTasker for the last couple of months (how time flies!).  In any case, in the past, I have been using the demo application as a base point for my intended application.  It has come time to clean things up and create a new project based on my experiments.  I still think that your framework is a good starting point, but I would like some pointers as to how to proceed:

1) Should I keep the application.c, or start from scratch?
2) What is the best way to prevent the Debug messages from going to the telnet console (or serial for that matter).  I would like to use the telnet console for configuration of the device, and the debug messages get in the way (there are a lot of debug messages for Modbus communications).

I will most likely have more questions, but figure they are generic enough that other users may benefit.

19

µTasker general / Re: HTTP Authentication

« on: January 21, 2010, 11:02:18 PM »

Hi Mark,
In my attempt to start implementing this, I've been also educating myself on how webInterface.c works.  Although I know that this is an "example", it serves as a good template/start point for many web applications.

I've appended the fnHandleWeb functionality to the fnInsertString document I sent you a while back, I can upload this somewhere if you'd like.

Regarding the authentication, my thought process would be as follows:

1) If VARIABLE_PAGE_AUTHENTICATION is set, call fnHandleWeb with ucType set to 0x01 (or user defined)
2) fnHandleWeb (upon seeing ucType as 0x01), checks to see if the file is of HTML type.  If so, it looks at the FIRST byte of the file.  If this byte is set to £ (web delimiter), then read the NEXT byte (should be between 0-9).
3) The byte would symbolize a "security" level required for viewing of the page.
4) If the current session "security level" is equal to or greater than the page required security level, then return APP_ACCEPT, otherwise return APP_REQUEST_AUTHENTICATION

This scheme requires a new "global" variable for security level of the current session.  Default security level would be "0", and other security levels could be assigned based on a user list (the creation/maintenance of the user list is another subject).

If this is available, it would be prudent to add a fnInsertString function to output the current security level, such that the pages could be dynamically created based on the current session "security" level.  That is, a javascript or similar client side variable could display/hide links based on the current level.

I'm "thinking out load" with this for the moment...I prefer to bounce some ideas before I go too far.  If you see any problems with this, let me know.  Also, if you have a different implementation in mind, please let me know, so I don't re-invent the wheel.

20

µTasker general / Re: HTTP Authentication

« on: January 20, 2010, 11:07:34 PM »

Hi Mark,
Forgive me, but to fully implement the VARIABLE_PAGE_AUTHENTICATION, does a new case need to be added to fnHandleWeb() to handle the check of the page?  I don't see any cases that match the 0x01 ucType setting.

Therefore, the pseudo code would be:

Code: [Select]

#define VARIABLE_PAGE_AUTHENTICATION
...
    if (fnHandleWeb(0x01, (CHAR *)ptrptrFile, http_session) != APP_ACCEPT) { // check whether this page is protected
...
within fnHandleWeb():

Code: [Select]

switch ucType:
...
...
  case 0x01:
    <if file_MIME_type=HTML then>
      <if file is "protected"> return APP_REQUEST_AUTHENTICATION
       else return APP_ACCEPT   
    break;
...


21

µTasker general / Re: HTTP Authentication

« on: January 20, 2010, 09:17:37 PM »

I'm going to be looking into this a little more closely over the next little while, and potentially investigate other authentication methods.  I did notice that the current authentication method asks for credentials only if the "root" ie "/" page is accessed.

That is, if the user directs their browser directly to the "Kadmin.htm" page, they can specifically disable HTTP authentication and continue on to any page (including "/") without credentials.

Moreover, this HTTP Authentication method has not server controlled means of initiating a logout, so for sensitive applications, this may not be a good method.

How have other users tackled this issue?  It may not be a big deal for us at the moment, but that may change shortly.

22

µTasker general / Re: HTTP Authentication

« on: January 20, 2010, 05:36:49 PM »

Hi Mark,

Once again, thanks for the quick reply.  I started browsing the code, and your summary will be a big help in this.  Do you think it would make any sense to include in the web page some sort of "server side" variable that would define which users had access to it?  This way, the pages could be protected via an "access level" (and therefore more generic implementation) rather than having to create a static list (or algorithm).

For example, if we used one of the web delimiters "£", with a "security level" associated with it as the first bytes in the HTML file (or some implementation like this), then the algorithm could check this against the current user's security level. Although I guess this wouldn't work well for binary data (images, etc)....which might be an acceptable limitation.

I'm not familiar with HTTP Authentication methods, but is the username / password sent with every HTTP request?  Who decides how long this data is good for (server or browser?), and do we have to mess with cookies, etc?

I will try to educate myself on this regard, but if anyone has any other input, I'd appreciate it.

23

µTasker general / HTTP Authentication

« on: January 19, 2010, 10:04:53 PM »

Is it possible to have multiple users and/or passwords for the HTTP server.  That is, to have one password make visible one set of pages (ie: setup, config, debug, etc), and the other for regular "data" pages.

24

µTasker general / Re: Feature suggestion: HTTP Response Header

« on: December 22, 2009, 12:08:23 AM »

Sorry to dig up this old post, but I was having the same issues.  Chrome and FF worked OK, but IE kept dying on me.  Turns out that IE absolutely REQUIRES that the Content-Type be set for XML, and there is no way to fix this on the client side.  Chrome and FF look for the MIME type, but fall back to the file extension, IE just dies without it.

Anyways, I followed mcosta's suggestion, but also had to add a section where the content type was to be written to the client.

I created a new MIME type in config.h, and added the following lines to http.c:

(line number approx 379)

Code: [Select]

#ifdef SUPPORT_CHROME        // {34}
  if (http_session->ucMimeType == MIME_XML) //PCK 12/21/2009 -- added XML type
    uMemcpy(HTTP_Tx->ucTCP_Message, cucXML_header, SIMPLE_XML_HEADER_LENGTH); // copy the XML header
  else
    uMemcpy(HTTP_Tx->ucTCP_Message, cucHTTP_header, SIMPLE_HTTP_HEADER_LENGTH); // copy the HTTP header to start of each file to be transferred

  fnGetParsFile(http_session->ptrFileStart, (HTTP_Tx->ucTCP_Message + SIMPLE_HTTP_HEADER_LENGTH), (usLen - SIMPLE_HTTP_HEADER_LENGTH)); // get a frame to send
  http_session->ptrFileStart -= SIMPLE_HTTP_HEADER_LENGTH;             // offset for the added header
#else

and

(line number approx 911)

Code: [Select]

#ifdef SUPPORT_CHROME                                                    // {34}
  if (http_session->FilePoint == 0)                   // regeneration of first frame needs to be handled differently to insert the HTTP header
  {
    if (http_session->ucMimeType == MIME_XML) //PCK 12/21/2009 -- added XML type
      uMemcpy(HTTP_Tx->ucTCP_Message, cucXML_header, SIMPLE_XML_HEADER_LENGTH); // copy the XML header
    else
      uMemcpy(HTTP_Tx->ucTCP_Message, cucHTTP_header, SIMPLE_HTTP_HEADER_LENGTH); // copy the HTTP header to start of each file to be transferred
     
    fnGetParsFile((http_session->ptrFileStart + SIMPLE_HTTP_HEADER_LENGTH), (HTTP_Tx->ucTCP_Message + SIMPLE_HTTP_HEADER_LENGTH), (Len - SIMPLE_HTTP_HEADER_LENGTH)); // get a frame to send
  }
  else {
    fnGetParsFile((http_session->ptrFileStart + http_session->FilePoint), HTTP_Tx->ucTCP_Message, Len);
  }
#else

Just do a search on the two places the cucHTTP_header is used, and add/replace the code with the above.

Mark, perhaps it would be better to create a "generic" Content-Type handler???

25

µTasker general / Re: Finding device with DHCP IP address

« on: December 10, 2009, 11:15:36 PM »

As a small update, I have done some more research into this topic.  It looks like the Luminary Micro implementation requires that the "target" is running a "locator" process.  This is actually included in the /StellarisWare/utils directory as source.  Then the "finder" application appears to send a broadcast query and looks for a response from this process.

This method works well, but seems to be overkill if you can use NETBIOS.  In that case, its as simple as setting it up in uTasker and typing "ping (whatever)", where that is the name you specified.  The ping command will resolve the netbios name to an IP address and display the results.

The trick with the Luminary approach is that the device MUST be on the same subnet.  If it doesn't successfully obtain an address (or uses AUTOIP to grab a "default" address), this method won't work.

The Lantronix utility is somehow able to find a device even if it hasn't obtained an IP.....

26

µTasker general / Re: Finding device with DHCP IP address

« on: November 30, 2009, 10:27:50 PM »

No, the Lantronix software finds *any* Lantronix module.  I think it may look for any device that has its own vendor specific MAC address start.  You don't need to know anything about the module, it just has to be (physically) on the same subnet.

Incidentally, I recently found that Luminary Micro has an identical utility for finding the IP address of its boards on the network.  Its called "finder" and its included in the StellarisWare package (with source code).  I have to take a closer look, but it looks like it uses some sort of custom "protocol" to sniff out modules that are on the network.  Again, there may be a presumption that the MAC address is specific to the vendor.

27

Luminary Micro ^TM LM3SXXXX / CS GCC Lite vs Yagarto

« on: November 24, 2009, 03:12:53 AM »

I'd been having issues with CS GCC Lite, and decided to give Yagarto a whirl.  As it turns out, Yagarto wasn't any better (actually, it was worse!).  After fighting with it for some time, I was able to finally adjust the .ld script for both CS GCC and Yagarto to work.  I made separate batch files for both, so I could compile the same code using either one.

I found that the Yagarto toolchain is significantly worse with regards to code density.  In all fairness, I'm not sure if I had all the optimization settings set properly (ie: I took Mark's makefile and ld script from the GNU directory and modified them for Yagarto to work.  Here are some notes, in case anyone else is interested:

Yagarto:
1) You should add "-mfpu=vfp" to the CFLAGS section in the makefile.  Otherwise you'll get errors regarding "VFD instructions"
2) Make sure you update the makefile with the name of the new .ld file that you create (in case you aren't editing the existing one)
3) Any changes to the xxxx.ld file should be mirrored in the xxxx_BM.ld file
4) Add the following section to the xxxx.ld file(s).  It should go right after the "vectors_ram" section:

Code: [Select]

  __eh_frame_ram_start__ = ALIGN(__vectors_ram_end__, 4);
  .eh_frame ALIGN(__vectors_ram_end__, 4):
  {
     KEEP(*(.eh_frame));
  }
  __eh_frame_ram_end__ = __eh_frame_ram_start__ + SIZEOF(.eh_frame);

  . = ASSERT(__eh_frame_ram_end__ >= __SRAM_segment_start__ && __eh_frame_ram_end__ <= (__SRAM_segment_start__ + 0x00010000) , "error: .eh_frame is too large to fit in SRAM memory segment");

CS
1) if linking any routines from libc, you'll probably get errors about the section ".ARM.exidx" overlapping with vectors.  I think this is because libc requires this section (apparently, it's for exceptions).  You'll have to add it to the xxxx.ld file (after .ctors, before .rodata) section as follows:

Code: [Select]

/* .ARM.exidx is sorted, so has to go in its own output section. */

  __exidx_start = ALIGN(__ctors_end__, 4 );

  .ARM.exidx ALIGN(__ctors_end__, 4) :
  {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  }
  __exidx_end = __exidx_start + SIZEOF(.ARM.exidx);

With these changes I was able to compile the same snippet of code....(although Yagarto puked when I tried to use the ctime function because of unresolved references to a bunch of system calls....I suspect I'd have to play more with syscalls.c and include it).

Anyways, on a rather hacked up piece of code (not using any libc functions), these are the results I got:

Yagarto:

Code: [Select]

   text    data     bss     dec     hex filename
  68780     107     972   69859   110e3 uTaskerV1.4.elf
CS GCC Lite:

Code: [Select]

   text    data     bss     dec     hex filename
  57552     107     976   58635    e50b uTaskerV1.4.elf
As you can see, there is > 10k difference!  After seeing this, and after Yagarto died totally with the ctime() function (I *did* manage for CS GCC Lite to compile it), I think I'll stick with CS for the moment.

28

µTasker general / Re: Date keeping & routines

« on: November 22, 2009, 01:19:04 AM »

Slight followup: I found the ctime function which looks to do what I need.  It assumes a time in the "UNIX-time" format (seconds relative to 1/1/1970), so I just adjusted the time from the server by 2,208,988,800 s (seconds between 1/1/1900 and 1/1/1970).  This works in the simulator.

HOWEVER, trying to compile this for the LM3S6965 fails.  It looks like any time I try to add any libc functions, the linker attempts to add a section called ".ARM.exidx" at the start of the code, which overlaps with ".vectors".

I'm using CodeSourcery GCC Lite 4.4.1.

29

µTasker general / Date keeping & routines

« on: November 22, 2009, 12:27:37 AM »

I noticed that the uTasker demo can use a TIME server to get the 32-bit seconds from 0:0:0 1900 time format.  I see that when the TIME server returns the value, it is converted to the present time (by subtracting 9/1/2007, and then 24-h increments).

Are there any routines to use this 32-bit datecode as an actual date?  I do realize that the conversion routines would be significantly more complex (days, months, years, leap year), but I'd like to implement date keeping on-board for data logging purposes.  The system could sync itself to the time server every couple of hours.  I'd prefer a software solution than an external DS1307 type solution.

Regards,
Paul

30

µTasker general / Re: Finding device with DHCP IP address

« on: November 20, 2009, 04:17:06 AM »

Richard,

I'm also interested in this.  You may need to look into UPnP, as I believe it will allow you to talk to the router and haveit to open certain ports for you.  From the outside world, if you know the address of the router (via a dynamic DNS setup), and a unique port, you won't need to know the IP address of the internal client.

I've also wondered how device discovery works, for example the "Detector" utility from Lantronix.  It is designed specifically for this purpose: ie: the Lantronix modules use DHCP (or sometimes not even), but can still be detected (and in fact configured) via this utility.  I guess somehow it talks via the MAC address, and bypasses TCP until the device has an actual address.

Let us know if you get anywhere with this, and I will do likewise, as for devices without a display, having a "detect" utility would be important (although NetBIOS may be a nice compromise).