Actions
Forum Thread Details
  • Replies 6 replies
  • Subscribers 393 subscribers
  • Views 837 views
  • Users 0 members are here
Related

A fast digital IO

Workshopshed

I've not had an issue with performance of the I/O but here's a technique for squeezing a little more speed out of the ports without having significant code changes.

 

http://www.codeproject.com/Articles/732646/Fast-digital-I-O-for-Arduino

Parents

  • This looks nice until you see things like recent changing from Raspberry Pi to a Pi 2 and the library breaks! Too many folks here would not know what to do, except for some of the hard core type. image I have not checked, but would guess the Arduino has ports mapped differently depending on the chips also.

    Pass,

    Clem

Reply

  • This looks nice until you see things like recent changing from Raspberry Pi to a Pi 2 and the library breaks! Too many folks here would not know what to do, except for some of the hard core type. image I have not checked, but would guess the Arduino has ports mapped differently depending on the chips also.

    Pass,

    Clem

Children
  • in reply to clem57

    I think I get what you mean. Being able to standardise code is important if you are working on lots of different platforms and changing "core" libraries does pass compatibility issues onto your responsibility. However there are already issues between the different Arduino versions and often the libraries you find for your project are very old so to get working on that platform you do need to be quite good at fixing those kind of things.

    To be honest if you are needing to squeeze ms off digital I/O you must already be working at quite a low level and this provides an intermediate step before you get to raw AVR code.

  • in reply to clem57

    It does, and the ports also have different functionality (Much of which is not exposed through "Wiring") but in order to protect the user from this there is a rather large and relatively slow abstraction layer allowing the use of commands like DigitalWrite() etc. to still output that logic level to the same pin on the "Arduino Header Connectors"

     

    The reason the MEGA is way slower than the UNO for the exact same program is entirely down to the abstraction layer being more involved for the MEGA. The Mega IO is more complex and requires more checks before outputting your logic level to the port (I tested this a long time ago and this is true even though the MEGA and UNO where both running at 16Mhz)

     

    It is when I reduced the code to use direct IO that the two code applications started to run at the same speed and that was also a significant increase in speed too (Maybe 10* or more)

     

    I will perform some tests over the weekend if I get a chance and publish the results

  • in reply to clem57

    Clem Martins wrote:

     

    This looks nice until you see things like recent changing from Raspberry Pi to a Pi 2 and the library breaks! Too many folks here would not know what to do, except for some of the hard core type.

    Raspbian moved the peripheral base address from 2000.0000 to 3F00.0000.  It's probably hard-coded to 2000.0000 in most libraries.

     

    Here's a discussion at RasPi Forum: http://www.raspberrypi.org/forums/viewtopic.php?f=33&t=98740

     

    The RasPi GPIO Wiki hasn't been updated with the new value.  For that matter, it hasn't been updated completely for RasPi A+/B+ and RasPi 2.  Sic semper wikis.  http://elinux.org/RPi_Low-level_peripherals