purduesigbots/pros2

Source code for PROS kernel 2: open source C development for the VEX Cortex microcontroller

PROS Kernel for the VEX Cortex Microcontroller

What is PROS?

PROS is a lightweight and fast alternative open source operating system for the VEX Cortex Microcontroller. It features multitasking, low-level control, and Wiring compatible functions to harness the full power of the Cortex. PROS is built with developers in mind and with a focus on providing an environment for industry-applicable experience.

Primary maintenance of PROS is done by students at Purdue University through Purdue ACM SIGBots. Inspiration for this project came from several computer science and engineering students itching to write code for the extended autonomous period. We created PROS to leverage this opportunity.

All PROS development is open sourced and available for the community to inspect. We believe that sharing source improves PROS through community contributions and allows students to learn by example.

PROS is built using the GCC toolchain and standard C practices (ISO C99) to make the learning curve small. Structures, pointers, dynamic memory allocation, and function pointers are all available. Additionally, code is run on bare metal, allowing you to take full advantage of the microcontroller's power.

You can develop code on Windows, OS X, or Linux. Code is compiled using GCC and the PROS CLI is available on most operating systems. The PROS development team makes distributions for Windows, OS X, and Debian-based Linux distributions.

The PROS team develops a plugin for Atom to making developing projects in PROS the best possible experience. The highly customizable editor designed for the 21st century enables students to learn how to code in a modern environment.

Cool, how do I get it?

Pay a visit to our website, pros.cs.purdue.edu, to download our latest installer or view installation instructions for your preferred platform.

How do I use it?

We have a number of resources available on our website, including

• A basic tutorial to get you acquainted with the PROS ecosystem
• A series of tutorials on how to use some of the more advanced features of PROS
• Extensive documentation on the kernel's API

Does PROS support C++?

No, PROS 2.x does not officially support C++. Some users have found ways around this, but be warned: we will not be able to help if you run into issues doing this.

I still have questions!

Drop us a line

• at [email protected]
• on the VEX Forum
• on VEX Teams of the World Discord

I think I found a bug!

We maintain GitHub repositories for the three major components of the PROS ecosystem:

• The Command Line Interface (cli) at purduesigbots/pros-cli
• The Atom plugin at purduesigbots/pros-atom
• The kernel here

If you find a problem with our documentation or tutorials, we have a repository for that, too, at purduesigbots/pros-docs.

pros2's Issues

Compiler Error with solution to #5 C++ newlib compatibility

Expected Behavior:

Including tuple before or after including API.h should not cause any compiler errors

Actual Behavior:

If tuple is included after API.h a compiler error is thrown: https://hastebin.com/vubolicumu.php

Steps to reproduce:

Include C++ header tuple before PROS header API.h

System information:

Kernel Version: 2.12.0

Additional Information

If I comment out these lines: https://hastebin.com/efodegaduy.cpp
Then the error goes away and I can include tuple and API.h in whatever order I want.
Tagging regression: #5

Further debugging on faults

A really nice feature would be the ability to actually locate what code caused a fault not just that one occurred, it was actually easier to achieve than i thought

First we have to get the pc at the point of the fault
Here is some working code:

static const char * const hex = "0123456789ABCDEF";
static void _fault_dumpInt(uint32_t num) {
    while (!(USART1->SR & USART_SR_TXE));
    USART1->DR = '0';
    while (!(USART1->SR & USART_SR_TXE));
    USART1->DR = 'x';
    unsigned char i = 32;
    while (i) {
        i -= 4;
        while (!(USART1->SR & USART_SR_TXE));
        USART1->DR = hex[(num >> i) % 16];
    }
    while (!(USART1->SR & USART_SR_TXE));
    USART1->DR = '\r';
    while (!(USART1->SR & USART_SR_TXE));
    USART1->DR = '\n';
}

// this function is basically the default error handler but prints out the instruction pointer
uint32_t _fault_dumpPC(uint32_t *faultStack) {
    //we dont need these for now
    //volatile uint32_t r0;
    //volatile uint32_t r1;
    //volatile uint32_t r2;
    //volatile uint32_t r3;
    //volatile uint32_t r12;
    //volatile uint32_t lr;
    volatile uint32_t pc;
    //volatile uint32_t psr;

    //r0 = faultStack[0];
    //r1 = faultStack[1];
    //r2 = faultStack[2];
    //r3 = faultStack[3];
    //r12 = faultStack[4];
    //lr = faultStack[5];
    pc = faultStack[6];
    //psr = faultStack[7];

    __disable_irq();
    USART1->CR1 = USART_CR1_UE | USART_CR1_TE | USART_CR1_RE;

    _fault_dumpInt(pc);

    while (!(USART1->SR & USART_SR_TXE));

    __reset();
}

// some ASM that calls our _fault_dumpPC function with a pointer to the stack that caused the fault
static void _fault_test( void ) __attribute__( ( naked ) );
static void _fault_test(void) {
    __asm volatile (
        " tst lr, #4                                                \n"
        " ite eq                                                    \n"
        " mrseq r0, msp                                             \n"
        " mrsne r0, psp                                             \n"
        " ldr r1, [r0, #24]                                         \n"
        " ldr r2, handler2_address_const                            \n"
        " bx r2                                                     \n"
        " handler2_address_const: .word _fault_dumpPC               \n"
    );
}

and then just call it at the top of the current fault handler because im lazy

void __attribute__((noreturn)) _exit(int status) {
    _fault_test();

compile kernel, put it in a project with some faulty code:

compile project and open up the debug terminal:

woo! we have our instruction pointer "0x08000192"

in order to convert this into the actual location of the fault, (obviously) first we need to compile the project with debugging information by adding -g to $CFLAGS in common.mk

CFLAGS:=$(CCFLAGS) -std=gnu99 -Werror=implicit-function-declaration -g

make sure you have arm-none-eabi-addr2line
finally

pixel@pixel-PC:~/pros_test$ arm-none-eabi-addr2line 0x08000192 --exe=bin/output.elf
/home/pixel/pros_test/src/opcontrol.c:36

Now ill work on getting a full backtrace and automating the process

Improve Speaker API

Some high level goals of this task are:

• Create lower level API to control the VEX speaker to not limit users to playing RTTTL sounds
• Make VEX speaker thread safe

Atomic tasks

A nice feature to have would be atomic tasks which will only context switch to other atomic tasks when yielded with taskDelay sort of like co-routine based multitasking. This would eliminate the need for mutexes on every variable shared by tasks.

Combined with this you could also have taskCreate instantly yield to the task its creating, allowing you to pass structs without dynamic allocation or statics since pointers to the struct on the caller's stack would still be valid

Double/Floats near integer values are not printed correctly in certain situations

void initialize() {
  for (float x = 0.96; x < 1.04; x+=0.01)
  {
    printf("%f\n", x);
  }
}

Expected Behavior:

0.960000
0.970000
0.980000
0.990000
1.000000
1.010000
1.020000
1.030000

Actual Behavior:

0.960000
0.970000
0.980000
0.990000
0.000000
1.010000
1.020000
1.030000

Steps to reproduce:

Run code above in new project.

System information:

Kernel Version: V2.12.1