Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Re: Codewarrior 7.1.2 optimisation problem

« on: March 26, 2010, 02:33:18 AM »

I just noticed some other distressing behavior related to Codewarrior 7.1.2.  Note the simple 'if' expression on the third line here. Using CW 6.3 and 7.1 (as well as the simulator), the expression evaluates correctly. But under CW 7.1.2, it always evaluates to false. Using 'and' instead of 'or' in the expression works fine. This problem happens with any level of optimization other than none.

Code: [Select]

if(!uStrncasecmp(p, "z1", 2)) {
   type = *(p+1) - 0x30;
   if((type == 1) || (type == 2))
       uPrintf("(%d == 1) || (%d == 2) is true\r\n", type, type);
   else
       uPrintf("(%d == 1) || (%d == 2) is false\r\n", type, type);
   if((type >= 1) && (type <= 2))
       uPrintf("(%d >= 1) && (%d <= 2) is true\r\n", type, type);
   else
       uPrintf("(%d >= 1) || (%d <= 2) is false\r\n", type, type);
 }

Simulator output:
(1 == 1) || (1 == 2) is true
(1 >= 1) && (1 <= 2) is true

Target output:
(1 == 1) || (1 == 2) is false
(1 >= 1) && (1 <= 2) is true

2

µTasker general / Re: Text File EOLs Messed Up in IE Only

« on: October 20, 2009, 03:40:54 AM »

Hi Mark,

Sure, that change looks good to me!

Dan

3

µTasker general / Re: Text File EOLs Messed Up in IE Only

« on: October 16, 2009, 07:35:17 PM »

Hi Mark,

Yes, I did implement a solution yesterday, and it seemed to solve the problem, but I hadn't quite finished testing it. But today I went ahead with your solution instead (which of course is very similar, as the changes and locations are pretty obvious), and that also seems to work fine. There is one thing, which is that because of the way the download link is implemented (and I can't really remember the details on that), I have to enable web parsing on text files (in addition to my other content that actually does need parsing, which is html and javascript files). This doesn't seem to affect performance in a noticeable way, and shouldn't be a problem since the WEB_PARSER_START character should never appear in the text file.

So I am good to go on this. Many thanks for your (usual) rapid support on this!

Dan

4

µTasker general / Re: Text File EOLs Messed Up in IE Only

« on: October 15, 2009, 11:45:25 PM »

Hi Mark (and 'dkg'),

Thanks for the quick responses. You're absolutely right, IE seems to need the content type to be specified. I changed that header define as you suggested, then tried it with IE, and everything was beautiful for both HTML pages and the text file. Naturally though, when I tried an HTML page in Firefox it showed me the raw HTML. Grrr....

So I think you're right, Mark, there needs to be some way to select the header based on content type.

Thanks,

Dan

5

µTasker general / Text File EOLs Messed Up in IE Only

« on: October 15, 2009, 10:38:39 PM »

Our product has a method for a user to download a bunch of settings via a link on a web page. The settings are presented as a text file with CRLF line endings, where each line is a separate setting.

This works just fine in Firefox, Safari, and Chrome; if you left-click on the link, the text file opens in the browser and is totally legible, and if you right-click the link and choose "Save File as..." or equivalent, the default name for the file is "settings.txt" as intended.

However, with any version of Internet Explorer, left-clicking the link opens the text file in the browser but the line endings are all messed up; it appears that the CRLFs are stripped out. I believe the browser is interpreting the file as HTML instead of text, even though the URL ends with "settings.txt". Also, right-clicking the link and choosing "Save Target as..." offers the default file name "settings.htm". Whether you save the file with the offered extension "htm" or change it to "txt", the file content ends up correct, with CRLF line endings.

Of course if you look at the file going across the network with a sniffer, the content is the same regardless of browser, and always has CRLF line endings.

Does anyone know of a way to make this file look like a text file to Internet Explorer, as it does to the other browsers?

Thanks,

Dan

6

µTasker general / Re: File upload using cURL

« on: February 02, 2009, 06:50:36 AM »

Hi Mark,

I tried the new stuff with cURL and it seems to work fine. I'll try to test it more extensively in the next few days, and I will also try the capability to post parameters over multiple frames (since a need recently came up for that).

Thanks for your efforts!

Dan

7

µTasker general / Re: File upload using cURL

« on: January 20, 2009, 07:53:01 PM »

Hi Mark,

I am not having any luck with this yet. I've posted you some private email about it.

Thanks,

Dan

8

µTasker general / Re: File upload using cURL

« on: January 18, 2009, 12:55:42 AM »

Hi Mark,

1) There must be some cURL option to turn off that Expect100Continue thing, I'll look into that. But as you said, it goes ahead with the transfer after a couple seconds anyhow, so not a big deal.

2) The data file is exactly 70,000 bytes, and ends with \r\n. I've attached the original file for your reference. This data is just some test data so that the data content and boundaries are easily recognizable.

I started looking into cURL for testing, but if I can put my update file on the target using cURL, without having any web pages yet stored on the target, I can eliminate the need for the FTP server and save some resources. (My update file contains both the application code and the file system content.)

Here's where cURL lives:

http://curl.haxx.se/

You can build from source, or download binaries for just about any platform.

Thanks,

Dan

9

µTasker general / File upload using cURL

« on: January 17, 2009, 01:17:06 AM »

Hi Mark,

I am trying to get a file to upload to my target using cURL instead of a web browser. It seems to almost work; that is, the entire file is transferred, but the target does not seem to recognize this. I am using this command line:

curl -F datafile=@1000.dh 10.10.5.132/HS.bin

I've attached a 'good' Wireshark capture (successful upload from web browser), and a 'bad' Wireshark capture (unsuccessful upload using cURL).

Can you see what's wrong with this approach? (I do see the extra 'Expect: 100-continue' in the bad capture, but I don't know how this might affect things.)

Thanks,

Dan

10

µTasker general / Re: Lost Ethernet Frames - Collision?

« on: November 11, 2008, 12:07:12 AM »

Hi Mark,

Thanks for your usual fast response.

We are not using auto-negotiation mode because of that bug with the M5223x parts (we have lots of parts that do not have the fix, so we have to work around it). We added some code to periodicallly check for a link, and if not present, try setting up the link at 100m and then 10m. This code actually disables the duplex setting. However, the initial value used to initialize the ethernet driver has duplex enabled; so if the link is detected right away, the manual negotiation stuff doesn't kick in, and the link stays at full duplex. I changed that initial value to disable duplex, and now everything seems fine.

It is unlikely that any user will connect our unit to anything other than a network with multiple other hosts, so I think we should be OK just leaving duplex disabled.

Thanks,

Dan

11

µTasker general / Lost Ethernet Frames - Collision?

« on: November 10, 2008, 10:24:18 PM »

Hi Mark,

On my M52235 target, I have a task that sets up a listener on a UDP socket. When a particular sort of frame is received (a broadcast frame from a special utility), then the unit sends a response frame containing various data. This was implemented months ago, and has been working very reliably; the unit always responds very quickly to the broadcast frame.

Recently, and for the first time, I started running two of the targets side by side. At this point I noticed that when the units are both running, I usually don't see the response frames at all. By "usually" I mean that occasionally I do see the response frames; it's always both units, not just one or the other. I have some debug output that shows that the code that sends the response is always getting hit, whether I see the response frames on the network or not.

This is with both units connected to the same ethernet hub. I found that if I connect the units to separate hubs or switches, the problem is not seen. I suspect this is a collision issue. In fact I can see the "Collision" LED on my hub flash briefly each time. Probably when it works it's because one or both of the units lost the ARP entry of the host and had to re-ARP, thus changing the timing of things.

I could add some kind of random delay at the application level. But shouldn't the ethernet driver be handling that, if this is indeed a collision issue?

Thanks,

Dan

12

µTasker general / Re: http.c. Not parsing form posts correctly

« on: September 08, 2008, 06:51:16 PM »

Hi Mark,

For the record (even though I already privately posted you about this), this seems to work fine. I tried posting of parameters, but not file posting.

Thanks,

Dan

13

µTasker general / Re: http.c. Not parsing form posts correctly

« on: September 07, 2008, 02:28:29 AM »

Hi Mark,

Thanks - I'll just work on some other things until you have something ready.

Regards,

Dan

14

µTasker general / Re: http.c. Not parsing form posts correctly

« on: September 06, 2008, 01:58:35 AM »

Hi Mark,

I would also like to use HTTP POST and am having the same issue as Thomas. I have tried it using my own web page as well as Thomas's example, and basically the state never gets past HTTP_STATE_START_POST. All of the related items are defined in config.h, including SUPPORT_HTTP_POST_TO_APPLICATION and SUPPORT_POST_TEXT. My test is based on nearly unmodified uTasker 1.3 SP7.

You mentioned some changes to http.c and tcpip.h, but I don't see any notes about this in subsequent service packs (SP6 and SP7 for M5223x). Are there some simple changes I can make to support this?

Thanks,

Dan

15

µTasker general / Re: Simulator Stops Sending Serial Output

« on: August 04, 2008, 05:52:39 PM »

Hi Mark,

Yes, that all makes sense. Good point about the looping and essentially blocking other tasks. I could live with that since I am dumping debug stuff only during development, but it is a bit sloppy. I reworked my code to use the TX_FREE event as you suggested, and now everything is happy.

Thanks!

Dan