Messages

31

NXP^TM M522XX, KINETIS and i.MX RT / OUR_HEAP_SIZE increments

« on: July 12, 2010, 10:00:07 PM »

Mark,

My project has run to the limits of the chip I'm using, and I ran out of stack space.  After a lot of squeezing here and there, I changed the OUR_HEAP_SIZE define.

Code: [Select]

#define OUR_HEAP_SIZE (HEAP_REQUIREMENTS)((22*1024)*MEM_FACTOR)
to

Code: [Select]

#define OUR_HEAP_SIZE (HEAP_REQUIREMENTS)((43*512)*MEM_FACTOR)

I don't know enough about the memory structure to know if this is an issue or not.  Things seem to be working for now.
HEAP   Free 0x0194 from 0x5600
STACK   Unused 0x00d7
Prior to the heap change, I had no stack left. 

What are your thoughts on changing from 1024 to 512? 
Thanks,
Aaron

32

NXP^TM M522XX, KINETIS and i.MX RT / Re: fnRandom() not changing

« on: July 02, 2010, 06:44:09 PM »

Mark,

The sequence generated by the algorithm works great, however the seed value is very consistent.  The random pointer ptrSeed, is always the same value (0) and therefore fnInitialiseRND() returns 0x127b.
This may have to do with the compactness of my project, and not touching the memory space that the pointer is getting assigned to.

Have you or anyone else played with using network data to get a more randomized seed?  Or some other method? 

Thanks,
Aaron

33

µTasker general / dhcp and DNS search order

« on: June 21, 2010, 06:39:44 PM »

Now that our product is out in "the wild" we've found that a fair amount of dhcp servers are giving "bogus" DNS server information.  After poking around in the utasker code, I found that fnReadDHCP_IP() is setup to return the last IP of possibly multiple DNS server IP addresses.

Example option 6 response:
IP Address: 2.2.2.2
IP Address: 3.3.3.3
IP Address: 192.168.10.2
IP Address: 192.168.10.1
fnReadDHCP_IP() will return 192.168.10.1.

Is there a reason to use the last IP given, as opposed to the first one?
Please ignore the actual values of of the first two IPs, this is my testing of what to do when we receive bad DNS values.

Thanks,
Aaron

EDIT:
I've made the following change to fnReadDHCP_IP(), and so far so good.

Code: [Select]

//unsigned char *ptr = (*data + ucMsgLength - IPV4_LENGTH + 1);
unsigned char *ptr = (*data + 1);But I'm not an Ethernet expert.  Are there times when this could cause problems for the other IPs that are passed in?

34

µTasker general / dhcp client ID

« on: May 13, 2010, 10:37:17 PM »

Has anyone tried putting in a client ID string into the dhcp request?  Any issues doing this?
Also looking at the existing dhcp structures, it looks like it would need to be added, in order to use it.
Suggestions?

Thanks,
Aaron

35

µTasker general / Re: Visual Studio C++ Express 2010

« on: April 29, 2010, 04:30:11 PM »

Thanks Mark, I think you pointed out the most important reason for supporting it (2008 no long being available).

Aaron 

36

µTasker general / Re: Visual Studio C++ Express 2010

« on: April 29, 2010, 04:18:46 PM »

Are there any notable improvements from 2008 to 2010, as it pertains to the uTasker project?  Or is this just another upgrade from MS, that isn't super relevant?

37

µTasker general / Re: DNS bug when using the final '.' notation

« on: April 12, 2010, 09:12:12 PM »

I was looking for the RFC, that talks about this specifically, but the end dot is indeed legal.  It means, don't try to append anything to this while looking it up.  It allows for people to do a local look up, without having to enter the fully qualified domain name.  eg. "server1", instead of "server1.utasker.com", but of course, then what to do with someone who does enter the full domain name?  Well just add another dot, eg "server1.utasker.com." and the system won't append to it.
I think it's probably old and antiquated, but our new programmer formerly from Cisco told me about it while we were trying to figure out why our device (using utasker) wouldn't resolve DNS on a customers network.  When we tried it, it hosed the thing.

Aaron

38

µTasker general / DNS bug when using the final '.' notation

« on: April 12, 2010, 06:36:08 PM »

Mark,

In fnResolveHostName() if the cHostNamePtr ends with a '.' eg. "www.google.com."  Then the string parsing fails, and DNS is left in the BUSY state, without ever having sent a UPD packet, nor triggering the timer to allow the task to complete or fail.

Below is my simple, but code bloated way of fixing it.  If you have a more elegant method, that would be welcomed.

Code: [Select]

if ((*cHostNamePtr) == '.') {                                    // still not at the end, skip dot
            cHostNamePtr++;
if ((*cHostNamePtr) == '\0') {                               // add ZERO, QTYPE and QCLASS
                uMemcpy(ucBuf, ucZeroQTypeClass, sizeof(ucZeroQTypeClass));
                uTaskerMonoTimer( OWN_TASK, DNS_RESEND_PERIOD, E_DNS_RESEND ); // monitor resolution
                                                                         // send the request
                fnSendUDP(DNSSocketNr, ucDNS_server_temp_ip, DNS_UDP_PORT, (unsigned char *)&UDP_Message.tUDP_Header, (unsigned short)(usTotal + 13 + sizeof(ucZeroQTypeClass)), TASK_DNS);
            }
        }
        else {
            if ((*cHostNamePtr) == '\0') {                               // add ZERO, QTYPE and QCLASS
                uMemcpy(ucBuf, ucZeroQTypeClass, sizeof(ucZeroQTypeClass));
                uTaskerMonoTimer( OWN_TASK, DNS_RESEND_PERIOD, E_DNS_RESEND ); // monitor resolution
                                                                         // send the request
                fnSendUDP(DNSSocketNr, ucDNS_server_temp_ip, DNS_UDP_PORT, (unsigned char *)&UDP_Message.tUDP_Header, (unsigned short)(usTotal + 13 + sizeof(ucZeroQTypeClass)), TASK_DNS);
            }
        }
Aaron

39

µTasker general / Using the queue system that's already in place

« on: April 08, 2010, 07:45:56 PM »

Rather than make my own fifo system for some data, I'd like to leverage the queue system that is already in place.
Has anyone done this?  If so can you provide some guidance?
I know I need to add 1 to PHYSICAL_QUEUES, but after that I get lost.

Thanks,
Aaron

40

µTasker general / Re: SNMPV2

« on: March 16, 2010, 10:03:30 PM »

Any baseline parameters on code space and memory requirements for the SNMP code?

Thanks,
Aaron

41

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

« on: March 16, 2010, 10:01:24 PM »

It looks like it's just a trade off of one set of compiler problems for another.  Going from 7.1.1a to 7.2.
7.2 did shave off 4k, but in quick tests it had issues with some of the saved parameters.

But 7.1.1a has it's own issues.  Below, in this function I had to move a text string into a buffer to send it, otherwise CW would optimize it out.  I even tried turning off optimizations, to no avail.
Oh well.

Code: [Select]

static void fnDNSListner(unsigned char ucEvent, unsigned char *ptrIP){
CHAR cBuf[16];
    switch (ucEvent) {
case DNS_EVENT_SUCCESS:
uStrcpy(cBuf, "DNS answer: ");
fnDebugMsg(cBuf);
//fnDebugMsg("DNS answer: ");  //code warror optimizes this line away
fnIPStr(ptrIP, cBuf);
fnDebugMsg(cBuf);
fnDebugMsg("\r\n");
//uMemcpy(ip_sockets.ip, ptrIP, IPV4_LENGTH);                      // save the IP address which has just been resolved
break;
default:                                                             // DNS error message
break;
    }
}
Aaron

42

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

« on: February 23, 2010, 05:39:19 PM »

Has anyone tried out the new code warrior 7.2?  Is it good to use, or should it be avoided?

Aaron

43

µTasker general / DHCP and the BROADCAST_FLAG

« on: January 22, 2010, 01:26:26 AM »

Mark,

I was pointed to these articles by a co-worker:
http://support.microsoft.com/kb/928233 and
http://smallvoid.com/article/vista-dhcp-client-broadcast.html

I've found that embedded routers do not always fully comply with the DHCP standard (or DNS).
Looking through the uTasker code, it looks like the BROADCAST_FLAG is being set in the DHCP header cRequestHeader.

Have you run into any compatibility issues with this bit being set (or not being set)?
We haven't yet, but would like to know in advance if it could be a problem.

Thanks,
Aaron

44

µTasker general / certain routers not working...even with simulator

« on: December 23, 2009, 04:30:40 AM »

Mark,

I've have two routers so far with this issue, one was a Belkin and the other is a 2wire 2700HG-B.  Something in the uTasker isn't working with them.
The Belkin we updated the firmware and it started working with the uTasker project.  The 2wire already has the latest firmware and it is a very prevalent brand here in the US. 
The issue is duplicatable in the simulator as well.  In the simulator the link and activity lights never blink.

There is an interrupt every once in a while which triggers fnNetworkIndicator() and it hits both ACTIVITY_LED_ON() and TURN_LINK_LED_ON() and it never hits LINK_DOWN_LEDS().
The heartbeat works fine on PORT TC bit 0.

There are never any DHCP requests sent out on wireshark, even though the code is going through fnSendDHCP().  It's very bizzar to me.
I have the network settings set to 100MB.

Any ideas?

Thanks,
Aaron

45

µTasker general / Re: why are the packets only 128 bytes long?

« on: December 18, 2009, 11:09:11 PM »

Thanks Mark!
I had TX_BUFFER_SIZE in there for that parameter, which is 256.
I've change it to 0.

Aaron