SparkFun Forums

[stamstamnitzan]

Hello everyone,
I was wondering how can I enable the turbo mode?
And, what are the cons of using it over long periods of time?

Have a great day

[robin_hodgson]

Use these Ambiq HAL calls to turn it on:

Code: Select all

  // Enable burst mode to run at 96 MHz
  am_hal_burst_avail_e peBurstAvail;
  am_hal_burst_mode_e peBurstStatus;
  am_hal_burst_mode_initialize(&peBurstAvail);
  am_hal_burst_mode_enable(&peBurstStatus);

I am not aware of any limitations regarding burst mode. Run it that way forever if you want. The only issue is that it takes about 5 times the power to go twice as fast. See this post for details viewtopic.php?p=208507#p208507

[stamstamnitzan]

Thank you for the reply, I am about to receive my unit next week
Two questions regarding your answer:
Where do I paste this section too?
Where did you find this information? I couldn't find documentation..

[robin_hodgson]

If you are using the Arduino environment, just paste that sample code in your setup() function. You can switch between normal and turbo whenever you want. If battery life is important, leave the processor in normal mode. If your application needs to do some serious crunching for a bit of time, you might want to enable turbo mode, do the crunching, and turn it off again to save power. Honestly, I would bet that 95% of applications don't actually need Turbo mode.

To figure out what the HAL can do for you, the best thing to do is to download it from the Ambiq website and scan over the Ambiq HAL source code header files. It is well documented and easy to read.

Anything in the HAL is available from within Arduino: if you read about a HAL function in the Ambiq source, just call it like I did in the example from the previous post and the Sparkfun Arduino environment will take care of linking it all together. It's quite nice. For the most part, the Arduino environment already takes care of calling the HAL for you. For example, you could call the HAL to do serial IO, but the Arduino environment already implement the Serial class. Using the Arduino classes makes it easier to port in Arduino software libraries written by 3rd parties.

[stamstamnitzan]

I found and read many headers, these are well documented.
It is very interesting to dig into the codes behind the code!

Let's take a case study to see if I understand, say I have Artemis OpenLog, can I declare AM_HAL_GPIO_PINCONFIG(unit32_t 11, am_hal_gpio_pincng AM_HAL_PIN_PULLUP_6K) ?
Would that mean pin 11 is pullup with resistor 6K?

[robin_hodgson]

My advice is to read the Apollo3 data sheet regarding GPIO to begin with. There are lots of special cases about what pads can do what things. Most GPIOs only support a 'weak' pullup. Some of the I2C pads support specifying a pullup resistor size, as per your example. There is one special GPIO pad that can source up to 50 milliamps continuous, and another that can sink as much as 50 milliamps continuous.

The biggest issue is that the Apollo3 and its data sheet deal with 'pad' numbers, not pin numbers. The Arduino world uses 'pin' numbers. Back in the original Arduino days, they literally were the pin numbers for the specific AT Mega chip they used. Now that Arduino is supported by tons on non AT Mega chips, Arduino still uses 'pin' numbers even though they have no relation to the pins on the processor being used underneath. It all results in a layer of indirection and ongoing confusion. Personally, I write all my code referring to 'pads' and pad numbering , and skip the Arduino notion of 'pins'. I download the Sparkfun schematics for their boards so that I can map their silkscreen labeling to the actual pad numbers and go from there in my code.