Search This Blog

Saturday, 7 May 2011

FTP Server and RedFly-Shield Socket class

I have been using Skewworks FTP server class to test my simple RedFly.Socket class. I got to a point where the FTP server was able to respond to a few FTP commands, including using 'get' to retrieve a file from the FEZ Domino SD card. But hit a snag when trying to send a file from the PC to the FTP server. It was becoming obvious that my simple implementation of a Socket class needed to have higher level functionality. Two thoughts were; implementing meaningful exception handling and function parameter checking, and hide in a lower layer the internal socket handling within the RedFly-Shield.

My search lead my to quite a few differing implementations of System.Net.Socket class library functions. Eventually I was draw to the implementation in the OpenSource Mono .Net core.

I've heavily refactored the RedFly.Socket class, and tweaked the FTP server and RedFly-Tester solution (make sure to grab at least r106 from the GoogleCode SVN repository).

As of r106 of the repository, the FTP server can perform most of the commands. 'get' and 'send' are quite limited at the moment though. They are restricted by the number of bytes for a file transferred.

I've got two new steps to take now -
  1. Try the RedFly.Socket class with other example code, such as HTTP client and server, DNS lookups, NTP sync.
  2. Finally update the UART reception handling.


Brett Chien said...

I am also working with this Redpine product and connect them using UART. Currently I have some problem during boot-up. I only can receive "Firmware loading..." but no "Loading Done". Just wondering if you can spend little time to help me up.


Richard Crowder said...

Hi Brett,

I had the same problem when I started. I used Teraterm to update the firmware. It looked like it worked, but upon reboot would never get passed "Firmware loading...". Have you updated the firmware? If so try another terminal program. See Rohan's comment two blog posts back.

Regards, Richard.

Brett Chien said...

You mean the very first time, I need to upgrade firmware. after the first upgrade firmware successfully, the module would work like it should be. I didn't do any firmware upgrade at all. it might be the problem. I will try it. Thanks.

Richard Crowder said...

Ah, no firmware updated yet. Your problem may be more complicated. Do you see the following?

Firmware upgrade (y/n)

Brett Chien said...

yes, I have seen that, and reply with 'n'. then I receives "Firmware loading...", but no further messages from the module, I also try to send something but no response neither.

Richard Crowder said...

Good. That shows that the auto-baudrate detection is working. And you need to see that question to be able to upgrade the firmware :)

Brett Chien said...

Hi again,
Just wondering that after the "firmware upgradation complete" message, I should send the at+rsi_reset command or do a hard rest, which we have a button connect to the reset? I still stock in the same place.


Richard Crowder said...

Hey Brett,

The readme text file found in Watterott Arduino library recommends doing a hard reset (complete power off) after firmware update.

Hope you have it working now, Richard.