Topics

1

µTasker general / uTasker + Windows 7 64-bit + VC 2010

« on: January 28, 2011, 03:51:19 AM »

After a long hiatus, I'm trying to get back into the uTasker world.  I recently updated computers to Windows 7 64-bit, and had to make the switch to VC 2010.

After some turmoil, I got my project (previously working--modification of the example) to compile, but I can`t ping it, or access any web pages.  It appears to be grabbing the correct IP address, and it talks to the outside world (ie: grabs the TIME as per the example), but that`s it.

I saw this thread post (http://www.utasker.com/forum/index.php?topic=180.0), but I see that the code is already updated in ip.c

It appears that something is getting through to uTasker, since putting a breakpoint in fnHandleIP triggers when a PING is initiated from another PC.

2

µTasker general / fnDebugMsg and debug.c

« on: June 10, 2010, 04:35:41 PM »

Hi Mark,

I'm working on an embedded ethernet project and want to have a setup menu system via TELNET.  This is already done in the uTasker demo app and works well.  However, since you've used fnDebugMsg to display the menus, all of the debug messages from the other modules are coming through this interface (ie: Modbus communications messages, etc..)

What I'd like is to limit the TELNET communication to the menus only, or better yet, allow the user to set the "debug level" to define the amount of debug information they see.

However, modifying fnDebugMsg seems daunting since its in the driver.c file (which I would like to avoid changing), as well as all the instances of fnDebugMsg being used throughout the modules.

Do you have an idea of how to overcome this?  I was thinking of changing "debug.c" to "menu.c", and defining a custom print function within that file, and allow fnDebugMsg to write to the network port only if the debug level is set high enough.....

If you have a better implementation idea, please let me know.....

3

µTasker general / Parameter System

« on: May 26, 2010, 09:30:48 PM »

Hi Mark,

I need to modify the uParameterSystem for my project.  The parameter system is quite complex, and I've had some trouble getting familiar with the architecture.  I understand that there are essentially four locations for parameters: two in RAM (working and temporary) and two in FLASH (valid and swap). 

Here is my understanding, please correct me if I am wrong:  you can use the RAM-temp parameters to make changes, and then commit them to the RAM-working and/or FLASH-swap.  When the FLASH-swap are validated (in case of critical--ie: ethernet changes), they are moved to the FLASH-working section and deleted. 

Also, I'm a little confused on the valid / validated bytes at the beginning of the block(s).  ie: why would we have a valid+validated SWAP block? 

I read the uFileSystem document that talks about fnSaveNewPars, fnGetPar, fnSetPar and fnDelPar.

However, I also see that there are other functions that deal with the parameters not described in this document.  This includes:

fnGetOurParameters()
fnGetOurParameters_1()
fnGetEthernetPars()
fnRetreiveAllParameters()

At first glace, it appears there is some redundancy here, but I'm sure there is a reason???

4

Luminary Micro ^TM LM3SXXXX / Code Composer

« on: May 18, 2010, 06:14:35 PM »

Since the buyout by TI, it looks like they have made their Code Composer work for Stellaris.  Any feedback from users as to how Code Composer Studio compares to the other compilers?  I've been using the free command line G++ from CodeSourcery (mainly because the Simulator allows for a great IDE such as Visual Studio), however I've read that G++ isn't as efficient as others.

5

Luminary Micro ^TM LM3SXXXX / Linker Files

« on: May 18, 2010, 05:21:09 PM »

Mark,

For the LM project linker files, I noticed some differences between the regular one (1) and the _BM one (2).  Namely:

(1)  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
(2)  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x0003f000

(1)  SRAM (wx) : ORIGIN  = 0x20000000, LENGTH = 0x00010000
(2)  SRAM (wx)  : ORIGIN = 0x20000000, LENGTH = 0x00008000

(1)  __HEAPSIZE__ = 4097;
(2)  __HEAPSIZE__ = 0;

(1)  __FLASH_segment_start__ = 0x00000000;
(2)  __FLASH_segment_start__ = 0x00000800;

I understand the FLASH_segment_start, but I'm not sure why the FLASH, SRAM and HEAPSIZE variables are different.

Granted, I'm not an expert, but I just wanted to make sure this is correct.

6

Luminary Micro ^TM LM3SXXXX / Flash Protection

« on: May 18, 2010, 04:50:37 PM »

Hi Mark,

I read your post from some time ago regarding your initial experiments with the LM Flash system.  You mentioned that you hadn't worked with the protection mechanisms.  Has this changed at all?  We would like to do everything possible to protect our code, but also need bootloader capability.

A few interesting peices of information from the LM3S6965 datasheets:

(Table 8-1): With FMPPEn = 1 & FMPREn = 0:
"The block may be written, erased or executed, but not read.
This combination is unlikely to be used."

Isn't this exactly the protection level that we want?  Does this mean external (JTAG) reads, or internal (program) reads?

Also, you mentioned that the Protection bits are write-once, but the datasheet states:

"Once the register contents are commited, the FMPREx and FMPPEx registers can be restored to their factory default values by performing the sequence described in the section called “Recovering a "Locked" Device” on page 62. However, the USER_REGx and USER_DBG registers can never be restored to the factory default values."

There is a procedure to restore the registers to factory default (described on pp. 62), but I'm not sure if the LM Flash Programmer is capable of this, so I'm wary of trying it on my demo board.

Moreover, from my previous experiences (Atmel, PIC), the protection is set via programming, whereas here it appears that the code (bootloader??) needs to setup these bits.

Can anyone comment on their experiences with the Flash Protection.

7

µ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.

8

µ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.

9

µ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.

10

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.

11

µ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

12

Luminary Micro ^TM LM3SXXXX / Include files in .bin

« on: November 18, 2009, 03:49:43 PM »

Is there a way to generate a .bin file with the auxiliary files included inside it?  ie: I'd like to do my testing/debugging on the simulator, and upload files via FTP, etc. and then have the compiled output include all the htm/jpg/etc files that I've included.  This way I don't have to manually upload them later.

13

Luminary Micro ^TM LM3SXXXX / Simulator vs. GCC

« on: November 18, 2009, 03:45:40 PM »

I'm making progress in learning uTasker, but I'm having problems with the seemingly "simple" stuff.

I'm playing with dynamic web content (in terms of fnInsertString).  I took the advice to remove all the stuff from the sample fnInsertString function (webinterface.c) and start replacing it with what I need.  So far, I have the following:

Code: [Select]

if(!TxLength)  //simple string field
{
  switch(*ptrBuffer++)
  {
    case 'N':  //insert STRING
  uStrcpy(&cValue, "Test");
  *usLengthToSend=4;
  break;
case 'I':  
  *usLengthToSend=sprintf(&cValue, "%u", uTaskerSystemTick);
  break;
    default:
  *usLengthToSend=0;
  }


      return cValue;
}

I want the "£vI" directive to write the system tick value.  The above code works fine in the simulator, but when I try to compile it using GCC, it dies with a bunch of warnings and errors.  Specifically, it doesn't like the sprintf call.  Here are some of the warnings / errors:

Code: [Select]

C:\dev\uTasker\Applications\uTaskerV1.4\GNU_LM3SXXXX>cs-make -f make_uTaskerV1.4_GNU_LM3SXXXX all
arm-none-eabi-gcc -mcpu=cortex-m3 -mlittle-endian -mthumb -Wall -Wstrict-prototypes -I../../uTaskerV1.4 -D _GNU -D _LM3SXXXX -g -c -Os ../webInterface
.c -o Build/webInterface.o
../webInterface.c: In function 'fnInsertString':
../webInterface.c:646: warning: implicit declaration of function 'sprintf'
../webInterface.c:646: warning: incompatible implicit declaration of built-in function 'sprintf'
../webInterface.c:646: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'UTASK_TICK'
The warnings I generally understand, but where it dies is during linking I think, with the following:

Code: [Select]

arm-none-eabi-gcc -mcpu=cortex-m3 -mlittle-endian -mthumb -Wall -Wstrict-prototypes -I../../uTaskerV1.4 -D _GNU -D _LM3SXXXX -g -Os -Wl,-Map=uTaskerV1
.4.map --no-gc-sections -nostartfiles -TuTaskerLM3SXXXX.ld -o uTaskerV1.4.elf Build/application.o Build/debug.o Build/webInterface.o Build/KeyScan.o B
uild/CGLCD.o Build/OLED.o Build/LCD.o Build/NetworkIndicator.o Build/usb_application.o Build/LM3SXXXX.o Build/MODBUS.o Build/modbus_app.o Build/GLCD.o
 Build/eth_drv.o Build/Driver.o Build/uMalloc.o Build/uTasker.o Build/Tty_drv.o Build/iic_drv.o Build/USB_drv.o Build/uFile.o Build/Watchdog.o Build/G
lobalTimer.o Build/low_power.o Build/Ethernet.o Build/arp.o Build/dhcp.o Build/dns.o Build/ftp.o Build/http.o Build/icmp.o Build/ip_utils.o Build/ip.o
 Build/pop3.o Build/smtp.o Build/snmp.o Build/tcp.o Build/telnet.o Build/tftp.o Build/udp.o Build/webutils.o Build/NetBIOS.o
c:/dev/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld.exe: section .ARM.exidx loaded at [00000000,
00000007] overlaps section .vectors loaded at [00000000,00000007]
c:/dev/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/lib/thumb2\libc.a(lib_a-sbrkr.o): In function `_sbr
k_r':
sbrkr.c:(.text+0x12): undefined reference to `_sbrk'
collect2: ld returned 1 exit status
cs-make: *** [uTaskerV1.4.elf] Error 1
If I take out the sprintf, it works.

I have tried adding stdio.h to webinterface.c, but that didn't work.  So, can I use sprintf?  Is there a list of functions that I can/can't use?  Are all standard C functions ie: via (stdio, stdlib) supported?

My research on the internet tells me that sprintf probably uses malloc(), and malloc in turn calls this "_sbrk" function which doesn't exist. 

14

Luminary Micro ^TM LM3SXXXX / uTasker & LM parts

« on: November 13, 2009, 03:37:18 AM »

Just a quick question regarding how interchangeable the LM3Sxxxx parts are between each other.

I have a LM3s6965 dev board, but I'm trying to see which other chips within that similar family I can use.  Other than FLASH limitations, is it fairly straightforward to compile the same code over various chips?  ie: some chips have more than one SSI port, etc.....will it be fairly straight forward to compensate for this, and compile for these various chips if we move up/down in the family.

Basically, can the GNU compiler (and uTasker) work for all the 6000 series LM chips?

15

Luminary Micro ^TM LM3SXXXX / Timers

« on: November 06, 2009, 10:53:33 PM »

I'm trying to wrap my head around all this wonderful stuff, so I apologize if my question is dumb or easily answered.  I've been reading the uTasker documents including the timer document as it would relate to my project.

On top of adding web server, file system, etc connectivity, my project requires a highly accurate task to run at exact intervals.  In my previous implementation (without on operating system), I've used high priority interrupts.  Basically, I need a task to happen exacly 8192 times in 1 hour (3600s / 8192 = 439.453125 ms)....with as much accuracy as possible.  This task should fire and preempt anything else happening if possible.

Now, I know the LM6965 has 32-bit hardware timers, so presuming they count at 50Mhz (the LM6965 datasheet doesn't mention anything about pre-scalers for 32-bit timers??!?), it would yield a 0.02us period resolution.  If I'm doing my math right (and my assumptions are correct), this means that using a 32-bit timer, it could count to 85.899 seconds....so my requirement of 439ms would give me great resolution on top of adequate timer size.

Reading through the uTasker header files however appears that it only uses 16-bit timers.

Basically, I'm wondering if someone could kick me in the right direction:
a) Can uTasker use a dedicated 32-bit timer for high priority, high-resolution tasks?
b) Which documents should I digest to move in this direction?
c) Which header files and which defines are required for this to happen?