rtel wrote on Wednesday, October 04, 2006:
John, I’m finding that emails to you are bouncing back after two to three days. Can you send me your alternative address again as I’ve lost it.
In response to your SVN query, I tried a clean checkout and an update and both went through with no problems. Maybe there was a fault at the SourceForge end that is now resolved?
Regards.
westmorelandeng wrote on Saturday, October 21, 2006:
Forum Community,
This issue is a bit of a mystery - when Richard sends me e-mail (UK to US) - he gets bounces - but when I send e-mail to him - he receives it.
I’ve discussed this ad nauseam with my ISP - is it possible that the SMTP server across the pond doesn’t like domain names that are 23 chars long?
Westmoreland (12) + Engineering (11) = 23 ???
Any SMTP server experts out there?
TIA,
John W.
neilbradley wrote on Saturday, October 21, 2006:
What’s the text of the bounce? I’m not an SMTP expert, but I do run my own SMTP server (synthcom.com). I’ve not heard of a “domain name too long” problem before. Maybe I can track it down. John, who is your ISP?
westmorelandeng wrote on Saturday, October 21, 2006:
Neil,
This was one of the first things we looked at - Powweb claims no - definitely not on my accounts plus they claim not on any of their servers either… the only thing I could think of beyond this was maybe a box out there with an old version of something that rejected long domain names… not that makes sense really - but it was the only thing I could come up with after spending some time on this…
Thanks!
John
neilbradley wrote on Saturday, October 21, 2006:
Ohh… I think I know what this is. Powweb has problems with some versions of sendmail and they had to fix ours when talking to me (synthcom). Hopefully this text will be helpful (if a bit long).
> I\x92m writing this in response to your inquiry (ticket # 1541831) about
> receiving bounce back message while sending e-mail to some addresses.
>
>
> The new PowWeb mail servers use SPF (Sender Policy Framework) for
> preventing email forgeries and spam like the old servers did. SPF can
> sometimes introduce problems with forwarded mail. If you had mailbox
> forwarding to another address, and the intermediate server didn’t
> properly handle the message according to SPF, the email might be
> dropped. SRS encoding (http://www.openspf.org/srspng.html and
> http://www.libsrs2.org/) was developed to resolve this problem. Each
> server along the path
> rewrites the reply-to address so that the receiving server can properly
> determine the original sender and forwarders and check the appropriate
> SPF record.
>
>
> This SRS encodes ‘/’ in the envelope From: address in Base64. ‘/’ is
> valid within Base64 and legitimate RFC2822 character. However some
> remote MTAs do not like this character for some reason, being non-RFC
> compliant technically, and rejects the mails if they find mail from
> with SRS.
>
>
> We’ve implementing a workaround to overcome this ‘/’ problem to be
> compliant with MTAs that don’t like ‘/’ in Envelop From and we hope to
> resolve this soon.
>
>
> If you have any further questions, please don\x92t hesitate to contact
> us. We are available 24/7.
rtel wrote on Saturday, October 21, 2006:
Hi Guys,
Just a note that I removed the post that contained the bounced message text as it contains my email address in plain text - my spam box can’t cope. Sorry for inconvenience. I have only ever removed three messages from the forum, all for the same reason.
I’m currently creating the new zip download that contains dsPIC DCS, PIC24 and STR750 ports and demos. Once this is complete I will look at the wait for ever issue and comment on what would be necessary.
As a side note regarding the number of features. One of the original design goals was to keep the code small and simple, easy enough to understand to allow people to tinker with the code. As time has gone on FreeRTOS.org has become more popular than I originally imagined and I am always debating with myself how to take it forward, as would now seem appropriate. A lot of my time is spent creating new ports as new chips come out and/or people request them - the alternative would be to draw a line under the exiting ports and concentrate on adding new features. Pros and cons to both of coarse.
Regards.
neilbradley wrote on Saturday, October 21, 2006:
Thanks Richard! Hope I didn’t come across incorrectly. What you’ve designed FreeRTOS to do is precisely what it is, and very well executed I might add.
If I wanted to contribute back to FreeRTOS and add some of the kernel services I’ve been yammering about, what is the best way for me to go about this? Obviously I’d have to do things the FreeRTOS(tm) way code-wise, but I’m curious not only what you’re willing to take but what you’re interested in as well.
westmorelandeng wrote on Saturday, October 21, 2006:
Richard,
Understood and thanks!
Neil,
I’ll pass this on to Powweb - probably the same problem - what a coincidence that you’ve used Powweb too!
Thanks!
John
nobody wrote on Saturday, October 21, 2006:
> If I wanted to contribute back to FreeRTOS and add some of the kernel
> services
> I’ve been yammering about, what is the best way for me to go about this?
> Obviously
> I’d have to do things the FreeRTOS(tm) way code-wise, but I’m curious not
> only
> what you’re willing to take but what you’re interested in as well.
When people have sent code snippets of fixes in the past I have always done
the integration into the code base myself. I tend to be a bit of a control
freak about this - but it means I can maintain consistent look and feel,
check there are no side effects (especially from a portability view point)
and test the code myself on several architectures.
On occasion people have sent small functions that do fairly trivial
things - in general I don’t include these because they are only a few lines
long and if somebody else wanted the same feature they could easily add it
themselves.
Proper new features, such as those mentioned, would be welcome - provided
the author is happy for me to maintain the ownership/copyright message at
the top of each file. Needless to say I always credit people with work - I
don’t try and pretend I’ve done something when it was provided by somebody
else - but the copyright thing is a necessity.
What do you think about stacks/drivers/etc. Is it a good idea to provide
these, or maintain a focus on the kernel? There are open source options for
stacks/drivers but often the license is too restrictive for commercial use
(pure GPL without the exception provided by FreeRTOS.org for example). The
uIP and lwIP stacks are a good combination with FreeRTOS.org because of
their license terms. I don’t think it would be worth replacing these with a
FreeRTOS.org TCP/IP stack (but then again, maybe). File systems, more
generic USB stacks, that sort of thing would be good. Thoughts?
Regards.
neilbradley wrote on Saturday, October 21, 2006:
Thanks for replying, Richard. Lemme see, here.
I have no issues with you being a control freak about FreeRTOS, and I’d actually be surprised if you weren’t. One of the best ways to ensure quality in a product is to make sure that no crap gets into it. The author of a piece of code is always going to have familiarity with more than just the code - the whole concept and goal of the OS, which most others will not have.
I would have no problem with you owning my changes in their entirety. And of course I would do my best to follow existing code guidelines/examples so as to make integration much easier.
WRT stacks/drivers/etc… I personally don’t care much about the additional stacks/drivers when there are core features that I need that simply aren’t there in FreeRTOS.
I guess the larger question is what do you want FreeRTOS to become? Is it an interest thing - are you more interested in attracting more people via features or ports rather than core kernel functionality?
I currently have two projects that I’m considering FreeRTOS for:
The first is a hobbyist high altitude balloon project - that’s perfect for FreeRTOS and it has everything I need.
The second is a commerical project (sorry, under NDA, can’t mention what, but it’s a video game) that I’m porting from another RTOS that is long since dead (almost 10 years now) and with no rights to use. I’ve done a mapping of functions between FreeRTOS, the old operating system, and the actual function calls used, and there are holes that simply aren’t there in FreeRTOS:
1) Counting semaphores
2) Event flags
3) Mutexes
4) Timers
5) Task sleep/delay (this code suspends other tasks that are running for periods of time)
So I’m faced with either rolling my own OS, extending FreeRTOS for the features I require, or going with an off the shelf commercial solution. If FreeRTOS already had those needed features, the decision would already have been made.
Given that I’m coming from another OS and going to this (or another) one, I cannot believe I’m the only one who would evaluate an RTOS like this - mapping functionality. Is it your goal to make FreeRTOS more attractive to potential switchers porting from one OS to another? If so, I’d round out the kernel services first. It’s not like it has far to go. Here’s an example API list from ThreadX if you haven’t seen it already:
http://www.rtos.com/page/product.php?id=27
Licensing - boy, there’s a touch subject. I’ll make a blanket statement - I hate the GPL’s virulent nature. If you’re going to give something away free, give it away. I can perfectly understand wanting to keep extensions/mods/updates to FreeRTOS free, which is why I have absolutely no issue with FreeRTOS’s license. Forcing people to give back features in the core is a good thing, but it needs to stop there.
BSPs are a long haul. As long as there are sufficient proven examples to work from, that should be enough. There are always going to be people saying “Do you have a FreeRTOS port for chip x on compiler y?” and you’ll spend a lifetime trying to support them all. As long as support for free tools like GCC is availalbe and there’s at least one port for any given type of chip, that’s most of what you need right there.
There’s another apsect of this that ties in to board support packages. That is, FreeRTOS is great, but it won’t initialize memory controller x on CPU y unless you use one of the examples. I see this as a separate, but also important, task, especially when it comes to CPUs with network interfaces and peripherals built in to them (Intel IXP425 for example). Then you can go on and on with things like flash drivers. All of that is a big job.
But yes, eventually I’d like to see one stop shopping @ FreeRTOS.org for everything - BSPs, network stack drivers, operating systems, filesystems, USB drivers, serial port drivers, etc… all are extremely worthwhile. But the thing is you now have a very solid base upon which to build this empire. That is of course if you’re interested in doing so. What do *YOU* want to do?
So Richard, would you let me use FreeRTOS in my commercial products if I extended FreeRTOS to add the features that I need and give them back to you?
nobody wrote on Sunday, October 22, 2006:
> The second is a commerical project (sorry, under NDA, can’t mention what, but
> it’s a video game) that I’m porting from another RTOS that is long since dead
> (almost 10 years now) and with no rights to use.
A ten year old video game - sounds fun.
>I’ve done a mapping of functions
> between FreeRTOS, the old operating system, and the actual function calls used,
> and there are holes that simply aren’t there in FreeRTOS:
First - in the queue wait forever thread I have detailed what I think (without yet having studied it in great detail) is a two line change that permits wait forevers.
In software I have a philosophy of minimalism and simplicity. I don’t like to see features that are duplications, surplus or implemented in a more complex manner than necessary. The problem is though that how features are categorised is a philosophical question - John and yourself are both experienced engineers so I respect your view point - even if I don’t always agree. In an ideal situation new features will utilise the services already present - and I suspect that many commercial offering use 95% the same code for say mutex’s and counting semaphores.
> 1) Counting semaphores
I think these could be simply implemented by having a simple P and V wrapper around the exiting semaphore macros. Each counting semaphore would consist of a count value, and a handle to a semaphore as per the exiting implementation. When the count was zero the queue and even mechanism of the semaphore would be used - otherwise the count would be simply incremented and decremented.
I think this would be a good thing for me to add as it is something that has come up more than once.
As an aside, I originally had the plan of not using any #ifdef’s for conditional compilation as it does nothing for code readability. This ambition went out the window some time ago, so new features like this can be added but by default not be compiled into the code to maintain backward compatibility (wrt code size).
> 2) Event flags
This is an interesting one. There is not a quick solution that I can think of yet.
> 3) Mutexes
Why can the existing binary semaphore implementation not be used for this?
> 4) Timers
In what sense? Tasks can easily have them selves scheduled with a fixed period.
> 5) Task sleep/delay (this code suspends other tasks that are running for periods
> of time)
A task can sleep and delay itself for a fixed time, or until an absolute time. A task cannot do the same to another task - but implementing this would be straight forward. All you would need to do is pass in the handle to the task you wish to sleep and have the sleep performed on that handle rather than the handle of the calling task. This is similar to vTaskSuspend, which passes in NULL to suspend itself, or the handle of a different task if it wants to suspend a task other than itself.
One other point is that FreeRTOS is never intended to compete with, for example, real time versions of Linux. It is intended for small systems. ARM7, 9 and Cortex-M3
> BSPs are a long haul. As long as there are sufficient proven examples to work
> from, that should be enough. There are always going to be people saying “Do
> you have a FreeRTOS port for chip x on compiler y?” and you’ll spend a lifetime
> trying to support them all. As long as support for free tools like GCC is availalbe
> and there’s at least one port for any given type of chip, that’s most of what
> you need right there.
I agree! You would not believe the number of conversations I have that go something like:
Q - Oh, I see you support the SAM7S64, do you also support the SAM7S128?
A - What is the difference between the two.
Q - The 128 has more flash memory.
A - Yes FreeRTOS.org supports the 128 also.
Q - Where are the files in the download, I cannot find them.
A - Use the 64 files.
Q - But then I’m not using all the flash.
A - Change the linker script.
Q - How do I do that?
A - Read a book, search the WEB, go back to school, etc.
> There’s another apsect of this that ties in to board support packages. That
> is, FreeRTOS is great, but it won’t initialize memory controller x on CPU y
> unless you use one of the examples. I see this as a separate, but also important,
> task, especially when it comes to CPUs with network interfaces and peripherals
> built in to them (Intel IXP425 for example). Then you can go on and on with
> things like flash drivers. All of that is a big job.
Yes. There is a definite trend in the silicon market for vendors to provide source code. For example, I have just been working with the STR750 - which comes with a complete software library (even if I don’t like its style). Likewise the Cortex M3 offerings from Luminary. This is fine, provided people have the initiate to find it and understand it (ref the comments above).
Regards.
rtel wrote on Sunday, October 22, 2006:
I think it is obvious, but that last message was from me - I keep getting logged out for some reason.
Regards.
neilbradley wrote on Sunday, October 22, 2006:
Actually, it’s a 6 year old game using a 10 year old operating system that’s long gone. The RTOS is probably owned by some investment firmw somewhere now.
Thanks on the “wait forever”. That wasn’t one of the things I need for the game, but I’ll have a peek at it. I think the portMAX_WAIT should be equivalent to “wait forever”. That’s how ThreadX and uCOS-II handle it.
Yup - like I mentioned in prior emails, FreeRTOS is designed well enough to extend easily. I value simplicity as well, but at the same time there are things I expect in an RTOS as a minimal set.
I would also like to comment on this statement:
“On occasion people have sent small functions that do fairly trivial things - in general I don’t include these because they are only a few lines long and if somebody else wanted the same feature they could easily add it themselves.”
I’m not sure precisely what you’re talking bout, but adding trivial features like that, especially if people are adding them in repeatedly would make more sense if you added it to FreeRTOS. For example, mutexes. Until you pointed it out, and until I dug deeper on how FreeRTOS’s semaphores work, I didn’t realize a mutex could be implemented using the binary semaphores. Had there been a #define or something called “mutex…” I wouldn’t have had to dig further. So from a “shopping for an RTOS” perspective, the common/expected items should be included, if nothing more than the sake of completeness.
1) Regarding Semaphores, do you want me to dig into it, or do you want to handle it? It almost seems as if counting semaphores should be implemented as the base, with binary semaphore being derived from that.
Yeah, I hear you on #ifdefs. Ideally there aren’t any in any piece of code, but that way you’ve done it in FreeROTS is as readable as it’s going to get. I had no problem following it, and nothing struck me as illogical, unoptimal, or bad in any way. They’re logical splits.
At least it’s not like some old Phoenix BIOS code I worked with (over *400* ifdefs).
2) Event flags - want me to dig into this? I’ll need to study the core a bit more (if you have pointers to help me understand FreeROTS interals, that would be great). The tricky thing here is that it must be able to unblock more than one thread that’s waiting on the event flag.
3) Mutex - yeah, I could use a binary semaphore for that.
4) Timers - If my entire chunk of code was nothing but threads, yes, that would be an approach. However, there are all kinds of things I’d like to do with timers that don’t involve threads. For example, let’s say I wanted to blink an LED. Why not have a timer callback for that? Then I wouldn’t need a thread.
5) Correct - I’m looking for the sleep delay to allow controlling of other threads.
I know that FreeRTOS isn’t designed to compete with something like Linux, but the features I’m talking about are present in every other microkernel that I’ve used (hence me asking about it. 
).
Richard, do you have any comment on my question to you in my prior email:
So Richard, would you let me use FreeRTOS in my commercial products if I extended FreeRTOS to add the features that I need and give them back to you?
rtel wrote on Sunday, October 22, 2006:
> I’m not sure precisely what you’re talking bout, but adding trivial features
> like that, especially if people are adding them in repeatedly would make more
> sense if you added it to FreeRTOS. For example, mutexes. Until you pointed it
> out, and until I dug deeper on how FreeRTOS’s semaphores work, I didn’t realize
> a mutex could be implemented using the binary semaphores. Had there been a #define
> or something called “mutex…” I wouldn’t have had to dig further. So from
> a “shopping for an RTOS” perspective, the common/expected items should be included,
> if nothing more than the sake of completeness.
I think what you are highlighting is deficiencies in the documentation 
> 1) Regarding Semaphores, do you want me to dig into it, or do you want to handle
> it? It almost seems as if counting semaphores should be implemented as the base,
> with binary semaphore being derived from that.
> 2) Event flags - want me to dig into this? I’ll need to study the core a bit
> more (if you have pointers to help me understand FreeROTS interals, that would
> be great). The tricky thing here is that it must be able to unblock more than
> one thread that’s waiting on the event flag.
Let me have a think about these two items - I will get back to you via email. Ping me in a week if you have not heard from me.
One question would be where to implement these. I would not necessarily want to include another source file. They could be legitimately included in queue.c as they would use the queue implementation, but this might not sit quite right.
> 4) Timers - If my entire chunk of code was nothing but threads, yes, that would
> be an approach. However, there are all kinds of things I’d like to do with timers
> that don’t involve threads. For example, let’s say I wanted to blink an LED.
> Why not have a timer callback for that? Then I wouldn’t need a thread.
There is a tick hook facility. This only provides one time resolution. Something that provides multiple resolutions that were not a direct multiple/division of this would be tricky to keep portable.
> 5) Correct - I’m looking for the sleep delay to allow controlling of other
> threads.
This would be simple, but require another parameter to vTaskDelay() and vTaskDelayUntil() - being similar to the suspend/resume task handle parameter. I’m not sure if the provision of this would warrant an API change? I have never had this as a request before.
> So Richard, would you let me use FreeRTOS in my commercial products if I extended
> FreeRTOS to add the features that I need and give them back to you?
You can already - provided the condition in the table on http://www.freertos.org/a00114.html are met, otherwise a commercial licence can be used to remove the conditions.
Regards.
neilbradley wrote on Sunday, October 22, 2006:
Re: Documentation - Possibly, but I was looking through the FreeRTOS API in the .h file and not finding any mention of mutexes, so it’d not only have to be documented on the web site, but in the code as well. Even if the underpinnings are the same as another feature, then even something like a macro would be worthwhile. I scanned both the APIs and the .h files and couldn’t find mention of “mutex” anywhere. Even a note of “hey dummy, you can implement them with binary semaphores” would’ve worked.
How could event flags use the queue code? Or are you saying that it’d wind up using some of the same primitives? Regarding where to place it, if you take the ThreadX/uCOS-II approach, they implement each feature as a separate .c module (for the most part - there are some components of all features possible that are present in the scheduler and TCB structures). Having it as a separate module allows one to easily remove the functionality if it’s not needed.
TaskDelay - Well, personally I like consistency. If one API of a particular group uses a parameter like a task ID, they all should (makes it easier to remember how they work).
Regarding timers, there is no expectation that they are of a particular period, but rather “# of ticks”. This is expected! For example, under ThreadX/uCOS-II, if you set the system tick to 5ms, then you can get timers on multiples of 5ms. If you’d like, I can write a timer module for you for what I’m thinking. It’s quite straightforward, and definitely worthwhile.
Thanks!
rtel wrote on Monday, October 23, 2006:
>How could event flags use the queue code? Or are you saying
>that it’d wind up using some of the same primitives?
I was not being clear, but referring to the counting semaphores.
>Regarding timers, there is no expectation that they are of a
>particular period, but rather “# of ticks”. This is expected!
>For example, under ThreadX/uCOS-II, if you set the system tick
>to 5ms, then you can get timers on multiples of 5ms. If you’d
>like, I can write a timer module for you for what I’m thinking.
>It’s quite straightforward, and definitely worthwhile.
Sounds like a good plan ;-) Thanks.
Regards.