Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - thamanjd

Pages: [1] 2 3 4
It's been a while since i originally posted this one. It's also been a while since i implemented it. Everything went fine.  Thanks for all your helpful suggestions.

I ended up starting a DMA timer on tx register empty interrupt. It then checked
the txcomplete flag i think maybe every 1/10th bit time or something like that.

I looked at the automatic RTS but it didnt look like it was going to do exactly what i wanted. I'm happy using the DMA timer.

Not having dived comletely into Coldfire yet i was surprised to see while figuring out how to set up a DMA timer interrupt that you can change the priority of the DMA timer interrupt. Can you change the priority of all the interrupts?


I kept on with this, and kept copying the old elf files back into the \bin folder. The compiler displayed the error messages as long as the elf files were present. The problem then was that double clicking on the error message eventually stopped pointing to the correct line of code.

Once i'd eventually solved all the compile errors, it remained stable and the elf files do not disappear. Everytime i got a good compile i then put those elf files aside.

I don't know why it does it. Like i said i think i had so many compile errors, it just threw a wobbly. I'm porting code from NE64 so there's a bunch of stuff i've had to change.

I was going to experiment using MCF52235 UARTs with RS485 but have just discovered that the only transmit interrupt available is effectively Transmit Data Register Empty (TXRDY).

But for RS485 you need to know when it is safe to switch the transmit enable bit on the RS485 driver. That is, you need to know when the byte has completely finished transmitting, stop bit and all. It would have been nice for there to be a transmit complete (TXEMP) interrupt but this seems to be lacking in the UART module. I considered setting some routine/timer to check the TXEMP flag(after reception of TXRDY interrupt) but this solution isn't fast or elegant.

Is it just me or is the UART module in some (all?) of the MCF522xx devices a bit clunky?

ideas? at the moment i'm thinking i should look at some other micros but 128K program plus 128k flash storage is attractive in devices like the MCF52235.

John Dowdell

I suspect this problem is arising from something strange that i have modified in my code that the comiler is not handling very well.

When i compile, the errors message screen shows:
could not find or load the file "uTasker_full.elf" for target "M52235EVB_ROM" for project "uTaskerV1.3.mcp"

Has anyone come across this happening?
Is it not the compiler/linker that actually create the elf & map files?
The error screen doesn't give me any clues as to what it was that i did that stuffed it up.

I've found i think that the compiler error message screen shows me a bunch of errors i have to fix up but if i then press the make button again, that is when it shows no erros except for this missing elf file message

Before i started modding code, it wasn't happening. There were a bunch of compiler error messages but none of them were to do with missing elf files.

Any insights/comments are welcome

John Dowdell

µTasker general / Re: Finding device with DHCP IP address
« on: December 02, 2009, 01:38:23 PM »
Ive got the Lantronix tool. I might have the Luminary tool. If i think of it one day at work i'll run wireshark at the same time and see what happens.

MAC addresses are offered by IEEE in two ways. OUI and IAB.

With an OUI -Organisationally Unique Identifier you pay for the first three octets of a MAC. The organisation is then free to dole out their addresses using the last three octets.
Of course when the organisation runs out of OUIs they might buy another OUI or maybe if they think the MAC address is old enough - recycle it. I wonder what the expected use is?

With an IAB, if you don't think you'll use so many MAC addresses, you can buy a block. The first three octets (OUI) technically belong to the IEEE. The next 12 bits are also assigned. This leaves you with 12 bits. So you're really just buying 4096 sequential MAC addresses.

In both cases the organisation name associated with a MAC address is in a database on the IEEE site that is searchable.
However you can pay a bit more so that your company name is kept private.

So identifying their own MAC addresses should be straight forward if they are using an OUI or OUIs. I dont know if identifying the MAC address as their own is important or not though.

I'll see if i can find the one lantronix device ive got hanging around at work tomorrow and try it out.

FreescaleTM MC9S12NE64 / Re: Can I use uTasker?
« on: November 26, 2009, 09:17:17 AM »
Hey Dannix, i'm also working on a GPO relay controller.
Version 1 i tried on NE64. But code and RAM was uncomfortablly cramped and i had to drop a couple of desirable features.

I'm redoing the project with Freescale Coldfire MCF52235. I find the code quite portable even though i didnt necessarily write it with that in mind.

NE64= not a lot of code space or RAM.
A lot of the 8K gets gobbled by the ethernet buffers.

If the board's already on its way and its a one off project that you dont intend to turn into a product youhave to reproduce then there's no harm trying the NE64. You will however probably have to choose what features to use use because you'll probably find you'll have to keep telnet but drop dhcp and email stuff. or vice versa.
If you're making it a product or can see yourself wanting to add functionality and features later on then i also recommend trying out one of the other supported micros.

What IDE/compiler are you going to use? I dont know if any GCC tools are available but i guess if you can use the simulator and then do the compile and hardware debugging/programming with a full featured 30/60 day evaluation version of codewarrior or IAR or whatever other IDEs/compilers have evaluation versions.

The "free crippled" version of Codewarrior for Coldfire is very usable. I dont know if theres a "max files" limit but i havnt hit it yet. 128kB limit is a lot more that the 48K on ne64. Plus if you just want to use internal file system, NE64 Web pages have to be designed economically. Others micros you can put more features into.

For both coldfire and ne64 i use pemicro or bdm.

In my relay controller project, here's a couple of ideas ive added:

1. A schedule of 20 programmable events on startup to configure states of relays and any stagger timing between those relay toggles in the case of something like turning on 5 significant inductive loads.

2. A ping mechanism to see if the adsl modem can reach the outside world. If no ping response after set period, then power cycle adsl modem off one of the GPO relays. (my adsl modem/connection is a bit sticky sometimes).

Setup and control through web and telnet. I wanted to do email alert on return of power but i haven't got a handle on pushing emails to the outside world yet. Will also add TCP/UDP protocols for use with a PC software app. and for device discovery/advertisment.



µTasker general / Re: Finding device with DHCP IP address
« on: November 26, 2009, 07:43:17 AM »
This is an interesting topic. My two cents even tho youve put it on the backburner.
I asked myself the same question when we made our first product using utasker.

What i ended up doing was two things:

One: there is a single seven segment display and four buttons for reading and modifying the

Two: The devices periodically (every 1 to 3 minutes) advertise themselves using a UDP broadcast packet on a particular port. This could also use multicast packets if you dont like broadcast packets. A utility computer can also prompt for these advetisements with a "Request" packet on the same port.

This however does require a PC software utility and can only be used on the network where the devices/utility PC are reachable by UDP broadcast.

The devices also are given a third propietary address with a DIP switch. As long as the device is reachable, you can change the IP addresses using a UDP broadcast because the broadcast can tell a device of DIP switch address xxx to become IP address

This works as long as the DIP switch addresses are all different.
But even if there were one or two utasker devices with the same dip switch, it shows up on the software utility that sees the devices being advertised over UDP broadcast since they are also advertising their MAC Address.

I take it if your friend has a network that they have a computer?
Is it possible to find a simple UDP listener program ( i think i found one on sourceforge), give it to them, get them to enter the appropriate port number to listen two and the advertisements appear in the incoming window in plain text? IP=?

I've also played around with Lantronix. I think you're right, i think you could talk to them even if they weren't on your network. But i think you needed to know their mac address first? does that sound right? I haven't played around at the ethernet level but i suspect you can do some simple broadcasts/multicasts at that level to do discovery/advertisements.

What about getting it across the net?
Add an edit box in the web pages to put an IP or IP's to direct periodic advertisements to and set it up beforehand.
The friends router/modem should let this through but you'll have to make sure it gets through any firewall at your end.
Again you wouldnt necessarily have to make a software utility program for yourself if your happy just checking it with a freeware udp/tcp listener


µTasker general / Re: More HTTP sessions on a different port?
« on: November 26, 2009, 06:16:45 AM »
Yeah. Of course you're right. Not sure what i was thinking.

Now i'm trying to think of another reason to use it just cos ive done it.
I guess you could use different web parameters, different web handler or even different web pages?


µTasker general / More HTTP sessions on a different port?
« on: November 22, 2009, 11:29:29 AM »
I've already done this and it works but it's pretty ugly and implemented in a bad way....

So now i'm going to see if it's already been done, asked for or on your to do list Mark.

I wanted to have a way to use http locally using port 80 and be able to access the same pages remotely. I could port forward port 80 at the router(that has world facing ip address) to port 80 at my uTasker device but i wanted to keep it free for something else.

Plus, if two of this utasker project were used on the same network, i can't port forward port 80 to two different devices wth two IPs.

So i decided i wanted to add 4 more http sessions that would listen for connections on another port number that was world facing using port fowarding at the router on the port number i had chosen. I am still keeping the original 4 sessions that are listening for port 80 connections.

I'm not really worried out data on the pagesbeing out of sync. It will likely be only used by one person who is either on the local network or remote elsewhere so i dont expect feedback on the webpages being out of sync with reality because two people are manipulating the web pages at the same time.

All i did was replicate all? (most) of the functions in HTTP.c and given them a slightly different name. The sessions and message pointer is also replicated.

static HTTP         *ptrALT_HTTP = 0;
static TCP_MESSAGE              *ALT_HTTP_Tx = 0;

Anyway.............thoughts? It works so i'm satisfied with that. But i'm happy to hear about a method that would have been easier, less code space wasting and more elegant. Also happy to hear of any side effects i haven't seen or thought about yet.


FreescaleTM MC9S12NE64 / Re: Compiling uTakser 1.3 MC9S12NE64 in IAR
« on: April 10, 2009, 08:03:28 AM »
I also recall this being an issue when i was evaluating IAR for use with the ne64 utasker project. And the solution was as Mark has described.

The DBG_CODE maybe has something to do with which mode you are compiling in. I think IAR has a Debug mode and a Release mode. I don't thing i ever used the Debug mode and the project was always set to Release. I dont recall running into the DBG_CODE error.


FreescaleTM MC9S12NE64 / Re: Adapt9S12NE
« on: October 21, 2008, 06:26:51 AM »

If it comes to it, you can disable uTaskers serial functions and uTaskers serial interrupts and use your own interrupts, functions and serial setup routines. I did this for some code that was ported over from an hc08 series project.


FreescaleTM MC9S12NE64 / Re: No memory from 0x8000 to 0xbfff
« on: October 20, 2008, 07:09:51 AM »
I've got a feeling that the target setup/setttings for a "monitor" target wont work with the PE debugger.

Mark might jump in here with a comment but i believe that at least originally, uTasker CW project did not include a target for PE debugger.

You can add a target but at least in my CW version there is no option for automatic settings for PE multilink debugger. You could try entering the details in manually or....

To make it easy on myself i created a new ne64 project with the wizard in CW, and then chose to add a target for PE debugger and one for simulator. ( i wasnt using serial monitor). Deleted all or most(keep linker/prm/project/cmd and start12c files of the new project) of the new project files and replaced them with the uTasker files. Then i modified as mentioned previously the prm and start12c files.

Regarding the licence. I'm not sure. i take it they've sent you a new licence.dat file which has now been copied in place of the old one? Its a text file. open it up and see if the entry for version matches what you have. I've been sent licence.dat files for the wrong version once before.


FreescaleTM MC9S12NE64 / Re: First go at a compilation
« on: October 17, 2008, 03:01:55 AM »
It doesnt sound like this is your problem, but for CW at least.... dont forget to check you have a define in the command line arguments for "compiler for hc12" under the target settings. Including:



FreescaleTM MC9S12NE64 / Re: No memory from 0x8000 to 0xbfff
« on: October 17, 2008, 01:58:24 AM »
I had the same problem to begin with. same solution. here's a similar extract from my start12c:
i've commented out the #if define(_HCS12_SERIALMON). i'm user the pemicro debugger but i still need those settings.

__asm LDS #0x3FFF;

//#if defined(_HCS12_SERIALMON)
   /* for Monitor based software remap the RAM & EEPROM to adhere
      to EB386. Edit RAM and EEPROM sections in PRM file to match these. */
   ___INITRG = 0x00;  /* lock registers block to 0x0000 */
   ___INITRM = 0x39;  /* lock Ram to end at 0x3FFF */
   ___INITEE = 0x09;  /* lock EEPROM block to end at 0x0fff */


and here's my prm (theres a bunch of stuff commented out that i really should just delete).
Note that the file_routine segment should be placed in the lowest rom possible. This makes sure it is still accesible when the higher blocks are being swapped so the flash code is still accessible. Also not the two different ram sizes for dhcp and non dhcp. NE64 uses the lowest chunks of ram for ethernet buffers. see app_hw_ne64.h for buffer sizes

/* This is a linker parameter file for the MC9S12NE64 */

NAMES END /* CodeWarrior will pass all the needed files to the linker by command line. But here you may add your own files too. */

SEGMENTS  /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */
//    RAM = READ_WRITE 0x2C50 TO 0x3D40;   //for when use dhcp
      RAM = READ_WRITE 0x2602 TO 0x3D00;    //for no dhcp

    /* unbanked FLASH ROM */
    ROM_4000 = READ_ONLY  0x4000 TO 0x7FFF;
    ROM_C000 = READ_ONLY  0xC000 TO 0xFEFF;
    ROM_8000 = READ_ONLY  0x8000 TO 0xBFFF;

    /* banked FLASH ROM */
    PAGE_3C = READ_ONLY  0x3C8000 TO 0x3CBFFF;
    PAGE_3D = READ_ONLY  0x3D8000 TO 0x3DBFFF;
/*  PAGE_3E = READ_ONLY  0x3E8000 TO 0x3EBFFF; not used: equivalent to ROM_4000 */
/*  PAGE_3F = READ_ONLY  0x3F8000 TO 0x3FBFFF; not used: equivalent to ROM_C000 */

PLACEMENT  /* Here all predefined and user segments are placed into the SEGMENTS defined above. */
    _PRESTART,                   /* Used in HIWARE format: jump to _Startup at the code start */
    STARTUP,                     /* startup data structures */
    ROM_VAR,                     /* constant variables */
    STRINGS,                     /* string literals */
    VIRTUAL_TABLE_SEGMENT,       /* C++ virtual table segment */
  //.ostext,                     /* OSEK */
    DEFAULT_ROM, NON_BANKED,                  /* runtime routines which must not be banked */
    COPY                         /* copy down information: how to initialize variables */
                                 /* in case you want to use ROM_4000 here as well, make sure
                                    that all files (incl. library files) are compiled with the
                                    option: -OnB=b */
                                 INTO  ROM_4000,ROM_8000, ROM_C000 /*, ROM_4000*/;
 //   OTHER_ROM                    INTO  PAGE_3D, PAGE_3C;
  //.stackstart,               /* eventually used for OSEK kernel awareness: Main-Stack Start */
//    SSTACK,                    /* allocate stack first to avoid overwriting variables on overflow */
  //.stackend,                 /* eventually used for OSEK kernel awareness: Main-Stack End */
    DEFAULT_RAM                  INTO  RAM;
  //.vectors                     INTO OSVECTORS; /* OSEK */

ENTRIES /* keep the following unreferenced variables */
    /* OSEK: always allocate the vector table and all dependent objects */
  //_vectab OsBuildNumber _OsOrtiStackStart _OsOrtiStart


//VECTOR 0 _Startup /* Reset vector: this is the default entry point for a C/C++ application. */
//VECTOR 0 Entry  /* Reset vector: this is the default entry point for an Assembly application. */
//INIT Entry      /* For assembly applications: that this is as well the initialization entry point */



FreescaleTM MC9S12NE64 / Stack size / pointer setting recommendations
« on: August 22, 2008, 09:06:03 AM »
I think i need some advice for how i should be setting up the stack in the NE64.

I guess there's three settings im wondering about really.

Everything is working ok but i wonder if its just been luck so far.
I havn't yet used any of the stack/heap checking functions.

1. At what address should i be setting the stack pointer at initialisation?
2. In the PRM file should i leave room at the stack end of RAM indicating that the compiler should not try to allocate variables in a space set aside for the stack?
3. In the PRM file what size should STACKSIZE be?

 If i run the project on the debugger for a while and then stop it, can i look for some "untouched" memory pattern to make sure the stack and the heap didnt get too close to each other?

some of the settings in my prm file

      RAM = READ_WRITE 0x2602 TO 0x3D00;

      STACKSIZE 0x160

I'm using some of the buffer space normally used for ethernet buffers as ram at the bottom there. DHCP has been disabled. my name of "STACKSPACE" is only used in the above line and not referenced anywhere.

 i note in the demo program that STACKSIZE is 1 and RAM is allocated all the way:
RAM = READ_WRITE 0x2c00 TO 0x3FFF;


Pages: [1] 2 3 4