LeafLabs Garden » Topic: Sure Electronics 3216 bicolor display

LeafLabs Garden » Topic: Sure Electronics 3216 bicolor display http://forums.leaflabs.com/topic.php?id=1441 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:25:26 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8575 Sat, 10 Mar 2012 08:06:03 +0000 gbulmer 8575@http://forums.leaflabs.com/ lonewolf - my further analysis ... Clearly, a frame rate above about 60 frames/second is not necessary because of human's relatively slow persistence of vision. We just won't see any benefit above that sort of rate. So I assume frame rate is an indirect measure of how much time is available to do other things, like render text or images. Assuming the UART interface is fast enough to reach 60 frames/second, then the question becomes does this approach leave more free time for the processor to do other things? Agreed? There are three ways to use the UART: 1. Direct, polled UART 2. Interrupt driven 3. DMA driven 3. DMA driven This technique isn't possible on Arduino's AVR, but both the Maple STM32 and the ChipKit PIC32 could do this. Assuming the 'frame buffer' can be arranged conveniently, then DMA should use the least processor time, and leave the most 'free CPU time' for other processing. If you are lucky, it may be possible to set up DMA to continuously refresh the LED controller without any processor intervention, ever. So this has the potential of 'orders of magnitude' less CPU load than any other technique. 1. Direct, polled UART. I assume this uses the most CPU time to refresh the display controller of the three approaches, but, depending on the baud rate, it might still be comparable with bit-banging. A 'screen refresh' could be triggered by a timer interrupt. 2. Interrupt driven This will take a bit of estimation. I'll assume the frame buffer data dominates, and otherwise the UART uses a similar number of bytes. Sending a single bit, using bit-band addressing, is, roughly: <pre><code>// send one bit *_data = (bits & msb) ? 1 : 0; *_wr = 0; *_wr = 1; msb >>= 1;</code></pre> - three pin writes are 3 x 2 cycle instructions - <code>msb >> = 1</code> is 1 cycle - <code>(bits & msb) ? 1 : 0</code> is at least 1 cycle So let's call that 8 cycles/bit. Of course, it is a bit slower in reality because of loop overhead, and this may be faster than the HT3216 can receive data, but this'll do for a quick and dirty comparison (if the UART has lower overhead, then these other bit-banging overheads tilt the balance further towards the UART). Taking and returning from an interrupt is 12+12 cycles. writing a byte to the UART might be <pre><code>// write one byte to UART UART_DATA_BUFFER = *current_buffer++; // must be a byte because the interrupt was on if (current_buffer >= BUFFER_END) disable_UART_interrupt;</code></pre> So, assuming the buffer contains all the data, this will get called repeatedly, until the whole 'frame buffer' has been sent. I estimate: - load <code>current_buffer</code> - worst case 4 cycles - load <code>UART_DATA_BUFFER</code> - worst case 4 cycles - load <code>*current_buffer</code> - 2 cycles - store <code>*current_buffer</code> to <code>UART_DATA_BUFFER</code> - 2 cycles - <code>current_buffer++</code> - 2 cycles to store - load <code>BUFFER_END</code> - worst case 4 cycles - compare <code>current_buffer</code> with <code>BUFFER_END</code> - 1 cycle - return without disabling interrupts (the common case) 1 cycle that ~= 20 cycles interrupt (most common case) 44 cycles, which is less than bit banging 6 bits So even this may be faster than bit banging, but it is so close, it'd take careful analysis. But it may be possible to do better!-) The UART has two buffers, a data buffer, and the shift register which shifts out the data. According to RM0008, section 27.3.2 'Transmitter', the value written into the data register gets immediately copied to the shift register, if their is no active transmission. So if the interrupt can be arranged to happen at the end of a transmission, two bytes can be copied into the UART for each interrupt. The interrupt service routine will be slightly longer, but, I guess something like: test UART data register empty, or that there is no transmission - about 6 cycles load data byte if there is one, and store to UART data register - about 6 cycles So for about 12 more cycles, a total of about 56 cycles, 16 bits are sent via the UART, in the time that bit-banging sends 7 bits. So this might be significantly faster, i.e. less CPU load, than bit-banging. The STM32 has, in effect, a two byte buffer, so this could be quite efficient. The PIC32 has a 4 or 8 byte deep buffer, and so should work even better. Using interrupts might work on AVR's with more than one USART, but the cost of AVR instructions will be very different, and so may be much worse. Observation: the fastest technique on an 8bit AVR may be far from optimal on a 32bit processor, with more peripherals and DMA support. gbulmer on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8568 Fri, 09 Mar 2012 22:24:29 +0000 gbulmer 8568@http://forums.leaflabs.com/ Is this the device: <a href="http://www.sureelectronics.net/goods.php?id=972" rel="nofollow">http://www.sureelectronics.net/goods.php?id=972</a> The manual (at that page) says it is a UART device. If that is true, you could use a Maple UART or USART to talk to it, and remove the bit banging. This isn't an option with an Arduino as the USART is connected to the USB interface, but the extra peripherals is one reason to use Maple. gbulmer on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8564 Fri, 09 Mar 2012 20:46:19 +0000 gbulmer 8564@http://forums.leaflabs.com/ lonewolf - do you have any measurements about which functions, or lines dominate the run time? I looked at: <pre><code>void _writebits (register byte bits, register byte msb) { while (msb) { !!(bits & msb) ? _data_set() : _data_clr(); _wr_clr(); _wr_set(); msb >>= 1; } }</code></pre> If this were something like: <pre><code>static inline void _writebits (register byte bits, register byte msb) { static volatile uint32* const _data = bitband_peripheral_address(...); static volatile uint32* const _wr = bitband_peripheral_address(...); while (msb) { *_data = (bits & msb) ? 1 : 0; *_wr = 0; *_wr = 1; msb >>= 1; } }</code></pre> would likely be significantly quicker because there is no read, masking to build the bit pattern, then write for a whole 16bit port. That lot will be about 3x slower than a simple, single bit-band address write (as I explained above). The compiler might even unroll some of the loops if msb is a constant, making it even faster. Maybe you should reevaluate the idea of writing one common source implementation, with #defines to encapsulate the differences? Encapsulating differences is what classes are for. Instead write different classes, one for each processor, in simple, straightforward code, with no #if. Then look at the common parts, abstract them into a common base class, and maybe use specialised techniques in each processor specific derived class. If the specialised classes were template classes, much of the variability would be visible to the compiler at compile time, and it could do a good job of generating high-quality code. For example, the class might be templated on the I/O pins. In that case, likely all of the I/O can be done using port addresses known at compile time, so bit-band addressing, and the equivalent for AVR, could be calculated by the compiler, and optimal code generated. With a template class, _writebits could have all addresses known at compile time. With static inline, the compiler could unroll loops too. ala42 on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8563 Fri, 09 Mar 2012 20:45:15 +0000 ala42 8563@http://forums.leaflabs.com/ Looks like you did not read gbulmer's comment <pre><code>ARM digital I/O can be speeded-up enormously by using 'bit band addressing'. On STM32F every pin has two unique addresses, one gives single instruction write to a pin, and the other gives single instruction read of a pin.</code></pre> Currently you use a read/modify/write access to set a bit, but a single write was sufficient. If you want to use just one port base address, you should at least do what gpio_write_bit does: <pre><code>/** * Set or reset a GPIO pin. * * Pin must have previously been configured to output mode. * * @param dev GPIO device whose pin to set. * @param pin Pin on to set or reset * @param val If true, set the pin. If false, reset the pin. */ static inline void gpio_write_bit(gpio_dev *dev, uint8 pin, uint8 val) { if (val) { dev->regs->BSRR = BIT(pin); } else { dev->regs->BRR = BIT(pin); } }</code></pre> and use dev->regs as port address. lonewolf on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8562 Fri, 09 Mar 2012 20:20:51 +0000 lonewolf 8562@http://forums.leaflabs.com/ PS: Another optimization peculiarity I just noticed. Look at the function _update_fb(): <a href="http://code.google.com/p/ht1632c/source/browse/ht1632c.cpp#329" rel="nofollow">http://code.google.com/p/ht1632c/source/browse/ht1632c.cpp#329</a> On AVR and PIC32 the fastest way to set or reset - on the base of the "taget" value - the bit "pixel" pointed by "ptr" it's setting that value and, then, toggling it if "target" is zero. On ARM the fastest way it's a simple set or reset. Confirmed by benchmarks and by dumping assembler of compiled code. Useful hint for optimization :) lonewolf on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8561 Fri, 09 Mar 2012 20:05:02 +0000 lonewolf 8561@http://forums.leaflabs.com/ Hi gbulmer, I suspect who you're looking at an old version of my code. In the last version low level function were moved in ht1632c.cpp: <a href="http://code.google.com/p/ht1632c/source/browse/ht1632c.cpp#121" rel="nofollow">http://code.google.com/p/ht1632c/source/browse/ht1632c.cpp#121</a> ...and bit-banding and cpp macros are not used anymore. gbulmer on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8559 Fri, 09 Mar 2012 19:39:09 +0000 gbulmer 8559@http://forums.leaflabs.com/ <blockquote>Take a look to inlined functions in ht1632c.cpp. </blockquote> Okay, I did. There aren't any. Did you mean ht1632c.h? There are some <code>inline</code> functions there. Normally I'd declare them <code>static inline</code> otherwise the compiler might need to generate a none-inline function too, just in case it is called from outside the file. <code>inline</code> is *not* the normal default for C/C++, so if it is happening all the time, that is due to the options passed by the IDE. I have not checked recently, but it was certainly not the Arduino IDE default a while ago. I prefer <code>inline</code> to follow the rules of C/C++ by default, then I know what is happening. I don't think I'd like inline to be the default on something as small as an UNO where default <code>inline</code> could cause significant code expansion. I haven't checked this for years, but it was the case, that if the compiler was compiling for debugging, the compiler might choose to *not* inline a function, and that decision might be different for <code>static inline</code> vs none-static <code>inline</code>. <blockquote>I cannot use bit-banding in my code due to dynamic port/bit usage. </blockquote> Why? 1. All of a bit band addresses can be calculated at run time, it doesn't need to be done at compile time. If the compiler can see that the address is used repeatedly, it'll try to do that efficiently. 2. The SBIT, _set, _clr, and _out macros in ht1632c.h uses compile time string concatenation to build functions which are more specific. So at least the <code>bit</code> and <code>name</code> is known at compile time. 3. The calculation of the bit band address is an ordinary arithmetic expression, so if part of the expression is known at compile time, the compiler can simplify the calculation. 4. Are you saying that the wiring for the display can be changed at run-time, or are you trying to use a single compiled binary to support different wiring? If not, the wiring to port and pin addresses is known at compile time, and there is no dynamic port/bit information. It might be worth looking at the generated code for that SBIT technique. You might find that using a word address, and the bit offset (which must be known at compile time, or the macro string concatenation would not work) might be as fast and with less complexity than the bit-packed struct. If that is the case, then a bit band address might be quicker. <blockquote>pgm_read_byte and pgm_read_word are not so important </blockquote> Agreed. "pgm_read_*" is just an artifact of a specific 8bit processor with a split address space, which should not be imposed on 'cleaner' single address space processors. I much prefer to ditch that baggage and have simple, direct use of '*', '[]', '->', variables, structs, class instances, class members, array and struct initialisation, and no constraints on parameter passing, function returns, etc. <blockquote>I defined as inline ((uint8_t)*ptr) and ((uint16_t)*ptr) and that is enough for me... </blockquote> Good. <blockquote> but in other Arduino-like platform there is 100% compatibility, so this little details should be defined... </blockquote> LeafLabs have always been clear that they are not aiming for 100% Arduino compatibility. In the past, they have certainly said they would prefer to use all of the features of an STM32 rather than aim for Arduino compatibility. They have recently announced working towards Wiring compatibility, but again, have not claimed 100% identical is the goal. You are more than welcome to add a page to the wiki, and contribute your macros or inline functions to help people port their Arduino code to Maple, and other ARM or single address space processors. lonewolf on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8554 Fri, 09 Mar 2012 15:35:42 +0000 lonewolf 8554@http://forums.leaflabs.com/ gbulmer, thanks for the long reply :) Many answers to your questions are in the code of the project I linked. Take a look to inlined functions in ht1632c.cpp. With Arduino and ChipKIT I've not to specify inline. I think gcc is called by the IDE with different parameters (I've to investigate about it). About IO optimization, take a look to _set(), _reset() and _toggle() functions. As you can see, I already use bit manipulation on port registers instead of wiring pinMode and digitalWrite function. In the Arduino version I found a way to further optimized using some lines of assembler. I cannot use bit-banding in my code due to dynamic port/bit usage. pgm_read_byte and pgm_read_word are not so important, I defined as inline ((uint8_t)*ptr) and ((uint16_t)*ptr) and that is enough for me... but in other Arduino-like platform there is 100% compatibility, so this little details should be defined... gbulmer on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8550 Fri, 09 Mar 2012 14:41:12 +0000 gbulmer 8550@http://forums.leaflabs.com/ lonewolf - <blockquote>I noticed that, respect to Arduino and PIC32, the compiled code of Maple is not optimized. Is it a "problem" of the IDE (about the way of calling the compiler) or of the compiler itself? </blockquote> I strongly believe it is not the compiler. Arduino uses gcc, so does Maple, and I think ChipKit does too. If you dig into your Maple IDE install, you will find arm-none-eabi-gcc, arm-none-eabi-g++, etc. There is some documentation on using the compiler directly from the command line at <a href="http://leaflabs.com/docs/unix-toolchain.html" rel="nofollow">http://leaflabs.com/docs/unix-toolchain.html</a> which would allow you to do everything and anything. <blockquote>I had to explicitly specify "inline" functions, even "__attribute__((always_inline))" to force inline. </blockquote> That is the default for C/C++. What functions did you expect to be inlined automatically? <blockquote>Moreover, some datatypes present in Arduino's clones eg. "uint8_t" and "uint16_t" are missing </blockquote> Maple uses <code>uint8</code>, <code>uint16</code>, which, IIRC were used for a while on Arduino. You should be able to <code>#include <stdint.h></code> to get the ANSI type names, e.g. "uint8_t". <blockquote>Are also missing some AVR-compatibibility functions like "pgm_read_*". </blockquote> Good news here. Those "pgm_read_*" are the Atmel AVR mechanism to deal with the details of the AVR processor; RAM and Flash are different address spaces. RAM and Flash need different instruction to access them. The ARM is a 'proper' 32bit processor, with a single address space. Pointers can access Flash and RAM without the extra mechanism that the AVR processors need. So there is no need for "pgm_read_*", pointers just work. So it is straightforward to put anything into Flash, and access it using normal C/C++ operations, like dereferencing '*', and indexing '[]'. <blockquote>Finally, I have to find a way to better optimize IO </blockquote> Precisely what is it you are trying to optimise? ARM digital I/O can be speeded-up enormously by using 'bit band addressing'. On STM32F every pin has two unique addresses, one gives single instruction write to a pin, and the other gives single instruction read of a pin. The pinMode of the pin must be set, and only read or write will work at any one time (depending on pinMode INPUT or OUTPUT) but after that the appropriate bitband address gives direct access. The STM32F103 in the Maple takes two cycles to execute the instruction, so digital I/O has a theoretical speed of 36MHz. That is much faster than digitalWrite, and the compiler generates the correct instructions without any assembler. Please have a search for the threads which discuss this, but if you'd like a bit more help, please post, and we'll try to help. (Full disclosure: I am not a member of LeafLabs staff) lonewolf on "Sure Electronics 3216 bicolor display" http://forums.leaflabs.com/topic.php?id=1441#post-8548 Fri, 09 Mar 2012 13:02:20 +0000 lonewolf 8548@http://forums.leaflabs.com/ I wrote an Arduino library for Sure Electronics 3216 bicolor led display. I released the library under GPLv3 within a repository on Google Code: <a href="http://code.google.com/p/ht1632c/" rel="nofollow">http://code.google.com/p/ht1632c/</a> I ported the library to Leaflab Maple and ChipKIT Uno32. Some benchmarks (with two cascaded 3216 displays): * Arduino Uno and clones (AVR ATMega328 16Mhz) 135 fps * Leaflab Maple (ARM STM32 F103RB 72Mhz) 500 fps * ChipKIT Uno32 (Microchip PIC32MX320F128 80Mhz) 1050 fps NB: This library is a work in progress! Not extensively tested with all platforms, not fully working with > 2 cascaded displays. Some notes specific to Maple platform. I noticed that, respect to Arduino and PIC32, the compiled code of Maple is not optimized. Is it a "problem" of the IDE (about the way of calling the compiler) or of the compiler itself? I had to explicitly specify "inline" functions, even "__attribute__((always_inline))" to force inline. Moreover, some datatypes present in Arduino's clones eg. "uint8_t" and "uint16_t" are missing. Are also missing some AVR-compatibibility functions like "pgm_read_*". Finally, I have to find a way to better optimize IO (using assembler? any suggestions are welcome!): 500 fps seems to me a poor result compared to 1050 fps of a PIC32.