Matt Gordon

Matt Gordon

Forum Replies Created

Viewing 13 posts - 16 through 28 (of 28 total)
  • Author
    Posts
  • in reply to: porting of uC-os-iii #18091

    Matt Gordon
    Keymaster

    In order to run either µC/OS-II or µC/OS-III on a particular hardware platform, it’s necessary to have both a kernel port for the CPU core on which the platform is based, and a simple BSP to deal with the handful of peripherals that a project incorporating one of Micrium’s kernels requires. For a platform built around an STM32F103 MCU, the necessary ports have already been written. Micrium’s Cortex-M3 ports have been available since the M3 was first announced, and there are numerous µC/OS-II and µC/OS-III example projects on the Micrium Web site’s Download Center that use these ports.

    Among the projects listed on the Download Center are several examples targeting boards from STMicroelectronics, including a handful of boards outfitted with STM32F103 devices. Thus, for these boards, at least, the BSP code and the port files needed to run Micrium’s kernels is available. For other STM32F103-based boards, the BSP portion would need to be developed. However, there’s usually not an overwhelming amount of work needed to prepare a BSP for the kernels, since nearly all of the required code can be taken directly from examples that the MCU manufactures make available. A complete description of the basic BSP functions required for a working Cortex-M3 example project can be found in the following documents available from the Application Notes section of the Micrium Website: µC/OS-II Project Template for Cortex-M3 on IAR Embedded Workbench and µC/OS-III Project Template for Cortex-M3 on IAR Embedded Workbench.

    in reply to: undefined references to `CPU_SR_Restore' #17498

    Matt Gordon
    Keymaster

    Currently, all of Micrium’s example projects are hosted on this Web site. Among the projects available for download, there are numerous examples targeting various Eclipse-based IDEs, and most of these incorporate the port files needed to build either µC/OS-II or µC/OS-III under gcc. The Micrium Download Center page for STMicroelectronics MCUs, for example, offers links to many Eclipse-based projects: https://www.micrium.com/downloadcenter/download-results/?searchterm=hm-stmicroelectronics&supported=true

    in reply to: MSP432 Red vs. Black #17494

    Matt Gordon
    Keymaster

    Unfortunately, Micrium does not yet have an official example project for the newer red board that you’re using. However, we’ve worked with customers who are running µC/OS-III on this hardware. The feedback from the customers is that the correct initialization of clocks and Flash memory on the red board requires a slightly different procedure than that followed by Micrium’s examples for older versions of the board. In other words, the BSP_SysInit() routine provided in the examples must be modified for the new hardware. An updated version, which was actually modified by a customer, is provided below. Micrium’s team has not yet been able to fully test this code, but the customer is using it to successfully run µC/OS-III.

    
    void  BSP_SysInit (void)
    {
        // Set 1 flash wait state for 48 MHz
        FLCTL_BANK0_RDCTL = (FLCTL_BANK0_RDCTL & ~ FLCTL_BANK0_RDCTL_WAIT_15) | FLCTL_BANK0_RDCTL_WAIT_1;
        FLCTL_BANK1_RDCTL = (FLCTL_BANK1_RDCTL & ~ FLCTL_BANK1_RDCTL_WAIT_15) | FLCTL_BANK1_RDCTL_WAIT_1;
        
                                                            /* - Configure DCO to 48MHz. Make MCLK use the DCO.   - */
        CSKEY  = CS_ACCESS_KEY;                             /* Unlock CS module for register access.                */
        CSCTL0 = 0u;                                        /* Reset tuning parameters.                             */
        CSCTL0 = DCORSEL_5;                                 /* Set DCO to 48MHz operation.                          */
        DEF_BIT_SET(CSCTL0, DCOEN);                         /* Enable DCO (digitally controlled oscillator).        */
        
                                                            /* Select DCO as the MCLK with no divider.              */
        DEF_BIT_CLR(CSCTL1, (SELM_M | DIVM_M));
        DEF_BIT_SET(CSCTL1, SELM_3);
        CSKEY = 0u;                                         /* Lock CS module to protect it from inadvertent access.*/
    
        // Flash Bank read buffering
        FLCTL_BANK0_RDCTL = FLCTL_BANK0_RDCTL | (FLCTL_BANK0_RDCTL_BUFD | FLCTL_BANK0_RDCTL_BUFI);
        FLCTL_BANK1_RDCTL = FLCTL_BANK1_RDCTL | (FLCTL_BANK1_RDCTL_BUFD | FLCTL_BANK1_RDCTL_BUFI);
        
                                                            /* Enable SysTick Module                                */
        DEF_BIT_SET(BSP_SYS_REG_SCS_STCSR,
                      SYSTICK_STCSR_CLKSOURCE | SYSTICK_STCSR_ENABLE);
    
                                                            /* Set SysTick period to 1/48000                        */
        if (((CSCTL0 & DCORSEL_M) >> 16u) == 5u) {
           SYSTICK_STRVR = 48000u;
        }
                                                   
        CPU_IntEn();                                        /* Enable Interrupts.                                   */
    }
    
    • This reply was modified 3 years, 2 months ago by  Matt Gordon.
    in reply to: How to use Timers #15959

    Matt Gordon
    Keymaster

    The software timers in µC/OS-II (and µC/OS-III) have a relatively low resolution in most projects, since they are implemented using the same periodic, or tick, interrupt involved in time delays and timeouts. Through their callback mechanism, the timers provide a means of performing relatively simple operations either periodically or after a specified delay. As an example, a software timer and callback could be used to read an analog-to-digital converter (ADC) roughly once every 100 ms. For some applications, this approach could be preferable to creating a periodic ADC task that would require its own TCB and stack space.

    When it comes to measuring task or function execution times, the software timers would not be a good choice. It would be much better to rely on hardware timers for such measurements. Although most MCUs offer a variety of timers that can be used for measuring the duration of events, the simplest choice in a typical µC/OS-II-based project would be the timer that µC/CPU leverages for timestamp measurements. µC/CPU, which is a utility module found in practically every µC/OS-II example project, is expected to provide timestamping capabilities to other Micrium modules, so it normally (through a driver) initializes a hardware timer.

    To measure the duration of a particular passage of code, an application could simply call the µC/CPU function CPU_TS_Get32() immediately prior to the passage’s start and then call the function again at the passage’s conclusion. In most ports of Micrium’s newer kernel, µC/OS-III, this approach is used to keep track of tasks’ relative CPU usage. The kernel’s code, which is normally contained in the context-switch hook function, OSTaskSwHook(), uses a macro named OS_TS_GET(), as opposed to a direct call to µC/CPU routines, but the concept is the same. Numerous µC/OS-III examples incorporating this code are available from the Micrium Download Center, while the documentation for µC/CPU and its timestamp routines can be found here.

    in reply to: malloc from a ucos-iii task #15875

    Matt Gordon
    Keymaster

    It’s certainly the case that the stack pointer will lie outside of the bounds of the C stack while a µC/OS-II (or µC/OS-III) task is executing. If this is influencing the behavior of a library function within CrossCore Embedded Studio, then Analog Devices would be the best source of support. The porting and integration work needed for Micrium’s kernels to run in CrossCore was undertaken by Analog Devices engineers, so any requests for source code or for modifications would need to be directed to that team.

    • This reply was modified 3 years, 4 months ago by  Matt Gordon.
    • This reply was modified 3 years, 4 months ago by  Matt Gordon.
    in reply to: OS_memclr consumption of energy #15657

    Matt Gordon
    Keymaster

    OS_MemClr() is a function that uC/OS-II uses in place of the standard library routine memset(). (All standard library calls were removed from the kernel years ago to streamline the certification process for Micrium’s safety-critical customers.) The function is only called during initialization routines, where it is used strictly for initializing the arrays that serve as statically allocated pools of kernel objects in uC/OS-II. A complete list of these calls is provided below.

    OS_InitEventList(), in os_core.c
    OS_InitTCBList() (two calls), in os_core.c
    OS_FlagInit(), in os_flag.c
    OS_MemInit() (two calls), in os_mem.c
    OS_QInit(), in os_q.c
    OSTmr_Init() (two calls), in os_tmr.c

    in reply to: Proprietary Communication + Virtual Serial #15429

    Matt Gordon
    Keymaster

    Composite devices—those implementing more than one interface—are not uncommon in the USB world, and the authors of µC/USB-Device kept this in mind during the stack’s development. While, of course, it’s mostly up to application developers to write the communication and data-processing code for each of a device’s interfaces, the work involved in ensuring that the interfaces can coexist alongside one another, and that they are ultimately recognized by USB hosts, mostly boils down to configuration. Here, the µC/USB-Device user’s manual provided on Micrium’s documentation site can be especially helpful. The Configuration section of the manual offers detailed descriptions of the stack’s configuration constants and even provides example configurations indicating how these constants should be defined to implement different single-interface and composite devices.

    in reply to: Idle TCP Connection #15404

    Matt Gordon
    Keymaster

    Yes, µC/TCP-IP does support keep-alives, the segments commonly used by TCP/IP stacks to keep idle connections open. µC/TCP-IP will transmit keep-alive segments after a configurable interval of idle time on a connection, so that the remote device doesn’t send a FIN segment. For additional details on µC/TCP-IP’s keep-alive features, you can consult Micrium’s blog post on this topic.

    in reply to: Stack Problems #15333

    Matt Gordon
    Keymaster

    µC/OS-III offers an API function, OSTaskStkChk(), for checking the amount of free space remaining on a task’s stack. A full description of this function is provided on Micrium’s documentation site. Stack usage can also be monitored via µC/Probe, Micrium’s Graphical Live Watch tool. You’ll find more information on µC/Probe’s stack-related capabilities, and stack overflows in general, in this recent blog post.

    in reply to: FS Scan Directory #15330

    Matt Gordon
    Keymaster

    Although µC/FS does not offer a function that, with one call, returns a complete list of a folder’s files and subfolders, this behavior is fairly easy to implement with the APIs that are presently available from the software. There are actually two sets of functions that could be used to write code for examining directories’ contents. That’s because users of µC/FS can choose between POSIX-like API calls and proprietary Micrium calls for important file system operations. Thus, the situation on the file system is somewhat similar to that of µC/TCP-IP, which offers both a portable, BSD sockets API, and a Micrium-specific API that is capable of detailed error reporting.

    The POSIX-like functions that developers can use for accessing the contents of directories are fs_opendir() and fs_readdir_r(). Not too surprisingly, fs_opendir(), which accepts a path name as its argument and returns a pointer to a directory (assuming that there are no errors), is used for opening directories, while fs_readdir_r() provides a means of reading individual directory entries. The equivalent Micrium-specific functions are FSDir_Open() and FSDir_Rd().

    Code intended to read every entry in a directory would first need to open that directory—via one of the two APIs reserved for that purpose—and then begin reading entries, through a series of calls to either fs_readdir_r() or FSDir_Rd(). A pseudocode example is provided below. This example omits a few details of the operations involved, but it demonstrates the basic concept. For a lengthier, C-code example, along with information on all of the µC/FS directory functions, you can consult the file system section of Micrium’s documentation site.

    void  AppDirRd (void)
    {
        Open directory;                           /* fs_opendir() or FSDir_Open() */
        Read directory entry;                     /* fs_readdir_r() or FSDir_Rd() */
    
        while (Directory entry is not null) {
            Log or print current entry;
            Read next entry;                      /* fs_readdir_r() or FSDir_Rd() */
        }
    }
    in reply to: uC/Probe and Embedded Workbench #15261

    Matt Gordon
    Keymaster

    One of the easiest ways for users of Embedded Workbench to get µC/Probe up and running is to use the µC/Probe plugin that comes with all fairly recent versions of the IDE. To enable the plugin for one of your Embedded Workbench projects, you should first right-click the project’s name in the Workspace window and select Options from the resulting menu. In the Options dialog that subsequently appears, you should select Debugger from the Category list on the left and then, after clicking the right-most Plugins tab, check the box for the uC/Probe plugin that appears at the bottom of the Select plugins to load list.

    With the plugin enabled, Embedded Workbench will start a µC/Probe proxy server each time you run your code in the C-Spy debugger. This proxy server waits for requests from µC/Probe to read and write various memory locations on your target board. The server, in other words, stands between the tool and your board, allowing µC/Probe to interact with Embedded Workbench rather than sending read and write requests directly to the board through, for example, a hardware debug unit.

    Since µC/Probe supports a number of different communication mechanisms, it must be configured to send its requests to Embedded Workbench. This can easily be done through the tool’s Settings dialog, which is accessible via the Settings button that appears near the top left-hand corner of the main program window. To facilitate communication with the plugin, you should select the TCP/IP option from Target Resident Code in the Settings dialog, and you should then specify localhost in the Remote Host field.

    Once you’ve made this change in Settings, you’ll be able to proceed with µC/Probe much as you would on any other communication interface. For the most part, to use µC/Probe, you simply drag and drop different graphical components onto data screens and then associate the components with your embedded system’s variables. (It’s worth mentioning that an embedded system used with µC/Probe need not be based on the µC/OS-II or µC/OS-III kernels, since the tool is not dependent on Micrium’s embedded software modules.) For more information on basic µC/Probe operations, you can consult the videos available on Micrium’s Web site.

    in reply to: recv() vs. NetSock_RxData() #15260

    Matt Gordon
    Keymaster

    µC/TCP-IP actually offers two different APIs. With one of the two interfaces, the stack implements the familiar BSD socket functions. These functions, including recv(), are used in a wide variety of existing network applications and are well known to many developers with experience writing socket code. The primary motivation for implementing these functions within µC/TCP-IP, then, was portability—it should be fairly easy to adapt an application written for another BSD-compatible TCP/IP stack to µC/TCP-IP, or to go in the opposite direction, using a µC/TCP-IP-based application with a different stack.

    The other API available with µC/TCP-IP is unique to Micrium. This proprietary API follows the same naming conventions seen in µC/OS-III and other Micrium modules, so developers who are familiar with those modules should find it relatively easy to use. Additionally, the Micrium API offers error reporting that is somewhat richer than that available with BSD sockets, making it an appealing option for developers who require feedback from their sockets for debugging.

    Ultimately, the tradeoff to be considered by application developers attempting to choose between the two APIs is that of portability versus intuitive naming and error reporting. These concerns aside, the two interfaces are very similar—recv() and NetSock_RxData() both provide an effective mechanism for receiving socket data. For more information on these and other µC/TCP-IP API functions, you can check the TCP portion of Micrium’s documentation site.

    • This reply was modified 2 years, 1 month ago by  Micrium.
    in reply to: uC/OS-II on Nios 2 #15258

    Matt Gordon
    Keymaster

    On the Nios II, you actually won’t need an example project to get µC/OS-II up and running. That’s because the kernel is integrated into the IDE (the Nios II EDS). For any new project (created by clicking File->New->Nios II Application and BSP from Template), you’ll be given the option of a standalone BSP or µC/OS-II. If you choose the latter, the resulting project will incorporate all of the kernel’s source code, and any drivers that you use will—through hook functions—leverage kernel services for protecting shared resources and signaling events. Thus, it’s very easy to get started running µC/OS-II on any Altera platform supported by the Nios II EDS.

    • This reply was modified 3 years, 6 months ago by  Matt Gordon.
Viewing 13 posts - 16 through 28 (of 28 total)

View the complete site map

x
Loading...