For GPIOs 0,2 and 3 clocks are not enabled when you load an overlay
with pinmuxing and every access to the registers of these modules
results in a bus error. The workaround for this problem is to export
one pin from each module through sysfs. There was last month a
discussion on the group about this problem:
https://groups.google.com/d/msg/beagleboard/OYFp4EXawiI/61Zwn2Z5REgJ
I included with the library a script which enables all modules. Just
run tools/bbb_enable_gpio.sh and the bus error will be gone until next
reboot. There is no need to run this script before each run of your
program.
Jacek,
That did the trick. Just played for an hour characterizing the response latency in the write function on an oscilloscope. Very cool. Thanks again for your help.
Regards,
Scott Rush
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/yflrTE39KhQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
Var pins = (typeof bone != 'undefined') ? bone : b.bone.pins;
var ledPin = pins.P8_13;
var ledPin2 = pins.USR3;
b.pinMode(ledPin, b.OUTPUT);
b.pinMode(ledPin2, b.OUTPUT);
ETC
b.diitalWrite(ledPin, b.LOW)
ETC
And in C/C++ one has to open two files for each pin nested down several levels from root?????
Makes no sense!!!
Jacek,
I appreciate your response. However, I've never had to open files to write to the pins of a controller or computer. This is a first for me; and may I say, I find it a very inefficient method which leaves room for many errors. Furthermore, if you have to interact with the OS to read or write to a file system, it slows the system down by several orders of magnitude. I never had to work with a file to write to an output pin on a PC, PIC Microcontroller, AVR, Arduino, (old Sinclar 1000) etc... If TI wants this development board (computer) to be a viable development platform, they need to provide a more efficient manner in addressing GPIO pins directly from within the processor. Whether that is via inline assembly, a standard library, C++ data structures that facilitate '.' access to the elements and methods, etc. I stress, this needs to work within the embedded ARM processor and not through the OS file system. How many machine instructions/cycles are wasted telling the ARM to:
Open a file;
fseek...
analyze the data
fwrite...
fflush...
fclose...
And then, the processor has to go to the file system to open the file, read the data the programmer just set, and then set/write/read to/from the pin...
All the while, the ARM processor has to have assembler code that directly: 1. Reads/Sets the pin mode--to include data direction, pull-up/down resistor, etc., 2. Reads the pin value, 3. Writes a value to the pin.
--
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/yflrTE39KhQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c6abe7ba-c08d-42de-8d9a-685a24a4a810%40googlegroups.com.