FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [June 2013 Threads] webserver slow after flash writePosted by Pierre on June 17, 2013 Hello,
I use FreeRTOS and lwIP for a webserver on STM32F217. The web page is used to change settings that are stored in flash (on the last page which is free). The problem is that after the update to flash the webserver is very slow. The erase time the page is very long (depending datasheets can go up to several seconds). For now the update of the flash is a sub-function of the Webserver task.
I see this alternative: Save the page in RAM (RAM backup area eg.) And create a separate save RAM to flash task.
Is there are others? Thank you. Pierre
RE: webserver slow after flash writePosted by Richard on June 17, 2013 Do you mean the web server is very slow while the flash is being written to?
I'm afraid I don't have any experience of writing to flash while executing a program on that or other part. The only way I have done it before is to run code from RAM while the flash is being programmed, but normally you can only fit a small amount of code in RAM, just the function that does the actual re-programming. Other than suggesting you have the flash writing performed in a task other than the lwIP task I'm not sure what to suggest (the write can be initiated by the lwIP task, but performed by another task).
Regards.
RE: webserver slow after flash writePosted by Jerry Durand on June 17, 2013 I'm starting to use microSD cards embedded instead of regular flash chips. They have built-in wear leveling and as long as you don't do a bulk erase they're decently fast at saving.
With any flash or EEPROM type device, they're fastest if you can do multiple block writes. You have to keep things aligned to the pages or sectors in the part but you fill the device's buffer and then it writes it all at once.
I found a nice holder for micro SD that's intended for this application (insert memory when you assemble the PC board and then forget it). ALPS #SCHD3A0100 , Mouser.com has them.
I also found out an old Kingston brand card I have has a bad CRC in one of their tables...always a surprise someplace.
RE: webserver slow after flash writePosted by Pierre on June 17, 2013 Dear Richard, “Do you mean the web server is very slow while the flash is being written to?” Not only, after writing in flash all the lwip stack becomes slow. One ping takes hundred of ms instead one ms. It seems the systick for FreeRTOS follow to run while the flash writing. About the SD card, you are right, I use it for another project with success but here there are econnomic constraints and it is just for a fifteen of bytes. And probably one rewrite by card in its live. Pierre
RE: webserver slow after flash writePosted by Jerry Durand on June 17, 2013 For 15 bytes I'd use one of the very small EEPROMS, 1 k Bit ones go for $0.20 in single piece (US dollars).
If it's going to be erased only a few times, just dedicate a segment of your processor Flash memory and sequentially write updates (no need to actually erase anything, only add a new record like a multi-session CD).
RE: webserver slow after flash writePosted by Pierre on June 18, 2013 Finally the problem is in the driver ethernetif.c. I tried the correction in this post: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-td11154.html#a11161Now the tcp/ip recover after a big delay for erase/write flash and even after a breakpoint stop. Thank you.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|