Hello,

I'm working on an application where I need to change the flash. So, I erase pages and write bytes on-the-fly.

This is the erase page part:

FLASH_BASE->CR |= FLASH_CR_PER;
while (FLASH_BASE->SR & FLASH_SR_BSY);

FLASH_BASE->AR = pageAddr;
FLASH_BASE->CR |= FLASH_CR_STRT;
while (FLASH_BASE->SR & FLASH_SR_BSY);
FLASH_BASE->CR &= ~FLASH_CR_PER;

return true;

When there is serial data incoming in the same time, this results in a complete freeze of the chip just after starting the erasing.

Any idea why?

Apart from the technical debate about the elegance of the strings, when Maple is going to support the strings.h and stream.h libraries?

ARM-based Arduino Due, Teensy 3 and LaunchPad Stellaris provide them in their variant of the same Processing / Wiring / Arduino IDE.

• Arduino Due http://github.com/arduino/Arduino/tree/ide-1.5.x/hardware/arduino/sam/cores/arduino
• Teensy 3 http://www.pjrc.com/teensy/td_download.html
• LaunchPad Stellaris http://github.com/energia/Energia/tree/master/hardware/lm4f/cores/lm4f

Thanks.

We've started to update/check the source code to reflect the rev3 pin naming
conventions, but this process needs to be completed and tested on actual
hardware.

It appear that pin 9 PWM doesn't work, the following code:

    HardwareTimer timer(2);
    timer.pause();
    timer.setCount(0);
    timer.setOverflow(1000);
    timer.setPrescaleFactor(1);
    timer.setMode(TIMER_CH1, TIMER_PWM);
    timer.setMode(TIMER_CH2, TIMER_PWM);
    timer.setMode(TIMER_CH3, TIMER_PWM);
    timer.setMode(TIMER_CH4, TIMER_PWM);
    timer.refresh();
    timer.resume();

    pinMode(9, PWM);
    pwmWrite(9, 500);

Doesn't produce a PWM output on pin 9
However, writing it using OUTPUT and digitalWrite works
Also, producing a PWM on pin 8, which is also on timer 2 works

Any idea? (I've tried on two different boards just in case)

Hi, after investigations I figured out that using some pins seems to interfer with timer interrupts. Here is my example:

#include <wirish/wirish.h>

#define TIMER   1
#define CHANNEL TIMER_CH1

static void timer_interrupt()
{
    digitalWrite(BOARD_LED_PIN, HIGH);
}

__attribute__((constructor)) void premain()
{
    init();
}

int main(void)
{
    pinMode(BOARD_LED_PIN, OUTPUT);

    HardwareTimer timer(TIMER);
    timer.pause();
    timer.setPeriod(50000);
    timer.setMode(CHANNEL, TIMER_OUTPUT_COMPARE);
    timer.setCompare(CHANNEL, 1);
    timer.attachInterrupt(CHANNEL, timer_interrupt);
    timer.refresh();
    timer.resume();

    pinMode(27, OUTPUT);
    digitalWrite(27, LOW);
    digitalWrite(BOARD_LED_PIN, LOW);

    while (1);
}

In the example above, the led will never be turned on if you use CHANNEL=TIMER_CH1, and it will be turned on if you use CHANNEL=TIMER_CH2

It look like that pin 27 is indeed the timer pin 1_CH1, but why setting just it as OUTPUT would interfer with it?

Best regards

Hello,

When compiling with recent toolchains (from recent debian repositories for example), USB fail to enumerate
Do you have any idea what could cause this?

Hello,

I've noticed, that since the last Print.cpp rewrite, the usage of snprintf() make the final binary 23kb bigger.
See : http://forums.leaflabs.com/topic.php?id=680
For more info,

Thanks,
Xavier

I2C implementation in libmaple proper needs to be finished and documented before we can start the 0.0.10 merge process.

Pure C implementation only for now.

If the I2C remote device is not present, it appear that the libmaple can be stuck for ever in i2c_start_condition, any idea?

Hello
Why RAM is initialized at 20000C00 instead of 20000000?
What would happen if I change my bootloader to put the ram to 20000000 and set the board link script to also use this address?

Hello,
I'm wondering why so many STM32 based boards are running at 72Mhz
The PLL could technically go higher (or lower).. so why 72Mhz?

What will happen if I run my Maple Mini @128mhz for instance?

Hi,

I have a problem with 'make',

vit@myhost ~/projects/electronics/libmaple $ make
make: arm-none-eabi-gcc: Command not found
make: arm-none-eabi-gcc: Command not found
================================================================================

  Build info:
     BOARD:           maple_mini
     MCU:             STM32F103CB
     MEMORY_TARGET:   flash

  See 'make help' for all possible targets

================================================================================

  [CC]        ./libmaple/adc.c
arm-none-eabi-gcc: error trying to exec 'cc1': execvp: No such file or directory
make: *** [build/./libmaple/adc.o] Error 1
vit@myhost ~/projects/electronics/libmaple $

vit@myhost ~/projects/electronics/libmaple $ arm-none-eabi-gcc
arm-none-eabi-gcc: no input files
vit@myhost ~/projects/electronics/libmaple $ cc1
-bash: cc1: command not found
vit@myhost ~/projects/electronics/libmaple $ cc
clang: error: no input files
vit@myhost ~/projects/electronics/libmaple $

Thanks

The comments seem right for the ADCs addressed, but the code is wrong.

https://github.com/leaflabs/libmaple/blob/master/libmaple/adc.c#:~:text=void%20adc_set_sample_rate(const%20adc_dev%20*dev%2C%20adc_smp_rate%20smp_rate)%20%7B

Add C++ libraries in core

• string Stream.cppand Stream.h and
• stream Stream.cppand Stream.h.

Corresponding files for Wiring are Stream.cpp and Stream.h, WString.cpp and WString.h.

CDC_ACM mode stopped working for Perry, even when reverting to a known good version of libmaple. He could upload code via DFU by manually resetting and uploading during the window, but programs would fail (with no fault indication) immediately. Simply unplugging/replugging solved the problem (with the program in FLASH). This was with the FLASH memory target.

Here's the dmesg (not-working and then working):

[148682.090090] usb 6-2: new full speed USB device using uhci_hcd and address 121
[148682.255290] usb 6-2: configuration #1 chosen from 1 choice
[148684.790128] usb 6-2: USB disconnect, address 121
[148743.890124] usb 6-2: new full speed USB device using uhci_hcd and address 122
[148744.055380] usb 6-2: configuration #1 chosen from 1 choice
[148746.790086] usb 6-2: USB disconnect, address 122
[148757.100128] usb 6-2: new full speed USB device using uhci_hcd and address 123
[148757.324387] usb 6-2: configuration #1 chosen from 1 choice
[148759.580218] usb 6-2: USB disconnect, address 123
[148760.320129] usb 6-2: new full speed USB device using uhci_hcd and address 124
[148760.484370] usb 6-2: configuration #1 chosen from 1 choice
[148763.040348] usb 6-2: USB disconnect, address 124
[148792.410121] usb 6-2: new full speed USB device using uhci_hcd and address 125
[148792.576377] usb 6-2: configuration #1 chosen from 1 choice
[148795.290201] usb 6-2: USB disconnect, address 125
[148795.610127] usb 6-2: new full speed USB device using uhci_hcd and address 126
[148795.778328] usb 6-2: configuration #1 chosen from 1 choice
[148795.781278] cdc_acm 6-2:1.0: ttyACM0: USB ACM device

Hello

I know this would be really hard to do, but what about writing an adapter to emulate an ethernet over the usb?

Actually, that sounds more powerful and flexible than virtual com port

We could ping the board, netcat to it (with a basic tcp stack) and why not accessing to network

Again, I know it's not easy, and what I've read about that (usb device creating) seems insanely complicated. How feasible would be that?

Current script doesn't reset udev, check for the existence of plugdev, or create plugdev and add the user if it's not there. We've had several complaints; this could really use fixing.

Hi,
There is almost certainly a bug in Wire::process(), which occurs when you attempt to address a device that is not connected (and may occur under other circumstances)

What happens is that in i2c_get_ack, SCL is left low at the end of the function (see below)

bool TwoWire::i2c_get_ack() {
set_scl(LOW);
set_sda(HIGH);
set_scl(HIGH);
bool ret = !digitalRead(this->sda_pin);
set_scl(LOW);
return ret;
}

And in process() the function returns if there has not been an ACT (this happens in 2 places in process()

if (!i2c_get_ack()) {
return ENACKADDR;
}

Then when the next call to process() occurs (via Wire::endTransmission() ) SCL is low when it should be high, and the first clock falling edge, doesn't occur, hence only 6 address bits and the RW flag are clocked out.

So once there has been an error where ACK has not been received.

Wire totally breaks and never recovers.

The simple solution appears to be to Set SCL HIGH before exiting if there has been a failure to get an ACT

e.g.

if (!i2c_get_ack()) {
set_scl(HIGH);// Set SCL high ready for next transfer
return ENACKADDR;
}

This needs to happen in both locations.

On another associated note.

Please can someone tell me if this version of Wire is the latest version, as I've noticed its dated 2012, however on the LeafLabs server http://static.leaflabs.com/pub/leaflabs/maple-ide/
The latest IDE is dated 2013, but contains a completely different implementation of Wire

So either this Repo has not been updated with the latest wire from the static copy of IDE or vice versa

The correct toolchain is now available in debian sid/testing:
https://packages.debian.org/jessie/gcc-arm-none-eabi
https://packages.debian.org/jessie/libstdc++-arm-none-eabi-newlib

I've successfully compiled LibMaple with that. However, there is two errors here:
https://github.com/leaflabs/libmaple/blob/master/libmaple/include/libmaple/libmaple_types.h#L58

First, __unused is already defined, a testing it with ifndef is enough to fix that

The __always_inline is also defined, but it doesn't automatically adds the inline keyword. So, I propose changing all the occurences of __always_inline in the lib maple to inline __always_inline and also adding an ifndef

I can do a PR for that

We wrote a terminal that runs on-board and allows us to interract with the board on run-time easily:
https://github.com/RobotsWar/RobotsWar/blob/master/LibRobotCampus/terminal.h
https://github.com/RobotsWar/RobotsWar/blob/master/LibRobotCampus/terminal.cpp

I know this is more a third-party library, but it is really handy to do some tests.

If you want to give it a try, you can simply clone this:
https://github.com/RobotsWar/Maple/

Go to "skeleton", and then make & make install (it defaults to maple_mini)

Maybe this could be part of libmaple

This forum post from 2012 claims that the assembly delay_us implementation isn't accurate, at least with the maple mini:

http://forums.leaflabs.com/topic.php?id=9450

This claim should at least be investigated/tested.

Hi,
We've made a fork here adding support for OpenCM9.04 and CM900 (Robotis boards):
https://github.com/RobotsWar/libmaple

Do you think this would be interesting to merge it directly in this repository?

We need to rewrite the USB stack and get the virtual serial port right from the ground up.

This has been a major pain point for our users since the beginning, and it needs to go away.

It's also preventing us from writing a serial-only bootloader.

Latest forum report:
http://forums.leaflabs.com/topic.php?id=724

Hi,

When will you release the next version?

Thanks.

I'm working with libmaple in AeroQuad on stm32f4discovery.
I plan to change toolchain from sourcery(included in Maple IDE) to https://launchpad.net/gcc-arm-embedded because I want to use C++11 or something new.

I tried to build AeroQuad's libmaple with launchpad toolchain, but failed on linker.
I tried to build leaflabs's libmaple with launchpad toolchain, succeeded but seems lack of stm32f4 support..

I've noticed some difference in 2 libmaple but seems difficult for me to merge them.

Could someone give me direction, which way to utilize libmaple with launchpad toolchain on stm32f4discovery?

Perry doesn't like how these are implemented and should rewrite them so we are
free for all arduino library GPL source files.

include <pthread.h>

pthread_t pid;
void setup(){}
void loop(){}

error:'pthread_t' undefine.
what can I do if I want to use "pthread.h"?
Is there some way whose function is like ' -lpthread' that I can put in maple-IDE?
Otherwize,I can not use some code like 'int* i=new int;' eather.
Is there someone who knows about this?

forum thread: http://forums.leaflabs.com/topic.php?id=11883
repo: https://github.com/ventosus/libmaple/tree/F3

Here:
https://github.com/leaflabs/libmaple/blob/master/libraries/FreeRTOS/utility/FreeRTOSConfig.h#L76

We can see that 8K RAM are allocated for the heap (this is like 40% of the ram). Can this be reduced safely? How much of this heap are actually used?

Pins that don't work: "Arduino" pin 0, 1, 3, 5

The following code extract has been run with yPinNr changing from 0 to 7

Code extract to reproduce this issue:

byte yPinNr=0; //vary this value

void setup()
{
    pinMode(yPinNr, OUTPUT);
}

void loop()
{
    digitalWrite(yPinNr, HIGH);
    delay(1000);
    digitalWrite(yPinNr, LOW);
    delay(1000);
}

This issue has been resolved in https://github.com/rogerclarkmelbourne/Arduino_STM32. Well, it doesn't work on "Arduino pins" 0 & 1, probably because they're fix configured to use USART0.

Hello,

It looks like the doc is down:
http://leaflabs.com/docs/hardware/maple-mini.html

Apparently, static.leaflabs.com does not resolve anymore
Any idea?

Hi,

If I simply use this code :

    if (SerialUSB.available()) {
        SerialUSB.write(SerialUSB.read());
    }

And I write a python script that just open the port, write some "a" and read the "a"s, if I run this python script many times this cause the crash of the ACM port:

serial.serialutil.SerialException: could not open port /dev/ttyACM0: [Errno 5] Input/output error: '/dev/ttyACM0'

I have the same issue in many cases like this and I don't know exactly what's going on, my computer says :

Mar 27 16:01:38 bob kernel: [17103.998984] xhci_hcd 0000:03:00.0: ERROR no room on ep ring
Mar 27 16:01:38 bob kernel: [17103.998992] cdc_acm 2-1:1.0: acm_tty_open - usb_submit_urb(ctrl irq) failed
Mar 27 16:01:38 bob kernel: [17103.998997] tty_port_close_start: tty->count = 1 port count = 0.

Any idea ?

We can't just extend the bootloader live time for 7 seconds; that's ridiculous.

What would be better? Maybe have libmaple leave a message in memory so the bootloader lives longer when it's reset from the IDE?

We need low-level docs explaining the overall implementation strategy for libmaple, as well as docs pages for the files in libmaple proper.

An initial design document is (temporarily) available here:

http://static.leaflabs.com/mbolivar/libmaple_design/index.html

This needs to be finished and merged into the official /docs/source/ tree.

Hello,

it look like I can't attach interrupt on some channels (for instance, Timer1 channel1), why?

Should be "Maple rev3 (DFU)" and "Maple rev3 (CDC_ACM)", or "Maple rev3 (bootloader)" and "Maple rev3 (virtual serial)" or similar.

library can't be added with sketch-add-zip-library

I guess the folderstructure dos not follow the rules how the folder-structure must be to make the arduino-IDE
able to add a zip-library

Here:
https://github.com/leaflabs/libmaple/blob/master/support/ld/stm32/mem/sram_20k_flash_128k/mem-flash.inc#L3

Why the first 3K of ram are skipped?
I mean, why don't we start at 0x20000000 with 20K?

I have a program which alternately communicates on uart1 and bit-bangs GPIO to talk a certain protocol. When doing the bit-banging, interrupts are turned off.

This hangs very occasionally (~once an hour) on maple mini.

I attached a debugger and caught the hang in action: it's an interrupt flood to USART1 because usart_irq doesn't handle all the exceptions it enables.

The datasheet says:

Bit 3 ORE: Overrun error
This bit is set by hardware when the word currently being received in the shift register is
ready to be transferred into the RDR register while RXNE=1. An interrupt is generated if
RXNEIE=1 in the USART_CR1 register. It is cleared by a software sequence (an read to the
USART_SR register followed by a read to the USART_DR register).

So while the current code will read DR and therefore clear RXNE, it never reads SR to clear ORE. If there is an overrun it will never clear that exception and it will be continually reasserted forever. This is the cause of the hang I saw.

(Obviously this means I'm losing bytes sometimes, and that's fine for my application. YMMV, which is why this is an issue and not a pull request.)

I think loop() never reaches in this example. Maybe some other task named "background" should be introduces.

void setup() {
    // initialize the digital pin as an output:
    pinMode(BOARD_LED_PIN, OUTPUT);

    xTaskCreate(vLEDFlashTask,
                (signed portCHAR *)"Task1",
                configMINIMAL_STACK_SIZE,
                NULL,
                tskIDLE_PRIORITY + 2,
                NULL);
    vTaskStartScheduler();

    // Will not get here unless a task calls vTaskEndScheduler ()
}

void loop() {
   //wrong! never reached 
   // Insert background code here
}

// Force init to be called *first*, i.e. before static object allocation.
// Otherwise, statically allocated objects that need libmaple may fail.
__attribute__((constructor)) void premain() {
    init();
}

int main(void) {
    setup();

    while (true) {
        loop();
    }
    return 0;
}

Hello,
It appear that end() doesn't allow a port to get back its PWM configuration, here is an example:

   // (pin 9 is Serial2 TX)
    Serial2.begin(115200);
    Serial2.write('x');
    Serial2.end();        
   // This doesn't output any PWM
    pinMode(9, PWM);
    pwmWrite(9, 1500);

Something is maybe not cleaned, any idea?

See http://forums.leaflabs.com/topic.php?id=128

TLDR: DFU is not ABORTING upload transactions after a failed packet; it should. Why packets are failing is a separate issue, which can be fixed with better DFU error handling.

On some machines, there is a high DFU failure rate, from which Maple does not gracefully recover. During these botched uploads, Maple gets stuck in the DFU state machine somewhere, and does not accept attempts to retry DFU. The root cause of this is very likely due to some problem with how USB is buffering data. Perhaps some data is being lost and breaking the state machine.

Possible workarounds: reducing the transfer speed, reducing the DFU packet size.

I'm currently working on a project, and I needed to read data contiously from Serial1

My computer opens the USB ACM port and give some order to the board which starts talking very often to Serial1, which means that a lot of "RX" interrupts happens

If I close and open the USB ACM port, and if an RX interrupt on Serial1 is happening, it seems that the board just crashes

Changing the uart priority to 0 seems to fix the issue but I'm not sure about what the problem is exactly