acb35785c9
Previously the packet_rx() function would wait on the RxSem and when signalled it would process all available inbound packets. This used to cause no problem but once the thread synchronization was turned on via SYS_LIGHTWEIGHT_PROT, the semaphore actually started to overflow its maximum token count of 65535. This caused the mbed_die() flashing LEDs of death. The old code was really breaking the producer/consumer pattern that I typically see with a semaphore since the consumer was written to consume more than 1 produced object per semaphore wait. Before the thread synchronization was enabled, the packet_rx() thread could use a single time slice to process all of these packets and then loop back around a few more times to decrement the semaphore count while skipping the packet processing since it had all been done. Now the packet processing code would cause the thread to give up its time slice as it hit newly enabled critical sections. In the end it was possible for the code to leak 2 semaphore signals for every 1 by which the thread was awaken. After about 10 seconds of load, this would cause a leak of 65535 signals. NOTE: Two potential issues with this change: 1) The LPC_EMAC->RxConsumeIndex != LPC_EMAC->RxProduceIndex check was removed from packet_rx(). I believe that this is Ok since the same condition is later checked in lpc_low_level_input() anyway so it won't now try to process more packets than what exist. 2) What if ENET_IRQHandler(void) ends up not signalling the RxSem for every packet received? When would that happen? I could see it happening if the ethernet hardware would try to pend more than 1 interrupt when the priority was too elevated to process the pending requests. Putting the consumer loop back in packet_rx() and using a Signal instead of a Semaphore might be a better solution? |
||
|---|---|---|
| libraries | ||
| workspace_tools | ||
| .gitattributes | ||
| .gitignore | ||
| LICENSE | ||
| README.md | ||
README.md
mbed SDK
The mbed Software Development Kit (SDK) is a C/C++ microcontroller software platform relied upon by tens of thousands of developers to build projects fast.
The SDK is licensed under the permissive Apache 2.0 licence, so you can use it in both commercial and personal projects with confidence.
The mbed SDK has been designed to provide enough hardware abstraction to be intuitive and concise, yet powerful enough to build complex projects. It is built on the low-level ARM CMSIS APIs, allowing you to code down to the metal if needed. In addition to RTOS, USB and Networking libraries, a cookbook of hundreds of reusable peripheral and module libraries have been built on top of the SDK by the mbed Developer Community.
Documentation
- Tools: how to setup and use the build system.
- mbed library internals
- Adding a new target microcontroller
Supported Microcontrollers
NXP:
- LPC1768 (Cortex-M3)
- LPC11U24 (Cortex-M0)
- LPC2368 (ARM7TDMI-S)
- LPC812 (Cortex-M0+)
- LPC4088 (Cortex-M4)
- LPC4330 (Cortex-M4 + Cortex-M0)
- LPC1347 (Cortex-M3)
- LPC1114 (Cortex-M0)
- LPC11C24 (Cortex-M0)
Freescale:
- KL25Z (Cortex-M0+)
- KL05Z (Cortex-M0+)
STMicroelectronics:
- STM32F407 (Cortex-M4)
Supported Toolchains and IDEs
- GCC ARM: GNU Tools for ARM Embedded Processors
- ARMCC (standard library and MicroLib): uVision
- IAR: IAR Embedded Workbench
- GCC code_red: Red Suite
- GCC CodeSourcery: Sourcery CodeBench
API Documentation
- RTOS API
- TCP/IP Socket API (Transports: Ethernet, WiFi, 3G)
- USB Device API
- USB Host API
- DSP API
- Flash File Systems: SD, USB MSD, semihosted
- Peripheral Drivers API
Community
For discussing the development of the mbed SDK itself (Addition/support of microcontrollers/toolchains, build and test system, Hardware Abstraction Layer API, etc) please join our mbed-devel mailing list.
For every topic regarding the use of the mbed SDK, rather than its development, please post on the mbed.org forum, or the mbed.org Q&A.
For reporting issues in the mbed libraries please open a ticket on the issue tracker of the relevant mbed official library.