Increase Microcontroller frequency and Speed

Question

I am in process of upgrading the micro-controller of our project from Renesas M16C to RX63N. In our current M16C project we use 16HMz crystal. If in the new micro-controller Rx63N if I use the frequency to 196MHz using PLL, what are the points I need to consider specially in the code.

One thing I understand is the delay function used in the code may need to change according to our new instruction execution time.

Do I required to change or need focus on any other thing i.e. do I need to change anything in the serial communication between my new micro-controller and the external IC.

Do I need to change in my ADC logic? DO I need to change in my logic where I communicate to PC through RS232 chip?

Please guide me which area in my code, I need to give attention when I increase frequency and speed of the micro-controller.

Answer 1

A microcontroller isn't aware of a thing like time; it only knows clock ticks. So the controller's logic can't tell the difference between running at 16 MHz and 192 MHz: a clock tick is a clock tick, and it will do exactly the same in 10 clock ticks for both frequencies.

That means that when actual time is relevant it's up to you to make sure the number of clock ticks gets properly translated to time. Suppose you have a 1 ms timer for the 16 MHz controller. It will give you an interrupt every 16 000 clock ticks, that's once every ms. Run that same code on a 192 MHz controller and you'll still get the interrupt every 16 000 clock ticks, but now that will be 83 µs. So change the timer's value to 192 000. Do this for everything to which real time is relevant. If you don't the 9600 bps UART will run 12 times too fast, so set the prescaler to a 12 times higher value.

The ADC is a bit different. That one does know about time: the measurement capacitor will droop at the same rate whether you run at 16 MHz or at 192 MHz. Or at 1 Hz. While the controller will run (or rather: "stroll") happily at 1 Hz, for the ADC that's too slow. The datasheet will tell you the minimum frequency it needs.

Answer 2

Which area? Everywhere. Anything involving external interfaces -- button input debouncing, ADC or SPI rates and delays, RAM or flash acess times, LCD refresh circuits, etc. Anything involving delay loops, interrupt timing, external flash or ADC delays, etc. And even lots of things you might not expect, like race conditions between isolated pieces of code because something finishes faster than it used to and some time-based event didn't expect it to have updated a variable already.

Of course, this is highly dependent on what your code actually does. If it's all math, you may need to change very little. But most microcontrollers are used to interact with the real world in many ways. And the real world won't change speed to match!

Answer 3

If you increase the clock frequency of your micro, then yes, you will need to adjust any features of your code that rely on it being a certain frequency. This may be many things or not, depending on your design.

Any asynchronous comms like USART, peripherals like ADC/DAC are an obvious concern here. SPI and I2C will just be at a higher clock rate, which may or may not be desired (or may not work if the bus is borderline at the original frequency) Memory interface times, functions that rely on a certain clock rate (like the delay you mention may be affected), etc , etc.
You get the idea.

To determine what you need to do, you will need to examine your code carefully. Depending on how it is written it may adapt easily or not.
For instance, often a macro is used to calculated the divider ratio for a peripheral so all that needs to be changed is a #define of the clock frequency. If your code uses this type of technique then adjusting will be less painful - I would imagine any Renasas libraries will do this, so it will hopefully just be a case of reading the library documentation.
Here is an example of some UART setup code (part of the USART init function for an STM32 ARM peripheral library I happen to be using currently) Notice the final BRR register value is based on the apbclock rate and the value of USART_BaudRate (passed in a struct to the init function) This means any changes in clock frequency are handled as long as a global define (which is used in the RCC_GetClocksFreq() function) is updated:

/*---------------------------- USART BRR Configuration -----------------------*/
  /* Configure the USART Baud Rate -------------------------------------------*/
  RCC_GetClocksFreq(&RCC_ClocksStatus);
  if (usartxbase == USART1_BASE)
  {
    apbclock = RCC_ClocksStatus.PCLK2_Frequency;
  }
  else
  {
    apbclock = RCC_ClocksStatus.PCLK1_Frequency;
  }

  /* Determine the integer part */
  if ((USARTx->CR1 & CR1_OVER8_Set) != 0)
  {
    /* Integer part computing in case Oversampling mode is 8 Samples */
    integerdivider = ((25 * apbclock) / (2 * (USART_InitStruct->USART_BaudRate)));    
  }
  else /* if ((USARTx->CR1 & CR1_OVER8_Set) == 0) */
  {
    /* Integer part computing in case Oversampling mode is 16 Samples */
    integerdivider = ((25 * apbclock) / (4 * (USART_InitStruct->USART_BaudRate)));    
  }
  tmpreg = (integerdivider / 100) << 4;

  /* Determine the fractional part */
  fractionaldivider = integerdivider - (100 * (tmpreg >> 4));

  /* Implement the fractional part in the register */
  if ((USARTx->CR1 & CR1_OVER8_Set) != 0)
  {
    tmpreg |= ((((fractionaldivider * 8) + 50) / 100)) & ((uint8_t)0x07);
  }
  else /* if ((USARTx->CR1 & CR1_OVER8_Set) == 0) */
  {
    tmpreg |= ((((fractionaldivider * 16) + 50) / 100)) & ((uint8_t)0x0F);
  }

  /* Write to USART BRR */
  USARTx->BRR = (uint16_t)tmpreg; 

Answer 4

Another thing to specifically call out is any code that bit-bangs port pins to implement hand shake with external logic. This could include talking to I/O expansion shift registers, LCD displays, serial EEPROMs, and any other logic or ICs that may have timing requirements. These timing requirements may include - pulse widths, pulse rates, setup times, hold times and edge to edge relationships between various bit-banged I/Os.