Atmel Start is not the answer: My experience and some feature requests

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For context: I use Atmel Start differently than I used ASF3. In ASF3, I would constantly switch modules in and out, change which modes they used (example: delay systick vs cycle). I was generally ok with this method of using software modules. It worked for the most part. But now I am using ASF4. I don't want this post to be entirely negative, so I'm going to frame this as a feature request.

 

The way I currently use Atmel Start is I generate the project with the drivers and middleware I think I need, and if I end up needing something later on I manually add it myself. I realize that Atmel Start doesn't want you to do this, but theres a bunch of reasons I have to do this, which I'll elaborate on later. For now, here's the project:

 

Hardware: SAME54 Xplained Pro

Goals: A 1ms timer (tcc), a button, and a debug terminal over uart.

 

This seems pretty simple, right? Well, yeah. Except not really. The point of this post is to show that Atmel is moving from an actual HAL based approach (like arduino or mbed) and moving to code generation is the wrong way to go about it.

 

It seems the hardware is abstracted away in a HAL, which is fine I guess. But the reality is that a lot of the HAL isn't actually configurable from the front end. The code is generated from Atmel Start, like in MPLAB and Harmony. Even this I would be OK with, but the problem lies in incompleteness. After I have generated a project, I only have the files available to me which the generator has... generated. This is fine. After this I would assume everything would be configurable via config files in the config folder. I promise this is going somewhere.

 

So if I generate a project with an external interrupt, and I forgot to actually assign a pin to it, you'd think it would be as easy as changing some config settings like so:

 

Changing the original:

// <e> Interrupt 5 Settings
// <id> eic_arch_enable_irq_setting5
#ifndef CONF_EIC_ENABLE_IRQ_SETTING5
#define CONF_EIC_ENABLE_IRQ_SETTING5 0
#endif

// <q> External Interrupt 5 Filter Enable
// <i> Indicates whether the external interrupt 5 filter is enabled or not
// <id> eic_arch_filten5
#ifndef CONF_EIC_FILTEN5
#define CONF_EIC_FILTEN5 0
#endif

to

// <e> Interrupt 5 Settings
// <id> eic_arch_enable_irq_setting5
#ifndef CONF_EIC_ENABLE_IRQ_SETTING5
#define CONF_EIC_ENABLE_IRQ_SETTING5 1
#endif

// <q> External Interrupt 5 Filter Enable
// <i> Indicates whether the external interrupt 5 filter is enabled or not
// <id> eic_arch_filten5
#ifndef CONF_EIC_FILTEN5
#define CONF_EIC_FILTEN5 1
#endif

And I also needed to add the following to the bottom:

#define CONFIG_EIC_EXTINT_MAP {5, PIN_PD10},

Important Parts

And so far, so good. I also added the driver_init code necessary and enabled the irq just like in the example. But that wasn't enough! I also had to track down differences and I found this in ./hpl/eic/hpl_eic.c :

#define EXT_IRQ_AMOUNT 0

So it baffles me that such a definition would be located in the hardware layer of a HAL in a .c file. But it doesn't end there. It gets far more frustrating.

After making this change (changing 0 to a 1), it still didn't work. Thankfully, this ends soon.

 

After some more digging, I found this exact constant redefined to 0 in ./hal/src/hal_ext_irq.c:

#define EXT_IRQ_AMOUNT 1

This is a HAL... with an entire system of config files. Why are these not located in the config file? I don't understand, it is more work for the users and maintainers to have the settings defined this way. And it makes for less modular code inside of the hardware layer of a HAL. These mistakes can be overlooked, sure. I get it. But then

I found that this code was generated when I set EXT 5 to be enabled (inside of _ext_irq_init):

    NVIC_DisableIRQ(EIC_5_IRQn);
    NVIC_ClearPendingIRQ(EIC_5_IRQn);
    NVIC_EnableIRQ(EIC_5_IRQn);

This is what bothers me the most. This code is specific to the E54. In the hardware layer. Why is this not guarded by macros and compiled if the ext channel is enabled?

 

 

Conclusion:

There is generated code in ASF4 that makes no sense in regards to the system it is in. The killer part is if I were to use ASF4 the way Microchip wants me to, via the code generator, this would be removed and every time I wanted to change a pin on a different EIC channel, I would need to use atmel start and it would manually add these lines of code. But this doesn't make ANY sense. It should be as simple as adding config settings for the pins and channels because it is easier and more intuitive for the maintainers and the users. There are parts that are easier to macro as config settings in a config file, rather than being defined in every .c file it is used in:

#define EXT_IRQ_AMOUNT 1

There are parts that can be added beforehand and macro'd out via a config setting macro: (This code does not exist in ASF4. Instead it requires you to regenerate the project files instead of just doing this)

#if CONF_EIC_ENABLE_IRQ_SETTING0
    NVIC_DisableIRQ(EIC_0_IRQn);
    NVIC_ClearPendingIRQ(EIC_0_IRQn);
    NVIC_EnableIRQ(EIC_0_IRQn);
#endif
#if CONF_EIC_ENABLE_IRQ_SETTING1
    NVIC_DisableIRQ(EIC_1_IRQn);
    NVIC_ClearPendingIRQ(EIC_1_IRQn);
    NVIC_EnableIRQ(EIC_1_IRQn);
#endif
#if CONF_EIC_ENABLE_IRQ_SETTING2
    NVIC_DisableIRQ(EIC_2_IRQn);
    NVIC_ClearPendingIRQ(EIC_2_IRQn);
    NVIC_EnableIRQ(EIC_2_IRQn);
#endif
#if CONF_EIC_ENABLE_IRQ_SETTING3
    NVIC_DisableIRQ(EIC_3_IRQn);
    NVIC_ClearPendingIRQ(EIC_3_IRQn);
    NVIC_EnableIRQ(EIC_3_IRQn);
#endif
#if CONF_EIC_ENABLE_IRQ_SETTING4
    NVIC_DisableIRQ(EIC_4_IRQn);
    NVIC_ClearPendingIRQ(EIC_4_IRQn);
    NVIC_EnableIRQ(EIC_4_IRQn);
#endif
#if CONF_EIC_ENABLE_IRQ_SETTING5
    NVIC_DisableIRQ(EIC_5_IRQn);
    NVIC_ClearPendingIRQ(EIC_5_IRQn);
    NVIC_EnableIRQ(EIC_5_IRQn);
#endif
#if ...
#endif

But if I add these changes myself, they'll just be replaced the next time I have to reconfigure. And then I have to reconfigure every time I change to a different channel, which wouldn't be a huge deal if the process wasn't painfully slow while also deleting changes I make in other places.

 

So to finish off my post, @ whoever is maintaining this HAL, there is no reason for this. Please consider moving away from code generation and towards real, actual HALs (if we have to move that direction). MPLAB sucks. Don't force ASF to be like it.

 

PS: These weren't the only instances of this that I had to manually change. These were just the glaringly bad ones (for this project)

im a penguin

Last Edited: Sat. Feb 15, 2020 - 04:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agree, many configurations are not available.

You can't completely control your peripherals. Just use the HAL program generated by Atmel Start.

If I want more, I need to operate the hpl or even hri library to get everything I want.

Just code