news: Arduino STAR OTTO development board

Any other STM32 based boards
User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: news: Arduino STAR OTTO development board

Post by Slammer » Thu Jun 16, 2016 12:30 am

They reorganized the folders, but if you see carefully many files for peripherals are almost the same with libmaple (eg. usart)
The hal/cmsis sources are included, but I don't know if they are used and for what.
It seems to me like a work in progress, replacing functions of libmaple with hal. It is interesting......

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: news: Arduino STAR OTTO development board

Post by GrumpyOldPizza » Thu Jun 16, 2016 12:35 am

Slammer wrote:They reorganized the folders, but if you see carefully many files for peripherals are almost the same with libmaple.
The hal/cmsis sources are included, but I don't know if they are used and for what.
It seems to me like a work in progress, replacing some functions of libmaple with hal. It is interesting......
The HAL is really mostly used for USB (and SPI). The rest is pretty much verbatim the STM32DUINO F4 port. This probably never was used as is. The dfu-util upload looks problematic, which leads me to believe they only ever tried openocd. There are also way to many references to the DISCOVERY board.

There are CMSIS sources there, but it seems to me that they did not even change simple things like the ISR vector naming, so that the HAL would actually work.

Not sure what I am looking at ... work in progress ... or simply to show that they were able to grab somebody else's work and declared it as theirs ?

User avatar
RogerClark
Posts: 6368
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Thu Jun 16, 2016 12:37 am

If anyone wants a play with it, I have made a core that will work with IDE 1.6.9

http://rogerclark.net/uploads/star_otto_core.zip

just unzip into your arduino hardware folder

Seems to compile OK.

User avatar
sheepdoll
Posts: 232
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: news: Arduino STAR OTTO development board

Post by sheepdoll » Thu Jun 16, 2016 12:39 am

martinayotte wrote:I don't see any Leaflabs legacy files there, they removed all libmaple folders.
There are still some aeroquad32 credits in otto.h. In fact it still is a _BOARD_DISCOVERY_F4_H_.

Looks to be a QED(*) port rather than structured from the ground up.

(*) quod erat demonstrandum or in English Quick and Dirty although some would say quite easily done.

User avatar
RogerClark
Posts: 6368
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Thu Jun 16, 2016 12:52 am

Perhaps its what they used to compile the demo at Maker Faire

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: news: Arduino STAR OTTO development board

Post by GrumpyOldPizza » Thu Jun 16, 2016 12:43 pm

RogerClark wrote:Perhaps its what they used to compile the demo at Maker Faire
I am not sure this code is really working ... Here some excerpts from the SPI driver.

Code: Select all

void SPIClass::beginTransaction(SPISettings settings) {
  // do nothing
}

void SPIClass::endTransaction() {
   HAL_SPI_DeInit(&hSPIx);
}

void SPIClass::transfer(void *buf, size_t count) {
    uint8_t rxdata;
    HAL_SPI_TransmitReceive(&hSPIx, (uint8_t*)buf, (uint8_t*)&rxdata, count,5000);
}
So SPI.beginTransaction() does not set the SPI clock at all. SPI.endTransaction() disables the SPI peripheral alltogether (while beginTransaction() doesn't enable it again). Well. and the SPI.transfer() function will cause a stack corruption if "count != 1".

Ah, and there there is this interesting approach to have SPISettings call HAL_SPI_Init(&hSPIx), which means you cannot really have multiple settings, and if you do it's pretty much random which one gets applied.


Looking at the Wire/I2C code, it seems to borrow a lot of it's code from MBED without attributing:

Code: Select all

int TwoWire::i2c_master_start()
{
    I2C_TypeDef *i2c = (I2C_TypeDef *)I2cHandle.Instance;

    int timeout;

    // Clear Acknowledge failure flag
    __HAL_I2C_CLEAR_FLAG(&I2cHandle, I2C_FLAG_AF);

    // Wait the STOP condition has been previously correctly sent
  // This timeout can be avoid in some specific cases by simply clearing the STOP bit
    timeout = FLAG_TIMEOUT;
    while ((i2c->CR1 & I2C_CR1_STOP) == I2C_CR1_STOP) {
        if ((timeout--) == 0) {
            return 1;
        }
    }

    // Generate the START condition
    i2c->CR1 |= I2C_CR1_START;

    // Wait the START condition has been correctly sent
    timeout = FLAG_TIMEOUT;
    while (__HAL_I2C_GET_FLAG(&I2cHandle, I2C_FLAG_SB) == RESET) {
        if ((timeout--) == 0) {
            return 1;
        }
    }

    return 0;
}

Code: Select all

inline int i2c_start(i2c_t *obj)
{
    I2C_TypeDef *i2c = (I2C_TypeDef *)(obj->i2c);
    int timeout;

    I2cHandle.Instance = (I2C_TypeDef *)(obj->i2c);

    // Clear Acknowledge failure flag
    __HAL_I2C_CLEAR_FLAG(&I2cHandle, I2C_FLAG_AF);

    // Wait the STOP condition has been previously correctly sent
	// This timeout can be avoid in some specific cases by simply clearing the STOP bit
    timeout = FLAG_TIMEOUT;
    while ((i2c->CR1 & I2C_CR1_STOP) == I2C_CR1_STOP) {
        if ((timeout--) == 0) {
            return 1;
        }
    }

    // Generate the START condition
    i2c->CR1 |= I2C_CR1_START;

    // Wait the START condition has been correctly sent
    timeout = FLAG_TIMEOUT;
    while (__HAL_I2C_GET_FLAG(&I2cHandle, I2C_FLAG_SB) == RESET) {
        if ((timeout--) == 0) {
            return 1;
        }
    }

    return 0;
}

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: news: Arduino STAR OTTO development board

Post by GrumpyOldPizza » Thu Jun 16, 2016 2:03 pm

Ah, if anybody wants to try this on a DISCOVERY board, her the StAr_write.bat script:

Code: Select all

waitfor 0 /t 1 2> NUL
%1\dfu-util.exe -l -d %2 -a %3 -s %4 -D %5
%1\dfu-util.exe -l -d %2 -a %3 --reset-stm32

User avatar
RogerClark
Posts: 6368
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Thu Jun 16, 2016 9:14 pm

I removed the HAL folder and as far as I can tell, it still complies a blank sketch, so I am not sure the HAL is used at all.


I have a F4 Discovery board, but I am not sure its worth spending any time to see if this core works on that board, as it really looks like an interim silution until they rewrite again from scratch using the HAL

User avatar
RogerClark
Posts: 6368
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: news: Arduino STAR OTTO development board

Post by RogerClark » Thu Jun 16, 2016 9:45 pm

Update.

I just received an email from Francesco, letting me know that their code was based on my repo.
But there were no other technical details.

@grumpyoldpizza

I have replied, letting him know about your core, as I suspect it would be possible to modify it to work for the F4, and reminding him about @sheepdoll's HAL MX based core.


i have no more information about this board, as this is the first email I have had from Arduino.org since Maker Faire ( which was almost a month ago).

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: news: Arduino STAR OTTO development board

Post by GrumpyOldPizza » Fri Jun 17, 2016 3:40 am

RogerClark wrote: @grumpyoldpizza

I have replied, letting him know about your core, as I suspect it would be possible to modify it to work for the F4, and reminding him about @sheepdoll's HAL MX based core.
F4 and L4 are not that different. Only DMA and I2C come to mind as biggies. There is the RX timeout missing on USART (quick handy for circular DMA). QSPI and SDIO are identical. So at the end of the day, it should be fairly straight forward. Perhaps not optimal, as for L4 the goal was to minimize power. For a 180MHz F4 that is probably not an issue ;-)

Ah, BTW a microSD addon for Dragonfly is in the works ... using SDIO. So that should be plenty fast.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests