µTasker Forum
µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: k64konfused on September 24, 2014, 09:10:17 PM
-
Hi Mark, I'm trying my best to get running with KDS and uTasker on my FRDM-K64F, but so far I am completely failing.
First of all, I am relying on two documents to get started: 1) the readme file (http://www.utasker.com/docs/KINETIS/getting_started.txt) and 2) the uTasker v1.4 User Guide - First Steps PDF (http://www.utasker.com/docs/uTasker/uTaskerV1.4_user_guide.PDF).
Steps 1-3 in the readme are obviously very basic and I have all of the software downloaded and installed.
Step 4 I couldn't do because the software demo seems to be for the "tower board", which I do not have.
Once I got to step 5, I consulted the User Guide, but found the one specific to v1.4.
Here's where I got hung up. After I made a copy of Applications/uTaskerV1.4 and configured the simulator in Visual Studio, the next step was to add a new task to my project.
Specific questions at this point:
- when you say "add a new source file to the project", by "project" are you talking about the renamed project I created in the Applications folder, or are you saying that it should be in the root extracted uTasker folder? I've done it both ways -- when I look at the Project Explorer in KDS, should I have the Application, Hardware, stack, and uTasker folders, or should I just see Includes? Please see the following image:
(http://s28.postimg.org/slq3mhw1n/project_explorer_add_new_source_file.png) - If I put main.cpp into Applications/uTaskerDemo and then build, I just get a "Nothing to build for project uTasker" message
- If I put main.cpp into the other project that just shows Includes, then I get the error "fatal error: config.h: No such file or directory"
If you could help me fill in the details that I'm missing, I'd really appreciate it so I can start trying out uTasker. I apologize for these questions if the answers seem obvious. I'm just having a little trouble piecing the bits together. Thank you!
-
Hi
I wouldn't try making a new project yet since you can simply use the uTaskerV1.4 project as it is.
Therefore follow http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis.pdf and not http://www.utasker.com/docs/uTasker/uTaskerV1.4_user_guide.PDF.
Specifically, to work with KDS on the FRDM-K64F, starting with Release 1.4.7 do the following:
1. Delete all CW project files from the project root directory and copy the KDS project files from \Applications\uTaskerV1.4\KinetisDesignStudio\Project_Settings to the project root. The project root is the highest directory - the level where the folders \Applications, \uTasker etc. are located. This is also explained in the readme.txt file in the project root directory (V1.4.7 has CW set rather than KDS and they both need their project files at the same location - it is a bit of nuisance with Eclipe projects which want to have their files here but are otherwise not compatible with each other - same goes for Atollic)
2. Start KDS in a workspace of your choice - then import the project (see the CW video since KDS works the same)
3. Check that the compiler setting is for Cortex M4 (and not Cortex M0+) and select the linker script file \Applications\uTaskerV1.4\KinetisCodeWarrior\Linker_Files\K_1M_256.ld to match your chip (don't worry that this is a linker script in the CW directory since this can be shared for all GCC based builds). Again, this is shown in the CW video and is almost identical in KDS.
4. Select the uTaskerV1.4 target for Flash (rather than the serial loader, or others)
5. In \Applications\uTaskerV1.4\config.h comment in KINETIS_K60 to choose the family (comment out whatever is active if it doesn't match - I think that the default in that release is KINETIS_KE00). Then comment in the board FRDM_K64F, rather than TWR_K64F120M (in case it is selected) to select the exact HW.
6. Build and load to the board and you should have the project running. You can enable or disable USB, UART, SD card, ETHERNET and various TCP/IP services in the same file to configure what you want and don't (note that Ethernet is disabled by default in that release so you will probably want to enable ETH_INTERFACE). More detailed configurations are in \Applications\uTaskerV1.4\app_hw_kinetis.h (eg. choosing which UART the debug interface is on, whether SD card works with SDHC or SPI etc.).
Good luck
Regards
Mark
-
Thank you Mark, I certainly appreciate your prompt reply and will try out your suggestions ASAP!
-
Mark, I got a little delayed in trying your suggestions, but I followed them a moment ago. Everything compiles fine, but I can't seem to run the program on the target to test things out. I'm not sure how to proceed, given the following messages in my console.
(http://s27.postimg.org/3phblucj5/utasker_cantdebug.png)
FYI, I am currently using the mbed bootloader. Do I need to load the Segger J-Link OpenSDA firmware instead?
-
Hi
KDS can't work with the mbed boot loader.
- If you want to load the binary file (withoutz debugging) you can drag and drop it on the mbed boot loader when it appears as a USB hard drive.
- If you want to use KDS to load and debug you need to load the P&E debugger to the board. You can get details in this thread: https://community.freescale.com/thread/323324 and also a link to the code to be loaded.
Regards
Mark
-
Thanks, Mark! While there is still a gap in my knowledge regarding KDS, Eclipse, and various settings, it does look like the P&E bootloader did the trick. Once I realized that I had to specify the .elf file (I'm used to Visual Studio which does everything for me), I was able to debug the application. RGB LED is blinking green and I can ping the board at the specified IP address, so perhaps now I can shift back to trying out the simulator, as well as getting other peripherals to work in uTasker.
-
Hi
That sounds good.
Now that you basically have the complete infrastructure operating you can use the simulator to help you configure what you need and test that it is configured correctly, as well as doing some additional programming and debugging. Then you should be able to build the same with KDS, load to the board and verify the same behaviour.
When you find that you are not needing KDS to do actual debug work it is practical to reload the MBED boot loader to simply copy the .bin to the board.
Alternatively you can load the uTasker serial loader to the board (it has several modes such as Ethernet Web Server or USB loading) and then load using it. It also supports the Freescale KBOOT USB-HID loader.
Regards
Mark
-
Thanks, Mark. I just want to make sure I'm understanding things properly here, so here's an example.
I need to implement a Wiznet library over SPI so that I can add a 2nd NIC to the FRDM-K64F. Ideally, I'd simulate this first, but there isn't a way to send SPI commands to an external board. Therefore, I should simply write an interface for the library, then derive a simulation layer from this interface that the VS simulator project will call into. Once I prove that I can send simulated data back and forth, then I would implement the hardware layer and run through KDS.
While it's not possible to send SPI data, is the SPI interface something that is possible to emulate? In other words, I just need to confirm that I can make the uTasker SPI library call, and then have a simulated layer send back pre-packaged data. I think this is basically what you do for UARTs?
-
Hi
Take a look at the SPI Flash interface (in spi_flash_kinetis_sst25.h, spi_flash_kinetis_stmicro.h and spi_flash_kinetis_atmel.h). It allows the SPI Flash operation to be simulated but basically assumes that the SPI code works and passes the individual bytes to the interface in WinSim.c.
It doesn't make much sense to emulate the SPI interface itself since it is really only passing bytes of data back and forth.
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. I woudl interface the SPI Rx/Tx interface to the same NIC as the Ethernet one is connected to since the two can have different IP and MAC addresses so you could then ensure that the two networks are operating correctly over the single NIC.
Regards
Mark
-
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.
Regards
Mark
-
Thank you for the suggestions, Mark. I have to confess that I might need to read them a couple of times before I really understand. I'll post up whatever questions I come up with later on tonight. :)
-
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!
-
I should not rely on grayed out sections in the IDE. ;)
I added the code and it works, fnMyFirstTask executes. Awesome! Moving on...
-
Hi
Yes, be wary about greyed out code since all IDEs make mistakes on displaying these correctly (neither Eclipse and nore VisualStudio get it correct in all cases).
The best test is to type in a typo in the area you want to be sure of. If it builds without errors the area is NOT used. If there is a syntax error it means that the area IS used (irrespective of what the IDE may display).
Regards
Mark
-
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.
-
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!
-
Hi
The uTasker TCP/IP stack can operate on multiple networks and multiple interfaces. This means that you can have more than one IP address (either sharing one physical MAC address on a single interface or with multiple MAC addresses on a single interface, or on multiple interfaces).
The K64 has one EMAC (for Ethernet), which is an "interface".
If you have additional chips supplying further interfaces you can have a TCP/IP stack integrated into it but this will then not be a real dual-homed solution since the two TCP/IP stacks are completely seperate and so you will need some application layer that acts as a 'proprietary' interface between the two. This may get a bit messy since each interface may have rather different APIs.
The other solution, which I prefer for consistency and simplicity, is to add a second 'dumb' interface that just does the work of the EMAC (be it an SPI-EMAC-PHY or WiFi interface etc.). This means that there is only one TCP/IP stack involved which already handles all internal details and the application interface is essentially identical for whichever interface is being used. The API is consistent and there is probably less code involved in total.
Unless there is a special requirement of the other TCP/IP stack I would also stick to a 'dumb' interface due to the fact that any extensions to TCP/IP will be valid for all interfaces - if you find that there is something that the TCP/IP stack in an intelligent Ethernet module doesn't do that you want [may be even a special feature] you are completely stuck without either changing the HW or asking the supplier to upgrade the SW to make it possible (could be a risk since it is not fully under your control).
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!
Regards
Mark
-
>>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.
The principle is correct.
However the UDP frames are sent over the K64's Ethernet connection and not over the other network so this should be possible without any other impacts.
The idea is to have the main application (where the development work is at) on the PC in the simulation environment and just have final HW doing an interface extension (link between the API and the real HW).
Once all application development has been completed just build it for the HW without this simulation link (rather than [Application<->UDP in simulator]<-Ethernet link->[UDP<->SPI<->Ethernet on HW] it does [Application<->SPI<->Ethernet on HW] and should essentially operate identically (but already developed and debugged).
Regards
Mark
-
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
-
Hi
I find the Micrel KSZ8081RNA to be the best match for simple one port interface since it allows a single 25MHz crystal to be used for the complete design (the PLL in the PHY is multiplied to 50MHz to supply the Kinetis oscillator input).
Whatever PHY you are using there are reference designs at Micrel and all you need to do is contact an application engineer there and they will review a design to ensure that it is all correct - so there is little risk involved.
I never used the KSZ8863 but all PHYs have a basic IEEE register set so usually all will "basically" work with little effort.
If the processor that you use has an EMAC (Ethernet controller) I don't really see any need for using an external Ethernent controller unless you have no TCP/IP software and want to use the one built into the chip (don't forget you are paying for this SW then in the chip's price and so paying for each device and not a single royalty), even when a multihomed design is needed and the processor has only one EMAC (due to the 3-port switch's capability to simply make it look like two). The SPI throughput will aways be lower than the EMAC's and so lower performance.
If the processor has no EMAC built in it may make sense to use something connected via SPI (I would look at the Microchip ENC424J600 in such a case since it is low cost and I expect to have it supported in the uTasker project shortly) but often it is simpler to directly put a processor with EMAC in in the first place.
I don't think that the KSZ8999 allows controlling sending Ethernet traffic to specified ports (on a per frame basis) so this is probably not suitable for an 8 interface multihomed solution as such (more for simple managed switches etc.). Micrel may have newer ones that do support the tail tagging mode which can be used to achieve this.
Some details:
Tail tagging simply involves the processor specifying which port a frame is to be transmitted on by tagging on extra control bytes at the end of the frame (eg. to send to port 0 or port 1 only, to send to both or to send in switch mode). On each received frame the switch adds a byte to the frame so that the processor can read on which interface the Ethernet frame arrived on. This means that the SW works as if it has more than one Ethernet connection and there are physically more than one in the HW. This is simply sharing the single MII but otherwise operates as true multihomed HW. The SW does this with a hand-full of extra lines of code in the Ethernet driver and otherwise looks like a true multihomed architecture.
Regards
Mark
-
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:
(http://s28.postimg.org/azsspev7f/k64f_example.png)
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.
-
I wonder if the Freescale Tower Board (TWR-K64F120M) is the right way to go, so we can more easily get access to RMII...
-
Hi
I don't see the diagram but I am wondering whether you need two physical interfaces at all, especially as you write about not needing to be able to control the port that a switch would use.
There is no logical difference between a switch connected to multiple devices (each with their own IP and MAC and physical Ethernet connection) and a single Ethernet connection with multiple IP and MAC addresses.
If you don't physically need to sperate the networks so that no traffic is visible on the other Ethernet ports (eg like a router between two physically sperate networks) you can do it with a single Ethernet interface; the operation is controlled purely in SW.
A switch will simply allow one cable to be connected and will reduce traffic on each cable since it will not transmit frames if it knows that the destination is not situated there. The switch can be local (using a switch rather than a PHY) or simply connected to the Ethernet port externally.
If you need to add a three port switch (or other variation) rather than a simple PHY it woud be more practical to do this as prototype using a tower kit (than the FRDM-K64F) since you can add a prototype board with the PHY on it in place of the TWR-SER board (with the simple PHY connection on it).
Regards
Mark
-
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!
-
Hi
With Chrome I can see an image icon that I can then link to so I have now seen the diagram.
If you want the PC to be connected to network 1 and physically seperated from network 2 you do need the two interfaces.
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 (either sharing a single MAC address of using two different ones). When the second Ethernet interace becomes available (in HW and the SW driver for it as well) it can then be reconfigured to do the same but on two seperate Ethernet interfaces.
Regards
Mark
-
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.
-
Hi
The TWR-SER2 is supported (enable TWR_SER2 to select it rather than the TWR-SER board) but I haven't tested it together with a K64 tower board (possibly the configuration needs to be copied from a different processor (?)).
However the TWR-SER2 has 2 MII interfaces to 2 PHYs and so the Kinetis boards can "still" only use one of these. The TWR-SER2 is intended for connecting to devices (such as some bigger Coldfire ones) that contain 2 complete Ethernet controllers in them.
Regards
Mark
-
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?
-
Hi
Yes, by setting IP_NETWORK_COUNT to 2 will add a second network address.
Search the project for
#if IP_NETWORK_COUNT > 1
to see where additional settings are made (like the second network configuration) and you can also see the locations where this has an influence. The present Kinetis release (1.4.7) does contain a working setup for 2 networks as it is (it will allow operation on 192.168.0.3 and 192.168.0.4).
Later IP_INTERFACE_COUNT can be incremented. Don't do this just yet since it is a bit more involved and I have seen that the present release has a couple of settings missing that cause errors - I will be using it shortly so it will be resolved by the time you need to start with it.
There is no (released) document covering all of this yet but I will be working on it too.
Regards
Mark
-
Regarding the test with the FRDM and multiple IP addresses with a single interface, you are basically saying this, right? (see image below)
(http://s30.postimg.org/lnimq3oe7/Multiple_subnets_single_interface.jpg)
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! :)
-
Hi
A switch is only connecting Ethernet interfaces and is pretty dumb. You can have traffic on any number of networks passing through it.
A router would be a different story.
Regards
Mark