Friday, October 16, 2015

SAM4S W5100 driver

In the past several days I was working on many different things, including my project which involves SAM4S development with ASF. I'm working on a device which will communicate on a local network, using W5100 (http://www.wiznet.co.kr/product-item/w5100/). I wrote a "driver" for this ethernet controller in the last days, so, I can start to implement the higher level code which will use this driver to send/receive packets, but that's a different story.

 They say that is good to have same pictures in the post to make it more interesting. So, here is my config which helps me to learn the basics of ARM and get some experience with ASF.



Since I didn't find much about SAM4S, W5100 and SPI on the net, I decided to share my code here, it's free to use. 
It has the following features:

  • SPI interface init
  • SPI handling on low level (sending/receiving bytes)
  • w5100 register reading/writing
  • w5100 TX/RX Memory writing/reading (data sending/receiving) including all the calculations needed for that

The driver uses ASF, so you will need the drivers and services which I specified earlier in one of my previous posts about SPI with ASF.

My driver is not a general driver, most likely it won't work out of the box on your board. It's customized on a way as I needed it, however, if you just start to implement something similar, my code could be a very good starting point for you. I tried to comment the less obvious parts, hopefully you will understand it.

You can download the files from here: SAM4 SPI w5100 driver
If you have any question do not hesitate to ask...


If you like my post and/or it was useful, please, leave some comment. If you don't, let me know that too. :-)
Posted by at
Labels: , , ,

2 comments:

  1. AnonymousSeptember 29, 2017 at 4:26 PM

    For anybody else doing something similar, I was trying to get the W5500 to work in combination with ASF, which ended up being quite a bit of a hassle.

    I find ASF's SPI interface to be pretty needlessly complicated, and dislike that you don't get explicit control of the CS line. I spent a big chunk of my time trying to figure out why I kept reading the same value (0x01) on all my SPI reads. Turns out something went horribly wrong with ASFs managing of the chip select line (I configured it as `SPI_CS_RISE_NO_TX` and all, along with careful passing of the `uc_last` byte). As soon as I set the cs behaviour to SPI_CS_KEEP_LOW, and managed the CS line myself (using regular GPIO) everything suddenly worked just fine ... Go figure.

    In a previous post you said "I have to say, if I would have started implementing the code without ASF, just using the datasheet then I would have finished it earlier.". I have come to the same conclusion ;-).

    ReplyDelete
  2. UnknownApril 10, 2019 at 2:49 PM

    i want the recharded cable

    ReplyDelete

Subscribe to: Post Comments (Atom)