#Let's call it AssignIO(). This requests and locks #the scarce resource in
prep for an open. Odds are #unless you have some fancy hardware #multiplexing
it would stay assigned for the entire #program. But nothing stops you from
doing a #ReleaseIO() and then setting a GPIO bit to mux in #the I2C logic and
then an AssignIO() for the I2C.
Take a barebones or Green Hills Integrity RTOS.
Muxing is done in GPIO_Init and some registers are locked and can only be
unlocked in ARM supervisor mode.
GHS Integrity can be run in supervisor mode or virtual mode which uses the MMU
and MPU.
The intent is a bad application can't crash the processor each address space
can run an application and won't bring down the processor as in VxWorks AE 653+
Arinc 653) they want that in flight control it's life critical.
I didn't know Linux user space let you remux pins.
The challenge with these SOCs the barebones startup code started getting very
complex depending on what pins and peripheral you needed .I saw that with
starterware code for barebones tons of clock and pin and board set-up Data so
the code supported everything possible.
In a supervisor mode system the startup code makes sure every pin is
configuration won't cause a forging hammer to turn on ie it was safe. You added
a peripheral or changed board's the code changed.
In the Linux world all these board.c files got to be too much when most users
didn't care about hardware hence these device trees.
The problem in my opinion it's all keeps changing tree's to overlay to sysfs in
user space. Config pins changing books out dated.
I mean hell if you can keep abreast it's job security as it's seems the average
Joe can't even a simple i2c device working. Just keep changing things.
That is my biggest gripe against Linux beforehand if I wanted to add something
I looked at GPIO init.c and immediately knew what was hooked up.
And yes if I wanted to reconfigure something on the fly I could if I was
running in supervisor mode other wise a IO Device ( GHS kernel driver's)
abstracted the HW from the PC application programmer type that couldn't use a
scope and was only safe writing algorithms.
Flexibility comes at a cost. I'm struggling to stay informed and today saw yet
another wiki or blog or book or cookbook that talked about GPIO on Linux.
Something that takes 1 hour to get working ( toggle GPIO) in barebones or RTOS
really should not be as difficult as I see people asking about .DTS files
almost daily.
I realize a .DTS is no different than a c array holding pin muxing Data
I think the average user has no clue if it is uboot passing these to these
hardware dependencies in.dts to the kernel or who loads an overlay.
One final ramble I was researching FreeRtos on the Beaglebone bone today I was
struck by the average free RTOS user is very ARM low level processor
cognizant knowledgeable and I saw a readme says see the TRM to see 3 GPIO
interrupts being generated to trigger task context switches and how little code
was actually involved in a FreeRtos kernel Port some with lwip stack etc
I mention this because if the goal of embedded Linux is to abstract hardware
so the user doesn't need any knowledge I'm afraid they might change all this
again right when I think I was starting to understand it and make another
version of a book necessary 🙈
Sent from Yahoo Mail on Android
On Fri, May 21, 2021 at 10:01 PM, Dennis Lee
Bieber<dennis.l.bie...@gmail.com> wrote: On Fri, 21 May 2021 09:39:34 -0700,
in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6ditlojsohvde0pjs...@public.gmane.org> wrote:
>static const char *device = "/dev/spidev1.0";
> fd = open(device, O_RDWR);
> if (fd < 0)
> pabort("can't open device");
>
>One of two things happen. Either It opens the SPI bus which includes
>everything that config-pin does or it fails because config-pin wasn't done.
Hypothesis: The "device" (driver) is loaded -- but the pin-mux does not
have the pins connected to the internal port(s) used by the driver... So
the driver is basically dumping output into the "bit-bucket".
It can't really take control -- since the same pins are used by I2C
mode, if opening the "device" did the pin-mux one could really mess up data
transfers (open "I2C" start transfer, then open SPI using the same pins).
>> >Oh and none of this explains why the ioctl regardless of C or Pascal
>> >
>can't handle more than 4096 data bytes while the Python code can when sending
>a large bitmap to the SPI port.
>...
>> debian@beaglebone:~$ cat /sys/module/spidev/parameters/bufsiz
>> 4096
>> debian@beaglebone:~$
>
>How did you know to look at this file to determine the SPI buf size?
https://www.kernel.org/doc/Documentation/spi/spidev
"""
- There's a limit on the number of bytes each I/O request can transfer
to the SPI device. It defaults to one page, but that can be changed
using a module parameter.
- Because SPI has no low-level transfer acknowledgement, you usually
won't see any I/O errors when talking to a non-existent device.
"""
along with the source for the Python spidev module, which explicitly
mentions that parameter... Though just doing
sudo find / -iname "spidev"
and exploring what each result contains (or to bypass one layer)
debian@beaglebone:~$ ls -R `sudo find / -iname "spidev"`
/sys/bus/spi/drivers/spidev:
bind module spi0.0 spi0.1 spi1.0 spi1.1 uevent unbind
/sys/class/spidev:
spidev0.0 spidev0.1 spidev1.0 spidev1.1
/sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.0/spidev:
spidev0.0
/sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.0/spidev/spidev0.0:
dev device power subsystem uevent
/sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.0/spidev/spidev0.0/power:
async runtime_active_kids runtime_status
autosuspend_delay_ms runtime_active_time runtime_suspended_time
control runtime_enabled runtime_usage
/sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.1/spidev:
spidev0.1
/sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.1/spidev/spidev0.1:
dev device power subsystem uevent
/sys/devices/platform/ocp/48030000.spi/spi_master/spi0/spi0.1/spidev/spidev0.1/power:
async runtime_active_kids runtime_status
autosuspend_delay_ms runtime_active_time runtime_suspended_time
control runtime_enabled runtime_usage
/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.0/spidev:
spidev1.0
/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.0/spidev/spidev1.0:
dev device power subsystem uevent
/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.0/spidev/spidev1.0/power:
async runtime_active_kids runtime_status
autosuspend_delay_ms runtime_active_time runtime_suspended_time
control runtime_enabled runtime_usage
/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.1/spidev:
spidev1.1
/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.1/spidev/spidev1.1:
dev device power subsystem uevent
/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.1/spidev/spidev1.1/power:
async runtime_active_kids runtime_status
autosuspend_delay_ms runtime_active_time runtime_suspended_time
control runtime_enabled runtime_usage
/sys/module/spidev:
coresize holders initstate parameters sections uevent
drivers initsize notes refcnt taint
/sys/module/spidev/drivers:
spi:spidev
/sys/module/spidev/holders:
/sys/module/spidev/notes:
/sys/module/spidev/parameters: <<<<<
bufsiz <<<<<
/sys/module/spidev/sections:
__jump_table __mcount_loc __param __verbose
debian@beaglebone:~$
--
Dennis L Bieber
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/v2pgag101omfhqgj1h5p4o03b3ilskegli%404ax.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/741906799.1883238.1621656855149%40mail.yahoo.com.
