Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Re: Getting started with SPI devices

« on: November 11, 2014, 08:46:33 AM »

Ok, thank you for the heads-up, Mark!  I will look into this further...

2

NXP^TM M522XX, KINETIS and i.MX RT / Getting started with SPI devices

« on: November 10, 2014, 07:42:31 AM »

Hi Mark, I have not been working on this project enough lately, but I think at the moment it makes the most sense for me to try to get SPI devices working.  One is still the Wiznet W5100 in case I cannot figure out how to get the Micrel chips working in uTasker (highly likely), along with an RF module.

I started by looking through the code for SPI-related #defines, and I found #define SPI_INTERFACE.  I added that to my config.h, but the uTasker project doesn't build because it looks like the implementation of fnOpenSPI(SPITABLE *pars, unsigned char driver_mode) is missing.  Can you point me to any documents that you might already have available that will get me going in the right direction?  I looked at the document for the SPI EEPROM file system, but it specifically says to *not* use it with SPI_INTERFACE, so I figured that it would not be helpful to me.    Thank you!

3

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 16, 2014, 02:24:14 PM »

Regarding the test with the FRDM and multiple IP addresses with a single interface, you are basically saying this, right?  (see image below)



Honestly, I have never once tried hooking up devices that are on different subnets to the same switch.  All of the networking tasks I've done before just involve hooking up my home PCs to the same network! 

4

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 15, 2014, 10:09:59 PM »

You can however alread test the complete operation by connecting the PC (configured to be on the 10.10.10.x subnet) to the 8-port switch and configuring the FRDM-K64F to have IP addresses on both the 192.168.0.x and 10.10.10.x subnets but on its single Ethernet interface

Hi Mark, just to clarify the implementation portion of this, am I correct in assuming that this is done by setting IP_NETWORK_COUNT to 2 and then setting the properties for the 2nd subnet in network_default_1?  In addition, I leave IP_INTERFACE_COUNT as 1 until I eventually get the second interface, after which I would set it to 2?

5

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 15, 2014, 12:24:49 AM »

Thanks, I will try that tonight.  Does uTasker support the TWR-SER2?  It has two interfaces, which would be great for me so I don't actually have to attempt to design anything.

6

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 14, 2014, 11:42:03 PM »

That's strange, I can see the diagram two posts up on all of my PCs!

Regarding the separation of networks - while I technically do not need to direct specific frames to specific ports on the internal network, it would be nice to not needlessly send data to every device on the network.  I do need to separate the PC from the devices -- they cannot be on the same network, so that's why I need two interfaces.

It does sound like the tower board is the way to go for further development.  It looks like uTasker support for it is the same as the FRDM-K64F, so that is good for me.  I'll order one and give it a go.

Thank you!

7

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 14, 2014, 10:14:38 PM »

I wonder if the Freescale Tower Board (TWR-K64F120M) is the right way to go, so we can more easily get access to RMII...

8

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 14, 2014, 06:43:00 AM »

Hi Mark, I think all of my questions are causing things to get a little confusing.  Let me present a simple overview of what I am trying to achieve:



My goal is to have the simplest implementation for two NICs possible with uTasker.  The FRDM-K64F block in the diagram doesn't necessarily have to be that board -- I could attempt to create my own board based on the same processor and add my own ethernet (dual) MAC/PHY of choice, but it's not the easiest option.  However, I still have to consider that to make integration using uTasker more seamless.  So I have two routes:

Use the FRDM-K64F
In this case, I would use the MAC/PHY currently onboard to talk to Network 2 in the diagram.  I would then have to pick an SPI-based MAC/PHY (likely from Micrel) and use the uTasker TCP/IP stack to communicate with the PC in the diagram over Network 1.  Do you already have support for the Micrel SPI=based KSZ8851SNL?  If it is not supported, then another, less desirable approach is to use the Wiznet 5100 and implement the SPI communication code to talk to the PC.

Use a custom board with same processor and replace the MAC/PHY
In this case, instead of using the MAC/PHY selected for the FRDM-K64F, I would select another suitable chip from Micrel.  Since I need two separate network interfaces (one to talk to the PC, and the other to talk to the switch that's connected to all of the devices in the diagram), I would need to pick something with more than one interface (i.e. KSZ8081RNA is not suitable, right?), like the KSZ8863.

Does this sound about right to you?

At this point, I do not think I need to route Ethernet traffic to specific ports if I delegate this sort of task to an internal off-the-shelf switch.  However, it would still be nice to eliminate the extra hardware if something like the KSZ8999 is sufficient.  Unfortunately, my knowledge in this area is pretty limited, so I appreciate your comments and feedback, as well as the extra info on tail tagging, which will help me to do more searching and learning about the subject.

9

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 13, 2014, 03:07:10 PM »

The K64 has just one EMAC but if you need two complete Ethernet interfaces (for redundancy or multi-homed solutions you really only need to put in a Micrel KSZ8863 as PHY since this is a 3-port switch allowing 2 physically independent Ethernet connections to be created (costs may be $1 more than a standard PHY, plus a second RJ45 socket). This is supported in the project and allows it to be used as a switch (saving the need for external switches to attach multiple devices together or for redundancy) or as two controlable interfaces on a single EMAC (it has what is called tail-tagging operation which allows this and is supported by the EMAC driver). This avoids the need for further chips and SPI interface since all passes via the single MII interface!

So basically this means I'd have to make a new board based on the K64F, but replace the current MAC/PHY with the Micrel part that you have recommended, and then uTasker would immediately be capable of multihoming using two different interfaces?  That sounds like a much better solution than adding the W5100 or even an SPI-based MAC/PHY, but since I'm not an EE, I have no idea how to evaluate the complexity.

That's definitely something to think about, but let's say that I want to use temporarily evaluate uTasker with a middle-ground solution and pick up a Micrel SPI MAC/PHY like the KSZ8851SNL.  Is uTasker already capable of interfacing with a chip like this out of the box?

EDIT -- another interesting question I have is that if uTasker is capable of handling multiple interfaces and the 3-port switch that you had referred to earlier, can it handle even more connections?  In other words, rather than having one interface that talks to my PC and the other that is connected to another network via a switch, couldn't I remove the switch completely and instead use a Micrel chip that supports, say, 8 internal connections?  I found this as an example: http://micrel.com/index.php/en/products/lan-solutions/switches/article/20-ksz8999.html

10

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 12, 2014, 10:41:21 PM »

Another technique is to use the final HW to interface with the SPI device but rather than have the complete application on the board just send each received packet (received via SPI) in a UDP frame to the simulator. The simulator runs the complete application with a UDP socket in place of the SPI interface so the real HW is an extension to it. Rather than sending generated frames to teh SPI they are sent in a UDP frame to the board, which passes it on to the SPI based device. Once application development is complete, remove the UDP socket and connect to the SPI HW instead.

Hi Mark, I'm trying to understand this approach still -- based on the terminology you're using, it sounds to me like you are proposing a mixture of physical hardware and the simulator.  I'd like to outline it in excruciating detail just to confirm that I understand what you're suggesting.

The way I interpret what you're saying is to have the Wiznet 5100 plugged into the FRDM-K64F, and write code to interface with it over SPI.  Everything that comes from the W5100 gets sent over the FRDM-K64F via UDP packets.  The FRDM board is connected to my PC, running the simulator, via Ethernet.  Everything sent over UDP gets to the simulator, which then executes whatever command was contained in the UDP packet.

When the command is executed (which could result in simulateddata, like reading a sensor), this data is packaged up in a UDP packet and sent back over ethernet to the FRDM board.  The board does whatever it wants to with the data.

If this is what you're suggesting, I like it, but the one problem is that the Wiznet chip is intended to be connected to another network.  By using a mixture of hardware and simulator, the hardware port I'm trying to test connect with another network would end up getting used up to send UDP packets to the simulator on my PC.  Perhaps it's my lack of understanding about how networks can be configured that is preventing me from figuring this out.

I also picked up that book you had recommended.  Thanks for that info as well!

11

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 12, 2014, 09:37:51 PM »

In your case I would make use of the fact that the TCP/IP stack supports multiple networks and multiple network interfaces, especially if the Wiznet that you are using doesn't contain TCP/IP.

Mark, I have a rough proof-of-concept that shows uTasker will support the number of remote connections that I need.  Now I'm coming back to your suggestions regarding simulation of SPI data coming in from a Wiznet chip.

Are you saying that I could add another PHY to the board at some point, and uTasker will be able to bind it to a different IP address / subnet?  It seems like that would have advantages over using the Wiznet chip, which has the TCP/IP stack in silicon, but would require me to write more application code.  If I could add another physical interface and leverage your library, that would be pretty awesome.

*However*, when I looked at the K64F datasheet, it looked like it only supports one ethernet interface.  I'm not experienced in this area, but since I only see RMII0 (and not an RMII1), I assume that the only way to do what you're saying is to add another ethernet interface.  If so, can you recommend a compatible chip that you have used to show that a second interface will work?

Thanks, and sorry if this is a dumb ethernet question.

12

µTasker general / Re: Using TCP in the uTasker project

« on: October 10, 2014, 02:53:47 PM »

Hi Mark, as usual, thank you for the comprehensive (and comprehensible!) explanation.  The reason I was doing that was a) misunderstanding, and b) I was trying to do it quick-and-dirty, so closing the connection each time from a periodic task was necessary.  I haven't yet looked into how to initialize peripherals / features.  Ideally, I would open a listening socket upon startup, and then have multiple remote sockets get created only once when a connection needs to be made to its respective server/device.  Then in the periodic task I would just send ModbusTCP commands over each connection, and only close the socket upon shutdown.

I will definitely proceed in the order that you have recommended.  Hopefully, I will become more well-versed in TCP details in the coming weeks.

Thank you!

13

µTasker general / Re: Using TCP in the uTasker project

« on: October 10, 2014, 06:28:52 AM »

Hi Mark, although this is related to my "newbie" thread, I wanted to post here since it's related to TCP.  I am not an experienced network programmer by any means.  Most of the code I have written on Windows to program sockets uses really high level .NET libraries and aren't ever used in production code.

In order to get myself familiarized with sockets on uTasker, I felt that a reasonable starting point would be to leverage the simulator and modify the fnMyFirstTask() function from the getting started guide.  Here's what I ended up with:

Code: [Select]

extern void fnMyFirstTask(TTASKTABLE *ptrTaskTable)
{
static unsigned char ucCounter = 0;

/*
fnDebugMsg("Hello, World!  Test number ");
fnDebugDec(ucCounter++, 0);
fnDebugMsg("\r\n");
*/

static unsigned char ucRemoteIP[IPV4_LENGTH] = {192,168,0,112};
unsigned char data[MIN_TCP_HLEN + 4];
//memset( data, 0, 1024);

USOCKET test_client_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, TCP_DEFAULT_TIMEOUT, fnTestTcpServerConnect);
if (test_client_socket >= 0) {
USOCKET ret;
    if( (ret = fnTCP_Connect(test_client_socket, ucRemoteIP, 50000, 0, 0)) > 0) {
fnDebugMsg( "connected\r\n");
if( fnSendTCP(test_client_socket, data, 4, TCP_FLAG_PUSH) > 0) {
fnDebugMsg( "sent successfully\r\n");
} else {
fnDebugMsg( "send failed\r\n");
}
fnReleaseTCP_Socket( test_client_socket);
} else {
if( ret == SOCKET_NOT_FOUND)
fnDebugMsg( "Socket not found\r\n");
else if( ret == NO_FREE_PORTS_AVAILABLE)
fnDebugMsg( "No free ports available\r\n");
else if( ret == SOCKET_STATE_INVALID)
fnDebugMsg( "Socket state invalid\r\n");
}
} else {
if( test_client_socket == -2) {
fnDebugMsg( "No socket available\r\n");
}
}
}

I have the task set up to start after 10s and call fnMyFirstTask() every 10s.  This gives me enough time after starting the application to select the right NIC from the uTasker dialog.

I wrote a simple listener app in C# that listens on port 50000.  I know this app works because I have some code running on my FRDM-K64F that connects to the port and streams it data.  I can see the connection occur and bytes coming in.

When I run my application, via Telnet I can see that the socket gets created and connects successfully, and supposedly data is also sent successfully.  However, my app doesn't see the connection or byte stream.  On top of that, Wireshark reports some kind of error:

105964   4274.560943000   192.168.0.88   192.168.0.112   TCP   58   [TCP Out-Of-Order] 64416?50000 [SYN, PSH] Seq=0 Win=1460 Len=0

From reading the past posts in this thread, it sounds like it's possible that data could be sent, but not actually get received due to things like ACKs not being sent?  Anyhow, I put breakpoints in fnTestTcpServerConnect() and none of them get hit.  Actually, the function seems to not ever get called.

Can you provide me with any suggestions on debugging this further?  Can you also recommend any good reads for people that don't understand the nitty-gritty details of TCP, but want to learn?

Thank you!

14

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 10, 2014, 02:00:34 AM »

I should not rely on grayed out sections in the IDE. 

I added the code and it works, fnMyFirstTask executes.  Awesome!  Moving on...

15

NXP^TM M522XX, KINETIS and i.MX RT / Re: KDS / Eclipse newbie could use some help getting started

« on: October 10, 2014, 01:52:38 AM »

Hi Mark, I had to shift my attention to other things, but I'm back to learning how to use uTasker.  I'd like to get going with creating a socket and making a remote server connection.  However, the first thing I need to do is to be able to create my own task function where inside I do all of the socket calls.

I'm reading through the uTasker User Guide -- First Steps document, and it says to add the task identifier to ctNodes[].  The problem I see is that I'm running in the simulator under Windows, and in this case, all of the tasks are disabled because they are inside of a #if defined OPSYS_CONFIG block.  But surely there are tasks running somewhere, since the demo app is responding to ping.

Can you point me in the right direction?  Perhaps there's another document I should be reading?  Or is my demo project somehow misconfigured?

Thank you!