It’s been a while…

Home  >>  Drivers  >>  It’s been a while…

It’s been a while…

On September 8, 2015, Posted by , In Drivers,PSoC, By ,,,,,, , With 13 Comments

I know….

It’s been a while since I posted the first little tastes of what was to come of our Ethernet drivers for the WizNet devices, but, even though it doesn’t seem like much has been going on, I’ve been hard at work on a number of little things that might come in use to many of you.

What’s Been Going One

  • I have a working beta of the WizNet W5500 version of the Ethernet driver. The API underwent a major overhaul that will make the driver even easier to use, and with the new W5500 interface protocol, the data throughput is faster than ever. Check out the “example” project at https://github.com/e2forlife/PSoC-W5500-Example.git
  • I’ve ported the PSoC version of the FreeRTOS RTOS (redundant??) version 8.2.1 to use as a component. This is a awesome since it makes using a RTOS in your projects much easier than the “Stock” flavor of just including the code or starting with the “example” projects. There is even a (not so) nice customizer for selection OS options too.
  • I’ve generated a USB UART Wrapper component that uses FreeRTOS Tasks to process the USB com port data so that your applications don’t have to manage the USB connection and Rx Data events.
  • Since I have a nice USB UART driver for FreeRTOS now, I had to build a library component that allows the use of markup tags to insert ANSI (yes, the old 1980’s terminal commands) to add color and cursor control to the strings your sending through the USB com port.
  • And, since all that was there, I couldn’t resist adding a CLI (Command Line Interface) widget that uses a FreeRTOS queue to connect to the USB UART, or another (W5500 driver, hint, hint) device.
  • Lastly, not only has the logo changed on the site, but with all these fancy new components, I had to design a nice new component block for PSoC Creator! Check it out…

    A Sweet new custom component block.

    A Sweet new custom component block.

All of this is in varying states of testing, with most of the OS and OS-Related widgets in an early alpha stage, but I’ve been using the components in my normal everyday work and the are performing exemplarily!

Check out the early alpha OS code at: https://github.com/e2forlife/PSoC-FreeRTOS.git

I haven’t yet had enough time to document these fully, but, look at the code in the example project and you’ll soon see the beauty of being able to quickly insert these components in to a design more-or-less on the fly.


13 Comments so far:

  1. Jeff Schultz says:

    Has this been tested with multiple TCP sockets concurrently? I’m not sure I’m using it correctly but before I dig too deep I just want to make sure that functionality should be working.

    Thanks for the work on this!

    • chuck says:

      Thanks Jeff! Presently there are a couple of levels of tested functionality in the Ethernet drivers. The FreeRTOS Task based access for the W5200 has been tested with two sockets open simultaneous (I haven’t yet had time to build a more through test), however the base code that was ported to make it task safe has been tested with 4 sockets open on 6 devices running from the same PSoC. The W5500 code is not yet “task safe”, has been tested with 2 open sockets. I have the W5100 code running with max open sockets assigned to TCP.

      If you don’t mind, can I ask what you are seeing or having some issues with?

      • Jeff Schultz says:

        I apologize, I thought I replied the other day but I must not have hit post.

        I’ve had good luck using ETH_TCPOpenServer(port) as a single instance but when I try open two ports they both show a status of started but I can only connect to 1 of them. I tried with two calls of ETH_Socket_Open(port,ETH_PROTO_TCP) as well but it seems to lose its ability to detect a disconnect wen I do that and still only one port worked.

        • chuck says:

          On the W5500 code that I have tested, I’ve opened two sockets, but only attached to one at a time. I was able to attach to both the sockets, however I have seen some of the described behavior before. I think that there might be something up with the TCP/IP stack ASIC inside of the W5500 device. On the W5200 I’ve had as many ad 4 ports up simultaneously, maybe there is a hardware difference between the two devices other than the stated stuff.

          I’ll try to look in to this a little deeper, since it seems troubling that the chip would report a successful status on both sockets, yet, not connect to both.

          • Jeff Schultz says:

            Would you say w5200’s reliability is worth using over the w5500 at this time then? I would rather use the newer/faster chip but not if it means sacrificing reliability.

          • chuck says:

            Personally, after working with the 5100, 5200 and the 5500, I like the 5500 much better for both hardware design and the software interfaces behind the chip. To me it looks like WizNET is trying to improve on the technology and make using the devices more simpler. That being said, if you need to have 2 ports simultaneously and the 5500 is not working, you may need to go a different route, but I don’t see why the chip would be doing that logically. The other reasons to use the 5200 are Space (it’s a QFN) and Auto-MDX to allow devices to connect directly to the PC Ethernet port without needing a Cross-over cable. this is a little less important as most modern devices already support Auto-MDX, but if your designing a box that can talk directly to another of the same (or similar) types it might be beneficial to think of using the 5200 for that feature as well. Essentially the 5500 is a QFP version of the 5200 with a better software interface and without the Auto-MDX.

          • Jeff Schultz says:

            I stuck with the 5500 because it seemed to function better than the 5200 for me (minus the multiple sockets issue but I only need one).

            Have you tested the TCPOpenClient portion of the code and/or have a sample of it? I’m wondering if I’m missing a step to make it connect to the remote device. it seems to open the local port (TCPConnected returns CYRET_SUCCESS)but it wont actually make the connection.

          • chuck says:

            I love the 5500 device, but it has a bit fewer features than the 5200… one being the Auto-MDX switching which is pretty nice when I just grab a cable off the shelf without checking. Regarding opening a client connection, honestly, I haven’t tested it much at all. Mostly a time constraint presently. If you think you identify any issues, please let me know and I’ll look in to the code to see what is going on with my setup here.

          • Jeff Schultz says:

            I am getting timeouts on my client connection. I’ve tried connecting to a different w5500 as well as just connecting to a telnet/ssh port on a laptop. at one point it did connect to the second w5500 while I was stepping through the client function with the debugger. It timed out shortly after.

            The server function is working well so I don’t think it is an issue with the PCB. For now I think I’m going to move to UDP instead to make life easier.

            Thanks again for the library and the work you put into it, I would probably still be writing the drivers without it!

  2. […] W5500 Ethernet Driver for free RTOS : ttp://www.e2forlife.com/2015/09/its-been-a-while/ […]

Leave a Reply