Mailbox object

[rd...@iinet.net.au]

Hi,

 

What is the latency between a message being sent to a mailbox and a waiting thread being resumed?

 

In other words, if I call

 

rt_mb_recv(&mailbox, &message, RT_WAITING_FOREVER);

 

what is the latency between calling

 

rt_mb_send(&mailbox, message);

 

and the recv function returning?

 

Mailboxes are used by LwIP to send and receive data to and from the network interface and my testing currently shows a time per Ethernet frame as 49us. During my test the packets are not being processed by LwIP but are instead being handled by a custom protocol handler which does nothing but increment a counter and re-transmit the packet. A minimum length Ethernet frame takes 6.72us over the wire at 100Mb, I wouldn't expect there to be that much CPU time spent processing the frame. In an effort to try to locate where the other 40us is being spent I was wondering if anyone knows the latency due to the mailbox routines?

 

Regards,

Rob

 

[Ming Bai]

I'm a little bit interested about the time you provided here, '49us' and '6.72us', how did you get that? From some sort of instruments or just from calculation?

Besides, you may try bypassing the mailbox and repeat the package immediately right after receiving the package to help you find out whether the latency is caused by mailbox.

 

--
You received this message because you are subscribed to the Google
Groups "rt-thread-users" group.
To post to this group, send email to rt-thre...@googlegroups.com
To unsubscribe from this group, send email to
rt-thread-use...@googlegroups.com

[rd...@iinet.net.au]

Hi Bill,

 

The 49us was arrived at by setting up to identical boards running the same RT-Thread image (with different MACs). Board 1 would send a packet to board 2 which would then increment a 32 bit counter in the packet and return it, Board 1 would recieve the new packet, increment the counter and send it back to board 2. This process continued until 1 million packets had been sent. This took 49 seconds, therefore the average time per packet would have been 49us, or 20408 frames per second.

 

The 6.72us is simply the time it takes to transmit an Ethernet frame of minimum length (84 bytes including preamble and frame gap ...) at 100Mb. Or a max frame rate of 148809 frames per second. Of course I would not expect to be able to achieve this speed but I would expect better than I did achieve.

 

I have not had time yet to look into this. 49us is adequate for my needs at the moment, just not as fast as I expected.

 

Regards,

Rob

[Ming Bai]

Got it, basically I think, you're measuring your network latency. This kind of on-packet-loop of a minimum packet maxmized latency in your lan, in other word, what you did is simply a flood ping. So from this point of view, your result of the speed 100,000,000pkgs/49s is pretty good.

[rd...@iinet.net.au]

Hi,

 

Once again I've run into an issue that appears to be caused by the mailbox object. Basically there is a thread that has called

rt_mb_recv( ..., ..., RT_WAITING_FOREVER), while another thread is in a loop waiting for a packet. The DM9000 ISR gets called when a packet arrives and it calls rt_mb_send. However the thread waiting on rt_mb_recv doesn't resume and therefore the packet is not passed on to the polling thread. The thread that is polling eventually times out and exits and only then is the thread that is waiting for rt_mb_recv resumed.

 

I'm sure this is the same issue I was experiencing earlier with slower than expected network speeds.

 

Regards,

Rob

 

 

[bernard]

while,
what's your issue? You can use timeout feature of mail box to handle this case.

Bernard

--

[rd...@iinet.net.au]

 

As a way around this I have used an event object to communicate between the two threads. The problem with this is that in the case a reply packet is not received the event object timeout will not resume the thread quickly enough (10ms).

 

The network interface and Lwip is not very efficient in it's current form. Any amount of activity in other threads often causes overflows in the ethernet controller because the packets aren't being processed quickly enough because the thread waiting on the mailbox is not resumed quickly enough. A lot of packets can arrive in 10ms.

 

Rob

[bernard]

What's you request? There is a tx/rx in same time mode. Maybe you can check it on forum. Can you use Google translation to read Chinese?

[Ming Bai]

Open source project? if so, post your problematic code somewhere maybe far more better then to discuss over nothing.

[rogerz]

Why do you have another thread polling? If that thread has higher priority and never pend on something or sleep, it will occupy the CPU and your thread waiting for mailbox will never get the chance to run.

It seems in your work around, you have made the polling thread pending on event. That will solve the issue. But why don't you just wait for mailbox in the polling thread.

If it can not response in time(10ms), you may need to raise the priority of this thread. And I'm not clear about the value of your system tick. This will also affect the speed of scheduling.

--

 ,---.  Rogerz Zhang
( @ @ ) Human, not octopus
 ).-.(  Chase what you love and only that
'/|||\` 人非章鱼·爱吾所爱
  '|`   AsciiArt < Shimrod(hh)

[rd...@iinet.net.au]

The polling thread is part of a library I am porting. It would take a substantial effort to rewrite it.

 

I understand why it is not working which is why I was able to use an event object to work around the issue. And after looking through the code I see that the mailbox is working as designed. I was just expecting a faster mechanism for transferring control to a waiting thread. Such as preempting the current thread and resuming the thread waiting on the object without waiting for the next tick. Currently it's not enough to rely on the scheduler to prempt the current thread and resume a waiting thread, even it had higher priority it can still take up to 10ms (on a system with a 10ms tick).

 

On the Mini2440 the Ehternet ISR sends a notification to a mailbox object but it can take up to 10ms (or more if there are higher or equal priority threads) before the waiting thread resumes. This forms a bottleneck and impedes the performance of the network. Not only is it slower than it should be but packets are lost once the buffer overflows.

 

My "request" is simply for suggestions of how to improve the situation avoiding the 10ms limitation of the scheduler. I didn't write the ethernet interface to Lwip but perhaps a mailbox is not the best mechanism to use here? Or perhaps a faster mechansim can be implemented in RT-Thread? In most cases 10ms is adequate for a scheduler but in some cases a more immmediate context switch is required.

 

This library I am porting expects to timeout after waiting 500us for a reply packet and if one has not been received it resends it's request. I have implemented a timer with less then 1us resolution but if the thread yields it may not run again until the next tick.

 

 

Regards,

Rob

To post to this group, send email to rt-thread-users@googlegroups.com

To unsubscribe from this group, send email to

rt-thread-users+unsubscribe@googlegroups.com

[MingBai]

inlined.

On 12/06/2012 10:51 PM, rd...@iinet.net.au wrote:
> The polling thread is part of a library I am porting. It would take a
> substantial effort to rewrite it.
> I understand why it is not working which is why I was able to use an
> event object to work around the issue. And after looking through the
> code I see that the mailbox is working as designed. I was just
> expecting a faster mechanism for transferring control to a waiting
> thread. Such as preempting the current thread and resuming the thread
> waiting on the object without waiting for the next tick. Currently
> it's not enough to rely on the scheduler to prempt the current thread
> and resume a waiting thread, even it had higher priority it can still
> take up to 10ms (on a system with a 10ms tick).

No, preempting the thread which is target of a mail does NOT depend on
system tick.

> On the Mini2440 the Ehternet ISR sends a notification to a mailbox
> object but it can take up to 10ms (or more if there are higher or
> equal priority threads) before the waiting thread resumes. This forms
> a bottleneck and impedes the performance of the network. Not only is
> it slower than it should be but packets are lost once the buffer
> overflows.

Actually none of the bsps within rt-thread has a such kind of driver
which depends on system tick to handle Ethernet ISR notifications.
Moreover, any ethernet driver implementation that depends on system tick
should be considered as a bug. Considering the 100M Ethernet throughput,
10ms is a HUGE delay that is simply not acceptable.

> My "request" is simply for suggestions of how to improve the situation
> avoiding the 10ms limitation of the scheduler. I didn't write the
> ethernet interface to Lwip but perhaps a mailbox is not the best
> mechanism to use here? Or perhaps a faster mechansim can be
> implemented in RT-Thread? In most cases 10ms is adequate for a
> scheduler but in some cases a more immmediate context switch is required.

You don't need to 'request' that, it is there. Mailbox is fast, well
implemented, and has nothing to do with system tick.
I'd like to suggest you to double check your code. Pay special attention
to the Ethernet driver, it's a tough job in most platforms and don't
simply blame the mailbox implementation, I'm not promising that there is
no bug but, just think about the possibility, for this critical kernel
component.
Again, it would be great if you could post your code.

[MingBai]

inlined.

On 12/06/2012 10:51 PM, rd...@iinet.net.au wrote:

> The polling thread is part of a library I am porting. It would take a
> substantial effort to rewrite it.
> I understand why it is not working which is why I was able to use an
> event object to work around the issue. And after looking through the
> code I see that the mailbox is working as designed. I was just
> expecting a faster mechanism for transferring control to a waiting
> thread. Such as preempting the current thread and resuming the thread
> waiting on the object without waiting for the next tick. Currently
> it's not enough to rely on the scheduler to prempt the current thread
> and resume a waiting thread, even it had higher priority it can still
> take up to 10ms (on a system with a 10ms tick).

No, preempting the thread which is target of a mail does NOT depend on
system tick.

> On the Mini2440 the Ehternet ISR sends a notification to a mailbox
> object but it can take up to 10ms (or more if there are higher or
> equal priority threads) before the waiting thread resumes. This forms
> a bottleneck and impedes the performance of the network. Not only is
> it slower than it should be but packets are lost once the buffer
> overflows.

Actually none of the bsps within rt-thread has a such kind of driver
which depends on system tick to handle Ethernet ISR notifications.
Moreover, any ethernet driver implementation that depends on system tick
should be considered as a bug. Considering the 100M Ethernet throughput,
10ms is a HUGE delay that is simply not acceptable.

> My "request" is simply for suggestions of how to improve the situation
> avoiding the 10ms limitation of the scheduler. I didn't write the
> ethernet interface to Lwip but perhaps a mailbox is not the best
> mechanism to use here? Or perhaps a faster mechansim can be
> implemented in RT-Thread? In most cases 10ms is adequate for a
> scheduler but in some cases a more immmediate context switch is required.

You don't need to 'request' that, it is there. Mailbox is fast, well
implemented, and has nothing to do with system tick.
I'd like to suggest you to double check your code. Pay special attention
to the Ethernet driver, it's a tough job in most platforms and don't
simply blame the mailbox implementation, I'm not promising that there is
no bug but, just think about the possibility, for this critical kernel
component.
Again, it would be great if you could post your code.

[rogerz]

On Thursday, December 6, 2012, wrote:

The polling thread is part of a library I am porting. It would take a substantial effort to rewrite it.

 

I understand why it is not working which is why I was able to use an event object to work around the issue. And after looking through the code I see that the mailbox is working as designed. I was just expecting a faster mechanism for transferring control to a waiting thread. Such as preempting the current thread and resuming the thread waiting on the object without waiting for the next tick. Currently it's not enough to rely on the scheduler to prempt the current thread and resume a waiting thread, even it had higher priority it can still take up to 10ms (on a system with a 10ms tick).

 

On the Mini2440 the Ehternet ISR sends a notification to a mailbox object but it can take up to 10ms (or more if there are higher or equal priority threads) before the waiting thread resumes. This forms a bottleneck and impedes the performance of the network. Not only is it slower than it should be but packets are lost once the buffer overflows.

 

My "request" is simply for suggestions of how to improve the situation avoiding the 10ms limitation of the scheduler. I didn't write the  

ethernet interface to Lwip but perhaps a mailbox is not the best mechanism to use here? Or perhaps a faster mechansim can be 

I think a even lighter mechanism is completion. You can find it under component/driver/src. But it won't make much difference.

 

implemented in RT-Thread? In most cases 10ms is adequate for a scheduler but in some cases a more immmediate context switch is required.

In my understanding, the scheduler is called immediately when you send to mailbox. But the thread waken up is not the one waiting on it but the highest ready thread. System tick handler is used to wake up the suspended thread which is timeout.

I doubt that your higher priority threads sometimes may execute for more than 10ms without pending for any resource.

To switch context immediately to a dedicated thread, you may try calling rt_hw_context_switch() directly. Pick the thread manually instead of letting scheduler do it for you. You don't need any ipc object in this case. But you still need to worry about it being preempted by higher priority thread in next tick.

So my suggestion is to check your higher priority threads to ensure they won't occupy CPU for a long time.

This library I am porting expects to timeout after waiting 500us for a reply packet and if one has not been received it resends it's request. I have implemented a timer with less then 1us resolution but if the thread yields it may not run again until the next tick.

 

Not clear on how is the thread is waiting, polling for some status and check the timer?

[bernard]

Yes, the scheduler has no relationship with os tick. The os tick is used for timeout and same priority thread scheduling.

The possible thing is, there are some high priority thread exist in your system, or your process thread has another thing to handle and not waiting on an event object.

Please show your code for details information.

[rd...@iinet.net.au]

I don't pretend to be an expert on RT-Thread but I'm learning, despite the lack of documentation, so it is possible I could be doing something wrong. I post to this forum to provide a little assistance to the developement of RT-Thread where possible as well as to get a little help when things don't work as expected. I get the feeling some people get defensive and even slightly hostile when I suggest something doesn't work as expected. I'm not here to offend.

 

As far as a relationship between the scheduler and system tick, you say in one sentence there is no relationship and in the next sentence describe the relationship. The system tick calls rt_tick_increase which decrements the current thread's remaining tick count and when it reaches zero the thread yields and rt_schedule is called. I call that a relationship. The smallest timeslice is 1 tick. Although I don't fully understand how the timeslice is supposed to work, for instance if the thread yields before it's timeslice expires the next time it resumes it's remaining_tick count is not reset so it will only run for the remainder of it's timeslice.

 

In any case, sending to a mailbox resumes the waiting thread and calls the scheduler but there is no guarantee as to when the waiting thread will actually get executed. Also, in the context of an ISR such a context switch is not desireable until the ISR has returned.

 

As for posting code, you already have it, just start up a thread that remains busy for a period of time (a few ticks) and connect the device to a network with some traffic and see how long before the NIC (ie. DM9000) overflows as received packets are not processed quickly enough.

 

Regards,

Rob

[Ming Bai]

On Fri, Dec 7, 2012 at 12:31 PM, <rd...@iinet.net.au> wrote:

I don't pretend to be an expert on RT-Thread but I'm learning, despite the lack of documentation, so it is possible I could be doing something wrong. I post to this forum to provide a little assistance to the developement of RT-Thread where possible as well as to get a little help when things don't work as expected. I get the feeling some people get defensive and even slightly hostile when I suggest something doesn't work as expected. I'm not here to offend.

If what I posted gave you this kind of feeling, sorry for that, that's not what I mean. And I also absolutly agree that it's pretty tough to study rt-thread when there's very few English documentation, and that's also the reason why this forum exists and why we're here. But, you know, we're not paid, rt-thread is GPL licensed, just like many other open source projects, developers contribute their time and effort only because of their passion. So, just ignore those what made you feel unhappy and focus on the key points which can help you solve your problem. Okay, without further ado, let's get to the problem itself.

 

As far as a relationship between the scheduler and system tick, you say in one sentence there is no relationship and in the next sentence describe the relationship. The system tick calls rt_tick_increase which decrements the current thread's remaining tick count and when it reaches zero the thread yields and rt_schedule is called. I call that a relationship. The smallest timeslice is 1 tick. Although I don't fully understand how the timeslice is supposed to work, for instance if the thread yields before it's timeslice expires the next time it resumes it's remaining_tick count is not reset so it will only run for the remainder of it's timeslice.

Yes, the round robin rely on system tick, but mailbox doesn't.

 

In any case, sending to a mailbox resumes the waiting thread and calls the scheduler but there is no guarantee as to when the waiting thread will actually get executed. Also, in the context of an ISR such a context switch is not desireable until the ISR has returned.

Not really, there is a guarantee that the waiting thread will get executed unless another higher priority task is running.

 

As for posting code, you already have it, just start up a thread that remains busy for a period of time (a few ticks) and connect the device to a network with some traffic and see how long before the NIC (ie. DM9000) overflows as received packets are not processed quickly enough.

You mean the bsp is problematic without any modification? If so, that's a problem, indeed.

[bernard]

Hi Rob, 

I think its the language barrier. Take it easy.

Please see my inline reply. .

2012/12/7 <rd...@iinet.net.au>

I don't pretend to be an expert on RT-Thread but I'm learning, despite the lack of documentation, so it is possible I could be doing something wrong. I post to this forum to provide a little assistance to the developement of RT-Thread where possible as well as to get a little help when things don't work as expected. I get the feeling some people get defensive and even slightly hostile when I suggest something doesn't work as expected. I'm not here to offend.

 

As far as a relationship between the scheduler and system tick, you say in one sentence there is no relationship and in the next sentence describe the relationship. The system tick calls rt_tick_increase which decrements the current thread's remaining tick count and when it reaches zero the thread yields and rt_schedule is called. I call that a relationship. The smallest timeslice is 1 tick. Although I don't fully understand how the timeslice is supposed to work, for instance if the thread yields before it's timeslice expires the next time it resumes it's remaining_tick count is not reset so it will only run for the remainder of it's timeslice.

In face, the scheduler can be running well without system tick. The system tick will increase a tick count and decrease the remain tick count of current thread. But if there is no other ready thread with same priority level with current thread, the yielded thread is continued to run. That's to say, there is no any change for current thread if there is no the same priority level READY thread.

 

 

In any case, sending to a mailbox resumes the waiting thread and calls the scheduler but there is no guarantee as to when the waiting thread will actually get executed. Also, in the context of an ISR such a context switch is not desireable until the ISR has returned.

The typically time is about 5us for 78MHz ARM Cortex-M3 and more quickly for ARM9, which is the CPU core in mini2440.

 

 

As for posting code, you already have it, just start up a thread that remains busy for a period of time (a few ticks) and connect the device to a network with some traffic and see how long before the NIC (ie. DM9000) overflows as received packets are not processed quickly enough.

 

Do you mean the PHY negotiation? Could you please provide a simple code? For examples, 

One mailbox, 

Thread A waiting on it, 

ISR send a mail to maibox, 

...

[rd...@iinet.net.au]

No apologies necessary, I just don't want to be offending anyone. I might appear as someone who only shows up when he has something to complain about, but I try to contribute as well.

 

My apologies for the long post ...

 

An example:

 

Mini2440 BSP:

 

void test_thread_entry(void* parameter)
{
   /* Allow time for initialisation to complete */
   rt_thread_delay(rt_tick_from_millisecond(2000));
   rt_kprintf("Starting loop\n");
   while(1);
}

int rt_application_init()
{

   /* Init thread not shown */
 
   rt_thread_t test_thread = rt_thread_create("test", test_thread_entry, RT_NULL, 256, 20, 10);
   if(test_thread != RT_NULL)
      rt_thread_startup(test_thread);

 

   return 0;
}

Output:

 

RT-Thread Operating System 1.0.2
finsh />
mb_send 1354809805.1012958 sec
mb_send 1354809805.1012958 sec
mb_send 1354809805.1015617 sec
mb_recv 1354809805.1018361 sec
mb_recv 1354809805.1021456 sec
mb_send 1354809805.1032280 sec
mb_recv 1354809805.1034901 sec
mb_send 1354809805.1170354 sec
mb_recv 1354809805.1172984 sec
mb_send 1354809805.1180589 sec
mb_recv 1354809805.1183220 sec
mb_send 1354809805.1281898 sec
mb_recv 1354809805.1284521 sec
mb_send 1354809805.1566860 sec
mb_recv 1354809805.1569488 sec
mb_send 1354809806.1011366 sec
mb_recv 1354809806.1013991 sec
mb_send 1354809806.1025704 sec
mb_recv 1354809806.1028334 sec
mb_send 1354809806.1299488 sec
mb_recv 1354809806.1302143 sec
mb_send 1354809806.1423841 sec
mb_recv 1354809806.1426469 sec
mb_send 1354809806.1491763 sec
mb_recv 1354809806.1494391 sec
mb_send 1354809806.1781171 sec
mb_recv 1354809806.1783799 sec
mb_send 1354809806.1974919 sec
mb_recv 1354809806.1977550 sec
mb_send 1354809806.1985598 sec
mb_recv 1354809806.1988241 sec
Starting loop
mb_send 1354809807.1011572 sec
mb_send 1354809807.1049466 sec
mb_send 1354809807.1204277 sec
mb_send 1354809807.1272556 sec
mb_send 1354809807.1347320 sec
mb_send 1354809807.1472300 sec
mb_send 1354809807.1741845 sec
mb_send 1354809807.1767544 sec
mb_send 1354809808.1173681 sec
mb_send 1354809808.1218343 sec
mb_send 1354809809.1034044 sec
mb_send 1354809809.1103514 sec
mb_send 1354809809.1494931 sec
mb_send 1354809809.1653758 sec
mb_send 1354809810.1027936 sec
mb_send 1354809810.1052608 sec
mb_send 1354809810.1180608 sec
mb_send 1354809810.1187976 sec
mb_send 1354809810.1350496 sec
mb_send 1354809810.1475496 sec
mb_send 1354809810.1508429 sec
mb_send 1354809810.1637327 sec
mb_send 1354809810.1639931 sec
mb_send 1354809810.1745141 sec
mb_send 1354809810.1925185 sec
mb_send 1354809811.1033145 sec
mb_send 1354809811.1176719 sec
mb_send 1354809811.1287093 sec
mb_send 1354809811.1379172 sec
mb_send 1354809811.1389225 sec
mb_send 1354809811.1399052 sec
mb_send 1354809811.1409473 sec
mb_send 1354809811.1433895 sec
mb_send 1354809811.1443562 sec
mb_send 1354809811.1453379 sec
mb_send 1354809811.1464274 sec
mb_send 1354809811.1515863 sec
mb_send 1354809811.1518472 sec
mb_send 1354809811.1782566 sec
mb_send 1354809811.1908954 sec
mb_send 1354809812.1498128 sec
mb_send 1354809812.1532641 sec
mb_send 1354809812.1915710 sec
mb_send 1354809813.1322759 sec
mb_send 1354809813.1539988 sec
mb_send 1354809813.1849027 sec
mb_send 1354809814.1103352 sec
mb_send 1354809814.1322945 sec
mb_send 1354809814.1583318 sec
mb_send 1354809814.1729155 sec
mb_send 1354809814.1928225 sec
mb_send 1354809815.1026359 sec
mb_send 1354809815.1323137 sec
mb_send 1354809815.1738101 sec
mb_send 1354809815.1793020 sec
mb_send 1354809815.1918128 sec
mb_send 1354809815.1920735 sec
overflow

[bernard]

在 2012-12-7 下午4:14， <rd...@iinet.net.au>写道：
>
> No apologies necessary, I just don't want to be offending anyone. I might appear as someone who only shows up when he has something to complain about, but I try to contribute as well.
>  
> My apologies for the long post ...
>  
> An example:
>  
> Mini2440 BSP:
>  
> void test_thread_entry(void* parameter)
> {
>    /* Allow time for initialisation to complete */
>    rt_thread_delay(rt_tick_from_millisecond(2000));
>    rt_kprintf("Starting loop\n");
>    while(1);
> }

No, no.

A thread must be designed to avoid running all the time. It must suspend or block on some thing. If this thread is running with a highest priority, the system can not hand anything  except interrupt.

[rd...@iinet.net.au]

For some reason I managed to copy the first mb_send twice, it does not actually appear twice in the output.

The 1 after the decimal place can be ignored.

The times are just for reference, they are not accurate since they include the calls to rt_kprintf.

 

Rob

 

[rd...@iinet.net.au]

This was an extreme example to demonstrate the issue. The thread is low in priority and other threads do execute, the shell is responsive, etc. The tick interupt is calling the scheduler. But in any case the call to mb_send is interrupt driven and calls the scheduler which should switch to the thread waiting on the mailbox. In this example this never happens.

 

Rob

 

[Ming Bai]

On Fri, Dec 7, 2012 at 4:49 PM, <rd...@iinet.net.au> wrote:

This was an extreme example to demonstrate the issue. The thread is low in priority and other threads do execute, the shell is responsive, etc. The tick interupt is calling the scheduler. But in any case the call to mb_send is interrupt driven and calls the scheduler which should switch to the thread waiting on the mailbox. In this example this never happens.

No it should not. Because there is a higher priority task running in the foreground. Yes that thread has received a mail, but it will only put to ready queue and waiting....

 

Rob

[rd...@iinet.net.au]

I'm a little embarrassed to post this but here it goes.

 

Your comment about there being a higher priority thread running left me scratching my head until suddenly it clicked. For some reason, and I can't explain why, I had it in my head that thread priority 1, being the lowest number, was the lowest priority. When I realised my error things suddenly started to make sense, as I felt more and more like an idiot. I apologise for the confusion. Although my example showing a thread that did not yield does work provided it is a low priority thread, the scheduler does handle switching to the other threads as expected.

 

After adjusting my thread priorities I now get network performance closer to what I expected althougth I haven't had time yet to do more thorough testing.

 

A little info about my project, it is based on the Mini2440 BSP and uses the Hiteg cSky2440 core module. It uses the DM9000 Ethernet controller but I plan to move to the DM9010. The Ethernet controller uses MII to connect to an onboard 5 port Ethernet switch which provides Power Over Ethernet on 3 ports. An IIC EEPROM, a motion processor with gyros and accelerometers for full motion sensing, 4 channel high speed ADC, 16 channel low speed ADC, 8 channel D/A and 40 channel I/O expander. Micro SD card which supports SDHC cards as well dynamic mounting/unmounting. Analog signal conditioning on the A/D channels to support off-board accelerometers for vibration monitoring, RTD temperature sensors, and various 0-10 Volt, 4-20ma inputs. Currently I am implementing an EtherCat master.

 

I chose to use RT-Thread for this project because it's open source and because it has a small footprint compared to alternatives while providing most of the features desired in an RTOS. So far it has been working well aside from the odd little problem, most of which I have posted patches for. And now that I have my thread priorities fixed up my network performance looks to have improved. It's been an interesting and fun project so far and I'ld also like to contribute more to RT-Thread development.

 

Thanks for putting up with me during this.

Regards,

Rob

 

[MingBai]

Great!

[bernard]

Hi Rob, 

It's happy to hear that. 

As you know, some time the code will be a good way to communicate with each other. Any question or suggestion, please let me know, thanks. 

BTW, I have committed your patch. Welcome other patch. 

Best Regards,

Bernard Xiong

2012/12/8 <rd...@iinet.net.au>

Rob

 

--