LeafLabs Garden

A place to share, learn, and grow...

1. 

   joe_c
   Member

   Hi all; I'm new to the club. I just received my Maple r5 this week. I wanted to get a feel for how fast this board so I created a quick program to toggle an I/O pin. The main loop of the program is empty except for a togglePin() command.
   I measured the square wave out with my oscilloscope. I was surprised to find that the frequency was not the fastest I'd seen. I repeated the experiment with any processor I could find. Here are the results:

   Fastest, an AtXmega128, output = 3 Mhz, code was created with a commercial compiler Codevision. Clocked at 32 Mhz.
   Maple was next at 810khz, code was created with the Leaf compiler.
   Arduino UNO, output = 120 khz, code was created with Arduino V22.
   Arduino MEGA 2560 = 75 khz.

   Could this be a result of compiler efficiencies? register width? I am only a hobby level programmer and I suspect my tests are not valid. Any thoughts?

   Joe C.

   Posted 4 years ago #
2. 

   robodude666
   Member

   Performance has been discussed previously in the forums. I recommend taking a look at the Low Level pin manipulation and High-Speed GPIO Access? threads.

   Note that in the Low Level pin manipulation thread I used uint16_t bit9 = BIT(9); in attempt to optimize the toggle. This is WRONG. It turns out the compiler will evaluate any constants so using 1<<9 or BIT(9) as snigelen showed is preferred; it makes for cleaner code and saves a memory read.

   The reason for togglePin, along with digitalWrite and the remaining wirish functions (the same applies to Arduino's functions and wiring - not just Maple), are lacking in performance is because of the overhead incurred to make the functionality simpler to use. When you call togglePin you're really calling:

   void togglePin(uint8 pin) {
       if (pin >= BOARD_NR_GPIO_PINS) {
           return;
       }
   
       gpio_toggle_bit(PIN_MAP[pin].gpio_device, PIN_MAP[pin].gpio_bit);
   }

   You must go through a pin validation, which in itself is a few assembly instructions. You must then access the corresponding gpio device and bit for that particular digital pin which is a memory read (and more "expensive"). You then pass these arguments to the gpio_toggle_bit function which is a jump assembly command (though the inline attempts to optimize it). Within gpio_toggle_bit:

   static inline void gpio_toggle_bit(gpio_dev *dev, uint8 pin) {
       dev->regs->ODR = dev->regs->ODR ^ BIT(pin);
   }

   there is a GPIO read, a binary shift, an OR, and a GPIO write. All of this takes some time. What could be a 18MHz square wave turns into a ~700kHz square wave.

   Also, the ATXMega, like discussed in the High-Speed GPIO Access thread, requires only 1 cycle per GPIO read/write. The STM32F103 series requires 2 cycles per write. There are ways to optimize performance, as discussed in the linked-to threads. Ultimately, however, the STM32F103's 72MHz clock will make it a faster MCU. It is capable of doing computations much faster than a 32MHz ATXMega and will ultimately result in faster execution even if the GPIO writes takes 2 cycles.

   Ultimately, you don't want to toggle bits like this manually. Use hardware features whenever possible. If you need a square wave, use timer-based PWM generation functionality of the STM32. You'll get much better performance. If you need to toggle a heartbeat LED, using toggleLED, and digitalWrite will suffice. If you need high-speed GPIO for reading/writing to external devices consider using the DMA controller to make sure you're getting the full 18MHz capability the GPIO can output.

   -robodude666

   Posted 4 years ago #
3. 

   joe_c
   Member

   I thought I would get better performance from assembly. I wanted to see what the high level language would give me. You've given me a lot to think about. Thank you for the insightful post.

   Joe C.

   I just looked at your link. Sorry for the duplicate post. Next time I will dig a little further.

   Posted 4 years ago #
4. 

   robodude666
   Member

   It's okay. bbPress doesn't have the best search. Sometimes it's hard to find something without knowing exactly what the thread's name is.

   Although writing your application in high-optimized assembly would yield the best possible performance, it would also yield the most hair ripped out of your head. Using the low-level libmaple c library will yield much better performance than the wirish equivalents, and is generally good enough. Especially if you optimize your program to hide the extra clock cycles required for back-to-back GPIO access.

   Posted 4 years ago #
5. 

   gbulmer
   Moderator

   joe_c - what is it you are trying to do?

   Unless you are familiar with Thumb2 assembler, you will be spending a significant amount of time trying to produce better code than the compiler, and may discover that it is very hard, or you can't. ARM was part of the wave of RISC processors which were designed to be targeted by high-level language compilers (typified by MIPS).

   I am a big fan of Jon L Bentley's Writing Efficient Programs:
   http://www.amazon.com/Writing-Efficient-Programs-Prentice-Hall-Software/dp/013970244X
   (I used to teach undergrad and post grad CS & Software Engineering)

   Bentley suggest a six-layer model to consider efficiency, three are software and three hardware.
   Each layer typically yields a 10x efficiency gain.
   The effectiveness of translation of program code to binary is only one of the three software layers, and the compiler is likely to be pretty good (the C compiler has been developed and improved for many, many years). So it is often easier to go look at a different layer to get a significant efficiency improvement.

   Directly accessing the hardware is straightforward if you are accustomed to C.
   There are a bunch of helpful pre-defined macros in the libmaple gpio.h header which correspond to the General Purpose I/O (GPIO) ports.

   So you could write:
   (unsigned int*)0x40010800+0x10 = 0x00000010; /* set pin A5 via GPIO port A, BSRR register */
   or
   GPIOA_BASE->BSRR = 0x00000010; /* set pin A5, which is the LED pin, via GPIO port A, BSRR register */
   Both C statements compile to the same instructions. It is a short sequence because the compiler is dealing with constants which it can calculate for you at compile time.

   Once the value of GPIOA_BASE->BSRRand 0x00000010 is loaded into registers,
   the GPIOA_BASE->BSRR = 0x00000010 is one instruction.

   So toggling pins with:
   GPIOA_BASE->BSRR = 0x00000010; /* set pin A5, which is the LED pin, via GPIO port A, BSRR register */
   GPIOA_BASE->BSRR = 0x00100000; /* clear pin A5, which is the LED pin, via GPIO port A, BSRR register */
   GPIOA_BASE->BSRR = 0x00000010; /* set pin A5, which is the LED pin, via GPIO port A, BSRR register */
   GPIOA_BASE->BSRR = 0x00100000; /* clear pin A5, which is the LED pin, via GPIO port A, BSRR register */
   GPIOA_BASE->BSRR = 0x00000010; /* set pin A5, which is the LED pin, via GPIO port A, BSRR register */
   GPIOA_BASE->BSRR = 0x00100000; /* clear pin A5, which is the LED pin, via GPIO port A, BSRR register */
   GPIOA_BASE->BSRR = 0x00000010; /* set pin A5, which is the LED pin, via GPIO port A, BSRR register */
   GPIOA_BASE->BSRR = 0x00100000; /* clear pin A5, which is the LED pin, via GPIO port A, BSRR register */

   Should generate a sequence which is as quick as the hardware can go. (This technique lets you toggle some or all 16 pins in a port)

   I'd recommend reading the libmaple source code, which is Open Source and available, and use some of its techniques to make your life easier.
   You can get the source at https://github.com/leaflabs/libmaple

   These threads give some concrete advice on how to do I/O quickly
   http://forums.leaflabs.com/topic.php?id=517
   http://forums.leaflabs.com/topic.php?id=718
   http://forums.leaflabs.com/topic.php?id=737
   http://forums.leaflabs.com/topic.php?id=774

   I have got 18MHz on my oscilloscope, using that somewhat ugly repetitive code, and 12MHz with more normal looking stuff.

   Get the latest copy of the STM32F103 manual "RM0008 Reference manual", currently:
   http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf
   It describes every peripheral in loving detail, and also gives an overall memory map.
   If you want to change or toggle pins quickly, have a look at Section 9 "General-purpose and alternate-function I/Os (GPIOs and AFIOs)". Each pin of each GPIO port has a memory address, so you can read/write in a single 2 cycle instruction. You'll need to lookup 'bit-banding. and may need an ARM technical reference manual.

   Also get a copy of the STM32F103x8/STM32F103xB Datasheet if you have a standard Maple:
   http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00161566.pdf
   of the STM32F103xC/xD/xE Datasheet if you have a RET6:
   http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00191185.pdf

   These gives the memory map of the STM32F103 that is on your board.

   Please post questions if you'd like some more discussion.

   (full disclosure: I am not a member of LeafLabs staff)

   Posted 4 years ago #
6. 

   joe_c
   Member

   gbulmer; I have no specific project in mind. At work, I am a technician only in a department that largely uses Atmel. I am not a programmer except at the hobbiest level. I leave that work to the engineers and programmers in my department. I do have some influence at the hardware level.

   Currently we are using AtMega 2560/61's for the top of the line processor in our products. Before we move into AtXmega, I wanted to see if there was a better processor and tool-chain available. I hoped that ARM and the 32 bit wide architecture would be a winner.

   My quick thumbnail test was to flip an I/O bit and measure the resultant clock frequency, testing the processor and environment. It is a flawed test to be sure.

   I am interested in your (and robodude's) comments. I plan to read them and educate myself.

   Thanks;
   Joe C

   Posted 4 years ago #
7. 

   gbulmer
   Moderator

   joe_c -

   My quick thumbnail test was to flip an I/O bit and measure the resultant clock frequency, testing the processor and environment. It is a flawed test to be sure.

   If that's what is important to you folks, it's a good test!

   The main flaw is using the wirish library.
   Wirish is based on the Arduino's 'Wire' library, where simplicity and ease of use are primary requirements, and performance suffers.

   Maple also has the lower level libmaple library. That often uses C++ inline (e.g. gpio_write_bit) to remove the overhead of instruction to do a function call, and hence can get significantly faster when the function is small because the function calling instructions may take much more time than the actual work.

   The Atmel XMega is cleverly designed. Many load or store instructions take a single cycle, where the ARM Cortex-M3 may take two. So the performance may be quite close on programs where 8-bit data dominates the work load, even thought the STM32F runs at 72MHz. (Sadly, Atmel seems to have hired the same moron that ST hired to revamp their web site, so I can't find the XMega datasheets and manuals, and I don't have them on this laptop)

   I think the STM32F has some better peripherals, but that might not be a big enough difference to matter fort your applications, and if folks are comfortable with the Atmel peripherals the Xmega may be easier to use.

   The Cortex-M3 handles 8, 16 or 32-bit data at a time vs 8 bit data for the Xmega, so the STM32F may win quite strongly in some areas. For example, there is a fixed point arithmetic library which likely runs on the STM32F between 2-8 times faster than the Xmega (I haven't done the measurements, that is a SWAG).

   One area which I prefer on the STM32F, which was a pain on the ATmega is read-only data (e.g. strings). The STM32F has a single address space, so read-only data stored in flash is handled by the same instructions as data stored in RAM. On the ATmega, that is not the case. Data stored in Flash is not the same as data stored in RAM, so you end up writing two copies of some functions (as I wrote above, I can't find the Xmega manuals which might confirm or deny that problem still exists, so I may be wrong, and the Xmega may have fixed that problem, but I don't think so)

   Anyway, try the code:
   

   GPIOA_BASE->BSRR = 0x00000010; /* set GPIO port A pin 5, LED pin 13, via BSRR register */
   GPIOA_BASE->BSRR = 0x00100000; /* clear GPIO port A pin 5, LED pin 13, via BSRR register */

   (in a large block) and see how fast it toggles a pin. Then do the same on the Xmega. It should be very close.

   Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.