MCF5235EVB OpenTCP

[coolkiffings]

Hi, I'm quit new in this mc's stuff,

but i have to implement a client/server application with the evb. I'm trying to calculate something on the EVB and send the result back to my hostpc.

I'm using the udp protocol and the opentcp stack, which i've downloaded from the freescale page (for 5235bcc evb)

I've adapted the main.c a bit. I cut all the stuff for http server or telnet or something like this. Theres only the

    init_timerpool();
    arpinit();
    udp_init();

initialization.

I've attached the main.c.

The problem is, that it doesn't send anything to my hostpc, where i've written a small server application.

Hope someone can help me

Sorry for my bad english, I'm from germany.

[vier_kuifjes]

Hi,

I have some experience with Interniche Lite, but not with that board.

Interniche Lite (= Coldfire Lite) is not without issues though. Currently the main issue is that it is not compatible with Codewarrior 7.2.x. If you want to start using it, you'll need Codewarrior 7.1.x.

I would suggest you read my page with comments on Coldfire Lite here:

http://www.mvdh.be/cf_lite_patched.html

[coolkiffings]

Ah, thank you.

I've downloaded your 7.2 Stack. I hope I can port it to the board.

The problem is, that I'm really new in this topic..so I don't have any clue how to port it

to another board. Do I have to change the MCF5235EVB_sysinit to activate the ethernet port?

Or what I have to do?

[vier_kuifjes]

It is possible there already is a port for the 5235, but I may have removed it from my modified version. I'll have to check that.

It's not very difficult to write an application that receives messages over UDP and sends a response in return. I have done this already myself. If you wish I can give you some of the code.

[coolkiffings]

Yes, that would be great if you can send it to me

That would help me a lot. It's not hard to port to another board?

Hm, ok.. I'm working with the board since 2 weeks

[vier_kuifjes]

Hmmm... apparently there's no port for the 5235 CPU in the original coldfire lite. This may complicate things a bit. Porting should be possible but I think it will be quite a bit of work.

Available ports are:

5208

5223x

52259

5275

5282

53013

5329

54455

[coolkiffings]

yes..i've downloaded the original version from freescale, and there wasn't any port to the board

now i don't know how i have to port it..

[vier_kuifjes]

Maybe start by finding a supported CPU which matches the 5235 best. There's a subfolder src\cpu\... containing all cpu dependent code and definitions. It might be a good idea to start checking these files out...

[coolkiffings]

and what do i have to check there?

if the registers are the same or what do i have to do?

[vier_kuifjes]

The header files contain definitions of CPU internal registers. There may be some that exist in other CPUs but not in the 5235, Or there may be some that exist in the 5235 but not in other CPUs. Or they may be some that exist in multiple CPU types but located at different addresses.

Looks like it will be quite a bit of work...

[coolkiffings]

I've got some headerfiles from the opentcp project for the 5235evb board..can i replace them in the interniche stack?

should this work?

I've attached them in this post.

[vier_kuifjes]

They look very similar, but I don't think simply replacing them will do the trick. That would be too easy...

[coolkiffings]

yes they are very similiar. they come from the here.

couldn't it be so easy ?

I think tomorrow i will test it. But what could i do else? check every header file and adapt it to the board?

[vier_kuifjes]

You will also have to check the initialisation routines I guess...

[vier_kuifjes]

By the way... have you checked the MQX operating system? It's more modern and should be easy to program. But I don't know if there is a port to the 5235 CPU.

[mjbcswitzerland]

Hi Coolkiffins / Marc

It is strange to see OpenTCP linked with the M5235 since OpenTCP was intended for small processors (8/16bits) like the MC9S12NE64. It was a simple open-source project about 7 years ago with limited features which was not developed in any way.

I have seen that MQX is available on the M520X to Alpha customers but the M5235 seems to have a different register layout so will presumably require some extra work too.

It seems to me that ucLinux (this is often delivered with these types of boards) may be the best choice when ample SDRAM is available. This type of processor is used more in less price-sensitive projects where memory is less of a premium and often 32MByte+ space is available.

I would like to be able to suggest also the uTasker project (this does now include M5214, M5216, M5280, M5281, M5282, M5207 and M5208 on top of the V2 MCU line) but there is no M5235 support since it has never been requested. It is now finding its way into more of the V2 MPU based projects but mainly (but not exclusively) as web enabled loader to a more heavy-weight application (such as ucLinux...).

Regards

Mark

www.uTasker.com

P.S. Eigentlich schade, dass der M523X nicht dabei ist, denn wir hätten auch Support auf Deutsch gehabt...

[coolkiffings]

Hi,

No I don't want to use the MQX because the board should run without an RTOS,

it should be designed for testing some modules. So I flash the board with a multiply function in example.

The board calculates it and sends the result back with some CUnit informations..

I think my project is to small to use uTasker efficiently..I only need a leightweight TCP stack, for sending

a message via UDP to my host.

[mjbcswitzerland]

Hi

If you only run projects with a few lines of code would it not be better to use a single-chip one? Like M5223X, with integrated PHY?

This would make SW and developing much easier and HW much cheaper. Also it would probably be easier to find suitable SW for it.

You'll not be able to find TCP/IP packages without TCP and a few other features but anything not required can usually be simply removed by a define - leaving the Ethernet driver, ARP, IP and UDP.

Regards

Mark

[vier_kuifjes]

I too was thinking that using the 5235 CPU may be overkill for what you want to do with it. If receiving and transmitting in UDP packet is the only thing you will need to do, a "single chipper" may be all you need for a much lower price. Why not consider buying a 52259DEMOKIT, it's really cheap, and runs uTasker or Coldfire lite without problems.

[coolkiffings]

Well, surely it's quit easier to buy a new board but we only have this board at work, an my chief wants me to get it running on this board..

Yes I know that I have to implement all of the stack, and only call arp, ip and udp same like the main i've attached.

[mjbcswitzerland]

Hi

A new demo board costs $50 and you have several SW sources which will work out-of-the-box (either free or for small fees). It shouldn't take more than a day to get the basics working.

Following the present strategy may be rather more expensive and doesn't look to be predicatable how much time it will ultimately take. Since it has presently taken about 3 days without any progress I presume that you are working as an apprentice and your chef is giving you the job to gain experience and not achieve goals.

The M5235 can be used - if you don't have much experience you will need to find a BSP to get a working project [the biggest challenge is to get the device booting correctly, whereby it is probably simplest to run from external FLASH, which is programmed with CodeWarrior after selecting the exact FLASH type. Often the SDRAM controller needs to be configured and code copied first to SDRAM by a boot loader but there is enough internal RAM for small projects to not need to use SDRAM and boot loader at all].

After this you can chose any TCP/IP stack as reference. You will need to take the Ethernet controller and PHY configuration from somewhere (the EMAC should be compatible with any other Coldfire but the PHY initialisation may depend on the device on the board). The ARP, IP and UDP code is generally HW independent so shouldn't be a problem.

If you don't use an operating system, the simpler stacks use a periodic timer to control some counters so you will need to ensure that this code is running correctly - this may be HW dependent and you will need to ensure that the interrupt vectors are configured and working correctly. Vectors are often places in internal SRAM since this is the most efficient.

As an estimation, an experienced programmer should be able to do this in 1..2 weeks (very experienced maybe in 2..3 days). Less experienced programmers may require quite a bit longer.

It would in fact be an interesting exercise: could you report when the project has been completed and state which steps were the most time consuming?

Regards

Mark