µTasker Forum > µTasker general
turning off FS
twoerner:
platform: M5223x
app: uTasker V1.3 sample app with service packs 1-4
This might sound crazy, but I was wondering if it is possible to turn off (or disable) the uTasker file system in config.h yet still continue to use the HTTP server? In essence all I want is to use the HTTP-POST method to upload a new non-uTasker application to flash.
I replaced the 404 text #define (in config.h) with the POST section of 5admin.htm. Therefore I don't need "files" to serve up the HTML pages. This means I can diasable FTP (to save more space). I don't plan on saving the data that is uploaded with the POST as a "file". So I don't need "files" to serve, and I don't need to save uploaded data as a "file".
From the looks of it I'll need to hack the HTTP.c code since it seems to assume the filesystem is available, but if the above makes sense to you then you'll see that I don't really need files. Any "gotchas" I should consider?
[ps. I can't determine if this should be in this forum or the M5223x forum]
mark:
Hi
I think that this is the correct place since the question is not that platform specific. It is just as valid for an ARM project for example.
I understand that you would like to use the web server just to allow posting software. In this case replacing the 404 error page with a post formula is reasonable trick - note that most chips can be used with the define "SUPPORT_INTERNAL_HTML_FILES" which enables the web pages to be positioned in code rather than be uploaded via FTP (this is not possible with the NE64 project since it uses banked memory and one bank especially for files where HTTP always wants to access in the bank rather than use linear memory).
You are correct that normally the HTTP server works quite closely with the file system, which is generally logical since most HTTP use is to do with file reads and writes (mainly reads...). However it is also possible to use the option "SUPPORT_HTTP_POST_TO_APPLICATION". In this case the data which is received by the post is not actually saved to a file but rather passed on to the application. Your fnHandleWeb() call back can handle the event "POSTING_DATA_TO_APP", which is passed with a pointer to the data in the frame and the length of the data.
Then you are free to do anything you want with the received data - typical application are to send it to another port or write it to a device like an FPGA, but of course if you have routines that write it to your required location in FLASH this is probably what you need.
The only possible catches I see are these:
1. the parameter system (managing application parameters and IP config etc.) is realised as part of the file system code so completely removing the file system may cause some difficulty there - depending on whether you need the parameter support or not.
2. You may find it easier to keep the file system but replace the routines (or some of them with dummy calls to ensure that all compiles and links). I am not sure though.
3. You may find that you need a certain amount of code from the file system simply for saving to FLASH (you can also look in the boot loader code since this has a minimum solution for FLASH operations) and I am wondering whether you may find it easier with only quite minimum code size requirement to still use the file system in the project. According to code size comparison in the M5223X tutorial the file system code occupies about 2,3k FLASH. This includes also the low level FLASH driver routines for the M5223X so potential savings will be somewhat less.
Take a look at SUPPORT_HTTP_POST_TO_APPLICATION support. I would run the uTasker simulator and check that your HTTP post data is really passed to call back - check with data sending several frames to ensure that the file system never kicks in somewhere. When the application detects the end of the file you may like to have a second small web page in the program code which it then serves. See how fnHandleWeb() handles the end of a normal post to the file system - it receives the event "INFORM_POST_SUCCESS" and then specifies the web side to be displayed out of program code by returning "DISPLAY_INTERNAL" .
If you are lucky you may find that the HTTP code itself doen't require any manipulation to achieve what you would like.
Good luck
Regards
Mark
twoerner:
Hi Mark, thanks for your reply.
I've re-enabled the filesystem and am trying to get the SUPPORT_HTTP_POST_TO_APPLICATION / POSTING_DATA_TO_APP mechanism working. Unfortunately, every time the application comes to http.c -> fnPostFrame() -> case HTTP_STATE_POSTING_DATA, HTTP_session->ptrFile is always non-zero so the fnHandleWeb (POSTING_DATA_TO_APP...) function is never called and uFileWrite() is always called instead. As a very simple work-around I've just removed the if-statement which checks if HTTP_session->ptrFile is zero or not. But I'm guessing you probably had something in mind when you added that code, any idea what I'm doing wrong?
mark:
Hi
Best continue with this change so that you can ensure that all otherwise works the way you want to use it.
I have used this for writing posted data to a BDM in the past and will check out the details about the pointer - I'll report back as soon as I have details.
Regards
Mark
mark:
Hi
Now I have the details.
1. When posting, also make sure that you know what type of data is to be posted. Images, Text, binary etc. The single or multiple file types should each be defined (SUPPORT_POST_BINARY and/or SUPPORT_POST_TEXT and/or SUPPORT_POST_GIF). Unrecognised file types will be received without any errors but the contents will be dumped.
This is not a problem that you have since you already get further than this.
2. When the post begins, the call back event CAN_POST_BEGIN occurs, including details about the socket receiving the post. The details include a pointer to the file location where the file WILL be stored.
Your call back rountine (fnHandleWeb() in the demo SW) can check the file location if it wants and also change it - diverting the data elsewhere. In your case you can choose not to save it to a file by setting the file pointer to zero:
--- Code: ---HTTP_session->ptrFile = 0; // we decide not to save this to a file but handle it ourselves
--- End code ---
Note that you can also decide to refuse the post by returning any non-zero value.
3. For each frame you receive you will need to handle the event POSTING_DATA_TO_APP (I think that you probably already have seen this).
4. After reception of all of the data the event INFORM_POST_SUCCESS or INFORM_POST_FAILED (only when serious error) will be received. You then know that the data has been completely received and you can then cause a different web page (or default) to be served - see the uTasker demo which already does this.
So I think that you only need to clear the ptrFile field in the call back and this will allow the post to operate as you require, thus without modifying the HTTP code.
Regards
Mark
Navigation
[0] Message Index
[#] Next page
Go to full version