[beagleboard] Re: Using IIO driver as a Loadable kernel module
Solution was easy!
First disable default ADC overlay in uEnv.txt (optional)
then change my device tree to a better one!
related section of my device tree is below:
fragment@2 {
target = <>;
__overlay__ {
status = "okay";
adc@0 {
compatible = "ti,ads8688";
reg = <0>;
spi-max-frequency = <100>;
};
};
Because the ads8688 use spi for communication. I must introduce it to spi
interface!
On Wednesday, January 2, 2019 at 2:25:15 AM UTC-8, Bashid wrote:
>
> Hello
>
> I want use ti-ads8688 iio driver
>
> as
> a kernel module. I am using Beaglebone Black.
>
> I wrote below Makefile for this work.
>
> obj-m+=ti-ads8688.o
> all:
> make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
> clean:
> make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean
>
> ti-ads8688.ko file correctly generated and i load it with insmod command.
> But there is not module in iio devices, as you can see in below:
>
> debian@beaglebone:~/work/phase1$ ls /sys/bus/iio/devices/iio\:device0
> buffer in_voltage1_raw in_voltage4_raw in_voltage7_raw power
> uevent
> dev in_voltage2_raw in_voltage5_raw name
> scan_elements
> in_voltage0_raw in_voltage3_raw in_voltage6_raw of_node subsystem
>
> am i miss something? I also add in my devicetree below unit:
>
> adc@0 {
> compatible = "ti,ads8688";
> reg = <0>;
> spi-cpha;
> spi-max-frequency = <10>;
> };
>
>
> I think the problem is with my device tree, but I don't know how fix it.
>
>
--
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/b91a31c6-2e19-4a09-8877-87bc4087ad16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...
I have a project that uses a PRU to unpack run-length compressed data for a photoplotter. It has a loop that supplies the next pixel to the laser every 5 us! The PRU is not even breathing hard to do that. So, it watches for a low-to-high transition on a clock input and then counts out the pixels and decides if this run is used up and has to get the next run. No problem at all. Now, this is not actually a case where a few ns of jitter would show up, I have not counted out the instruction cycles or anything. The photoplotter provides the pixel clock and the PRU just stays in sync with that. Jon -- 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/74495cb0-64ef-4ed6-88f4-fdcd32d94be5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...
There's a pretty easy method to test bit-bangig with direct GPIO. Just run the example http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle You can adapt the PRU firmware using PASM assembler and test whatever you need. Choose one of the C, Python or FreeBASIC firmware loaders. Regards -- 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/54a42aee-49e2-479a-b4a4-49d3f21b60dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: I have a problem with Buildroot
Thanks for your interest. This is mtools.conf: # Debian default mtools.conf file. # "info mtools" or "man mtools.conf" for more detail. # # Linux floppy drives drive a: file="/dev/fd0" exclusive drive b: file="/dev/fd1" exclusive # # First SCSI hard disk partition # drive c: file="/dev/sda1" # # First IDE hard disk partition # drive c: file="/dev/hda1" # # dosemu hdimage. drive m: file="/var/lib/dosemu/hdimage.first" partition=1 offset=128 # # dosemu floppy image drive n: file="/var/lib/dosemu/fdimage" # # SCSI zip disk # drive z: file="/dev/sda4" # # uncomment the following line to display all file names in lower # # case by default # mtools_lower_case=1 9 Ocak 2019 Çarşamba 22:07:28 UTC+3 tarihinde Dennis Lee Bieber yazdı: > > On Tue, 8 Jan 2019 14:21:10 -0800 (PST), Talha Ayranc? > > declaimed the > following: > > > > >I encountered an error while trying build an image with Buildroot. What > is > >the reason of this? > > > > >Syntax error at line 5 for drive A: column 9 in file /etc/mtools.conf: > unrecognized > >keyword > > So what does /etc.mtools.conf contain? > > > -- > Wulfraed Dennis Lee Bieber AF6VN > wlf...@ix.netcom.com > HTTP://wlfraed.home.netcom.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/97ec8a71-5869-4315-be09-04f50d423f0f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] u-boot not booting/executing a bare metal binary
I recently compiled a u boot image from source, after I downloaded the source code from the official git repo i executed make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean make ARCH=arm CROSS_COMPILE=arm-none-eabi- am335x_evm_defconfig make ARCH=arm CROSS_COMPILE=arm-none-eabi- and then copied over the MLO, u-boot.bin and as some docs also mentioned it u-boot.img over to my SD card. After that i compiled this project: https://github.com/dwelch67/pocket_beagle_samples/tree/master/blinker01 (i verified that it works by dding the sdraw.bin to the sdcard and then letting it boot in raw mode from the SD card), copied the notmain.bin over to the SD card and wrote a uEnv.txt file with boot_notmain=mmc rescan & mmc 0x40200800 notmain.bin && go 0x40200800 uenvcmd=run boot_notmain to the SD card. After that i plugged the card into the SD slot of the beagle pocket and powered it on. However the LEDs didnt start to blink so either U-Boot or the notmain.bin file didnt get executed. If anyone has an idea what went wrong or could help me troubleshoot it please tell me. -- 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/2f2a5915-b5ed-46bd-a414-48f62d884b7c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] u-boot doesnt boot a bare metal application correctly
I recently compiled a u boot image from source, after I downloaded the source code from the official git repo i executed make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean make ARCH=arm CROSS_COMPILE=arm-none-eabi- am335x_evm_defconfig make ARCH=arm CROSS_COMPILE=arm-none-eabi- and then copied over the MLO, u-boot.bin and as some docs also mentioned it u-boot.img over to my SD card. After that i compiled this project: https://github.com/dwelch67/pocket_beagle_samples/tree/master/blinker01 (i verified that it works by dding the sdraw.bin to the sdcard and then letting it boot in raw mode from the SD card), copied the notmain.bin over to the SD card and wrote a uEnv.txt file with boot_notmain=mmc rescan & mmc 0x40200800 notmain.bin && go 0x40200800 uenvcmd=run boot_notmain to the SD card. After that i plugged the card into the SD slot of the beagle pocket and powered it on. However the LEDs didnt start to blink so either U-Boot or the notmain.bin file didnt get executed. If anyone has an idea what went wrong or could help me troubleshoot it please tell me. -- 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/45f1b653-0867-4036-bd4a-26974174608e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] U-boot doesnt execute a bare metal application properly
I recently compiled a u boot image from source, after I downloaded the source code from the official git repo i executed make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean make ARCH=arm CROSS_COMPILE=arm-none-eabi- am335x_evm_defconfig make ARCH=arm CROSS_COMPILE=arm-none-eabi- and then copied over the MLO, u-boot.bin and as some docs also mentioned it u-boot.img over to my SD card. After that i compiled this project: https://github.com/dwelch67/pocket_beagle_samples/tree/master/blinker01 (i verified that it works by dding the sdraw.bin to the sdcard and then letting it boot in raw mode from the SD card), copied the notmain.bin over to the SD card and wrote a uEnv.txt file with boot_notmain=mmc rescan & mmc 0x40200800 notmain.bin && go 0x40200800 uenvcmd=run boot_notmain to the SD card. After that i plugged the card into the SD slot of the beagle pocket and powered it on. However the LEDs didnt start to blink so either U-Boot or the notmain.bin file didnt get executed. If anyone has an idea what went wrong or could help me troubleshoot it please tell me. -- 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/48a6e63d-8272-4b3f-8b1b-23b22f2c2f67%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...
You can only do no-jitter bit-banging if you use the PRU direct outputs, and those are unique to each PRU core so there is no possibility for contention between the PRU cores for access. Any access to the standard GPIO registers will always have some jitter, as the write transactions from the PRU have to cross the on-chip interconnect fabric and transition to a separate clock domain. That said, the jitter is typically very low (5-10 nS) and is unlikely to be a significant problem. The very significant jitter seen when accessing the GPIO registers with the ARM core is related more to task scheduling and operating system effects than the low-level bus transactions to the GIPO registers, and does not exist on the PRUs. On 1/9/2019 3:06 AM, ithinu wrote: > So it means that I can do no-jitter bit banging if only one PRU accesses > the GPIO, and if the unit does not use any shared resources? That would be > great. > > On Tuesday, January 8, 2019 at 10:43:36 PM UTC+1, Charles Steinkuehler > wrote: >> >> The PRUs are mostly deterministic when accessing resources within the >> local PRU-ICSS block. The "mostly" comes from potential contentions >> if you have both PRU cores accessing the same resource (eg: PRU0 and >> PRU1 both trying to access the local UART) in which case one of the >> PRU cores will stall briefly. >> >> The PRUs are less deterministic when accessing resources outside the >> PRI-ICSS block (eg: SDRAM or GPIO registers) where the transaction is >> subject to synchronization delays, bus congestion on the L3/L4 >> interconnect, etc. >> >> On 1/8/2019 6:48 AM, daveyj...@gmail.com wrote: >>> Hi, I have read this nice ad for PRUs >>> http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how >>> deterministic the PRUs are, >>> >>> "*each PRU has its own single-cycle I/O*" etc. Then I wanted details... >>> >>> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit >> "Content >>> is* no longer maintained and is being kept for reference only!* " >>> >>> http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of >>> Wednesday, August 15th, 2018 this wiki *has been set to read only*." >>> >>> http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU >> write >>> instruction is a fire-and-forget command that executes in *~*1 cycle" >>> >>> *that tilde...* >>> >>> >>> "The read latency values at the following links are *considered* >>> "best-case," accounting for the 2 cycle instruction and interconnect >>> introduced *latency*". >>> >>> *best case* >>> >>> Possibly, there is some doc which states min/max execution times? >>> Deterministic or not? etc, etc. >>> *Not found. Just not found.* >>> >>> --- >>> >>> I do not want to be pessimistic but neither I want to >> reverse-engineer >>> these "deteministic" units, that do not really look that-deterministic. >> And >>> that docs obsolete or missing??? What is it all about? >>> >>> >>> >>> >> >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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/67079519-549d-ec77-6e8b-484caf77c6f2%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Hycon Touch controller HY4633 Linux Driver!!
Hello, have you found a solution e.g. a working driver? Best Regards, flo Hello, > > did anyone find the working and full driver of Hycon HY4633 Touch IC? > > I did not find any in current version of Linux Repo. > https://github.com/torvalds/linux/tree/master/drivers > https://github.com/torvalds/linux/tree/master/drivers/staging > > on the website > https://www.hycontek.com/en/category/products-en/touch-en#tab2 they > provide sample code > http://www.hycontek.com/wp-content/uploads/Linux_driver_sample_code.zip > but i dont know if its enough!!! > > any help will be appreciable!! Thank you. > > > -- 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/750fb695-f3d6-4c97-94a5-9c0f45324c4f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: PRUs - not really deterministic, missing docs?
Please disregard, original thread is in the PRU subsection, posted here by mistake... On Tuesday, January 8, 2019 at 2:45:06 PM UTC+1, daveyj...@gmail.com wrote: > > Hi, I have read an intro about PRUs > http://www.staroceans.org/documents/TI-sdk/spry264.pdf "each PRU has its > own *single-cycle I/O*" > > Well, nice. Let's look further... > > http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit > "Content is no longer maintained and is being kept for reference only! " > http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "has been set > to read only" > > http://www.ti.com/tool/PRU-SWPKG?HQS=TI-null-null-mousermode-df-pf-null-wwe=yes_url=https%3A%2F%2Fwww.mouser.fr%2F > > "this software package is no longer being maintained." > Tried to send a message into BeagleBone PRU subforum... it happily > disappeared forever. > > But ok, it is just a possible warning. Let us look into the hard docs. > > http://www.ti.com/lit/an/sprace8a/sprace8a.pdf a write instruction > "executes in *approximately* 1 cycle" "Table 1 through Table 3 are > considered *"best-case"* read latency values for the PRU" > > Now it is not just a warning. It shows that the details of the "real-time" > are some undocumented unknowns, and that these units might not be > deterministic at all. "Might", because there are just no precise docs and I > am not going to reverse-engineer them. It would not give the real-time > guaranties. > > Possibly you could point me to some modern processing unit where there is > at least a subset of instructions (including basic GPIO read/write and > intercore communication) with precise execution times? > > > > > > > > -- 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/172cf3a1-8d12-4384-898a-c145e40b9aaf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...
Hi Charles and lazarman, I do not do anything serious enough to require certificates stating that these docs are true, I just wanted to have the docs... Just "it will be one or two cycles if" which, if true, is likely known by the designers of the chip. Which I eventually got from Charles' post. Thanks lazarman for the insight concerning the industry. -- 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/e533c4f3-3395-4bdf-8393-9daacb6872be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...
So it means that I can do no-jitter bit banging if only one PRU accesses the GPIO, and if the unit does not use any shared resources? That would be great. On Tuesday, January 8, 2019 at 10:43:36 PM UTC+1, Charles Steinkuehler wrote: > > The PRUs are mostly deterministic when accessing resources within the > local PRU-ICSS block. The "mostly" comes from potential contentions > if you have both PRU cores accessing the same resource (eg: PRU0 and > PRU1 both trying to access the local UART) in which case one of the > PRU cores will stall briefly. > > The PRUs are less deterministic when accessing resources outside the > PRI-ICSS block (eg: SDRAM or GPIO registers) where the transaction is > subject to synchronization delays, bus congestion on the L3/L4 > interconnect, etc. > > On 1/8/2019 6:48 AM, daveyj...@gmail.com wrote: > > Hi, I have read this nice ad for PRUs > > http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how > > deterministic the PRUs are, > > > > "*each PRU has its own single-cycle I/O*" etc. Then I wanted details... > > > > http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit > "Content > > is* no longer maintained and is being kept for reference only!* " > > > > http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of > > Wednesday, August 15th, 2018 this wiki *has been set to read only*." > > > > http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU > write > > instruction is a fire-and-forget command that executes in *~*1 cycle" > > > > *that tilde...* > > > > > > "The read latency values at the following links are *considered* > > "best-case," accounting for the 2 cycle instruction and interconnect > > introduced *latency*". > > > > *best case* > > > > Possibly, there is some doc which states min/max execution times? > > Deterministic or not? etc, etc. > > *Not found. Just not found.* > > > > --- > > > > I do not want to be pessimistic but neither I want to > reverse-engineer > > these "deteministic" units, that do not really look that-deterministic. > And > > that docs obsolete or missing??? What is it all about? > > > > > > > > > > > -- > Charles Steinkuehler > cha...@steinkuehler.net > -- 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/8e0256f6-38cf-44b6-8456-9750ad0a95c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
