[beagleboard] Re: PRU I/O max speed
I would be stunned if the GPIOs don't have synchronizer flip-flops as they are sampling a signal asynchronous to the 200MHz clock. That would account for 2 clocks. You probably need one extra to clock data into R31. And then one clock to read R31. 50MHz is a pretty smoking speed for SPI--you normally need to start thinking about series termination and some basic signal integrity. You normally need the clock to capture to flop directly if you want things to work. I suspect you probably need to use the 16-bit Parallel Capture Mode while feeding your clock out back as clock in. You'll still probably be 4 clocks behind when the data hits R31, but the data will get *captured* by the PRU_CLOCKIN edge properly so the delay will now be deterministic if you are generating the 50MHz clock yourself. On Thursday, February 25, 2021 at 12:15:18 PM UTC-8 rpau...@gmail.com wrote: > With a sample size of one, r31 appears to be 4 instructions behind the > state of the pin. > > On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: > >> I am, unfortunately, bit-banging SPI with the PRU, and I seem to be >> running into a speed limit < 50 MHz I desire. I can certainly create a >> clock that fast, but reading data seems to be delayed. I can see on the >> logic analyzer a "0" clearly being read as a '1" so there is either a delay >> in my clock output or a delay in my input or both. I would like to think >> that r30 and r31 are tied directly to the outside world, but now I am >> thinking there is something in between that is either clocked or just has >> significant output delays. Anyone else encountered this? > > -- 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/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com.
Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
Bumping this. Again. I'd like to *NOT* have to keep supporting the fix for this on the user side in the 5.X series when this really needs to get fixed on the kernel side. I've filed the bug reports. They're just sitting. In reality, the rpmsg system doesn't really have the hooks to even support the fix from the user side as I can't query the size and depths of the buffers. This needs to get fixed in the PRU rpmsg kernel subsystem. Thanks. On Tuesday, June 30, 2020 at 3:43:01 AM UTC-7 Andrew P. Lentvorski wrote: > So, we're still back at the original question of "Where do I file this bug > so that it gets tracked?" > > I see some recent work on rpmsg bugs at > https://github.com/beagleboard/linux/issues, so I'll file a bug there. > But, is there somewhere else I should file it? > > Thanks. > -- 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/8c22cc26-7c2e-4fc9-a239-db3573efc1ean%40googlegroups.com.
[beagleboard] Re: PRU Memory Store Instruction with Autoincrement?
Hmm, that's an interesting idea, Dimitar, to encode the increment in the immediate. That's probably ... useful. That mechanism would give me a 64-sample burst per register which could possibly get me to 1920 samples *if* the SBBO doesn't stall out anywhere. I thought about the BeagleLogic, but it relies on the fact that every other cycle is NOP, so it can effectively run something simultaneously at half-speed in the interleaved time. Looks like it's time for some experiments. I'll report back if I see anything interesting. On Sunday, October 18, 2020 at 12:11:33 PM UTC-7 din...@gmail.com wrote: > Hi, > > Do you require continuous 200MHz sampling? That would be difficult I think. > > If you require bursts of 200MHz sampling, how long should those bursts be? > Even if you find autoincrement opcode, you would still need to add one jump > instruction to "loop". > > You can try hardcoding the "increment" into the constant offset field. And > load several registers with starting address of each 256-byte chunk of your > destination buffer. Example: > > init: > ldi r0, __buf_start > ldi r1, __buf_start+256 > ldi r2, __buf_start+256*2 > ... > burst_store: > sbbo , r0, 0, 4 > sbbo , r0, 4, 4 > sbbo , r0, 8, 4 > sbbo , r0, 12, 4 > sbbo , r0, 16, 4 > > sbbo , r0, 252, 4 > sbbo , r1, 0, 4 > sbbo , r0, 4, 4 > ... > > I am not sure what are the buffering limits of PRU's posted writes. I > doubt if so many consecutive sbbo instructions would not stall. > > You should also examine BeagleLogic firmware's operation mode for 100MHz. > Perhaps you can modify it to take 200MHz bursts instead of continuous > 100MHz sampling. Difference with above single-PRU example is that you would > use PRU register banks for buffering, which would decouple sampling from > SBBO bus operations. > > Regards, > Dimitar > > On Sunday, October 18, 2020 at 10:16:44 AM UTC+3 Andrew P. Lentvorski > wrote: > >> Hi, folks, >> >> I'm trying to dump R31 over and over into either RAM0 or Shared DRAM >> (Data RAM). >> >> So, basically it looks like I have to do: >> >> Store R31 to address in register >> Increment address in register >> (Lather rinse repeat) >> >> As that stands, that's a 100MHz sample of R31. Is there anyway to do the >> autoincrement on the store? That would double my sampling rate to 200MHz >> which would be the maximum possible. >> >> Alternatively, is there a different way to sample and store R31 >> repeatedly to RAM0 or Shared DRAM? I can't seem to see one, but there are >> so many permutation of Store Burst, mapping, the broadside transfer bus, >> and peripherals that I can quite easily be missing something that someone >> more experienced knows about. >> >> Thanks. >> > -- 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/1799122c-27ec-4c2e-91f3-60b41c906b81n%40googlegroups.com.
[beagleboard] PRU Memory Store Instruction with Autoincrement?
Hi, folks, I'm trying to dump R31 over and over into either RAM0 or Shared DRAM (Data RAM). So, basically it looks like I have to do: Store R31 to address in register Increment address in register (Lather rinse repeat) As that stands, that's a 100MHz sample of R31. Is there anyway to do the autoincrement on the store? That would double my sampling rate to 200MHz which would be the maximum possible. Alternatively, is there a different way to sample and store R31 repeatedly to RAM0 or Shared DRAM? I can't seem to see one, but there are so many permutation of Store Burst, mapping, the broadside transfer bus, and peripherals that I can quite easily be missing something that someone more experienced knows about. Thanks. -- 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/f6018682-11cb-4370-a7ed-8cab21011d4dn%40googlegroups.com.
Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
So, we're still back at the original question of "Where do I file this bug so that it gets tracked?" I see some recent work on rpmsg bugs at https://github.com/beagleboard/linux/issues, so I'll file a bug there. But, is there somewhere else I should file it? Thanks. -- 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/9382c9f2-3ecf-4a2b-8869-10b2b2cf3e6eo%40googlegroups.com.
Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
Sure. Right now, I just keep track of how many messages are in flight and I don't allow it to queue too many. That's useful once you know what the bug is. Fortunately, I hit this bug before I had two threads (one receiving USB and one receiving ethernet) which would have made hunting it down quite painful. So, at least now I know that I *must* have a single thread acting as a gatekeeper on top of the rpmsg system. If, however, you try to use a library on top of this bug that actually expects the O_NONBLOCK behavior to work, you will have a long debugging chain. What *originally* tripped all of this was that I tried to use Rust and Tokio, which failed mysteriously. After far too much fruitless debugging, I switched down to Rust and mio, which also failed weirdly. So, I switched down to C, poll, and O_NONBLOCK, which then gave the incorrect blocking behavior and the ERESTARTSYS. After *that*, I could actually pinpoint the incorrect behavior as belonging to pru_rpmsg and as being due to a full queue with incorrect blocking semantics. Getting to that point, however, was neither pleasant nor straightforward. -- 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/4f17a6a6-0c12-49de-81ec-25b072b6d9efo%40googlegroups.com.
Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
Urk, sorry I didn't quite get the implications of this statement: The kfifo is used only on the receive path because of the asynchronous > callbacks. The > Tx-path is synchronous, the copy is attempted directly on the vring buffers > That means that kfifo doesn't exist on send so the only available solution appears to be calling rpmsg_trysend when in O_NONBLOCK mode. That will hit the full vring buffers and should bounce back immediately with ENOMEM. Thanks. -- 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/dcbb9c5a-229a-481f-8ea0-11a8735ac095o%40googlegroups.com.
Re: [beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
Hi, folks, The issue is that requests cause the rpmsg channels to the PRU to fill. Which is actually fine, the PRU in this case is servicing slow requests and the rpmsg being full should exert backpressure. The problem is that the rpmsg system *HANGS* several second before timing out and throws a fairly bizarre error. Quoting my original message: > Except that my overrun writes to "/dev/rpmsg_pru30" *still* block for several seconds (very bad) and then terminate with an Error 512 (huh?). This is not good behavior from all manner of perspectives: 1) Why does the write time out *at all* when not O_NONBLOCK? That's certainly not expected behavior. There is no reason why the PRU might not take a couple seconds to service a request. If that's a problem, you either set a timeout manually (usually only valid for file descriptors of sockets) or you put the file descriptor into non-blocking mode. (It appears that this is the fault of the rpmsg driver which will time out after 15 seconds and then return ERESTARTSYS) 2) Why does the write hang *at all* when in O_NONBLOCK? That's also not expected behavior. If the queue is full, an attempt to write to it should return *IMMEDIATELY* with something like ENOMEM/EAGAIN. (This appears to be the fault of the rpmsg_pru driver). The file I was looking at is here: https://github.com/beagleboard/linux/blob/4.19/drivers/rpmsg/rpmsg_pru.c Two solutions seem to present themselves: 1) Use rpmsg_trysend when O_NONBLOCK is set (see rpmsg_eptdev_write_iter in rpmsg_char.c line 243 for an example) 2) Check the queue for space and return immediately with ENOMEM. (Saves the call to rpmsg_trysend and all its indirections). 3) Do both. (It's possible that trysend covers other cases than just kfifo full--but the kfifo check may be a useful optimization and catch 99%+ or all the cases quickly). Thanks. -- 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/dcb03907-1c54-4d83-8b42-6d396acbdd5co%40googlegroups.com.
[beagleboard] Re: Problems Reconfiguring GPIO's
1) While I'm always grateful for your responses, TJF, you need to understand that your answers almost always come across a bit ... abrupt. I presume it's a language thing as I couldn't possibly convey nuance in German. 2) You know the libpruio architecture cold, but none of your documentation explains it, at all. So, the relationship between kernel module, system groups, PRU, and user mode is not at all clear to newcomers who actually try to look at your libpruio library. 3) The reliance on FreeBASIC is an absolute non-starter for a *LOT* of people. While I'm sure you find it to be a superior tool, most people already find the BeagleBone forbidding enough. Adding another unfamiliar tool to the mix is not something most people are willing to do. Thanks. On Sunday, June 21, 2020 at 11:22:48 PM UTC-7, TJF wrote: > > > > Am Montag, 22. Juni 2020 07:45:44 UTC+2 schrieb Andrew P. Lentvorski: >> >> Neither userspace nor PRU can change a pinmux. >> > > Not correct. In a libpruio configuration all members of system-group > 'pruio' can pinmux from user space. That's why libpruio development is as > easy as Arduino development, but much more powerful. > *Because* you shunt the request through the custom kernel module. Telling people that they can pinmux from userspace simply confuses people further who are already probably plenty confused. -- 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/9e313800-286e-41fa-b20f-cee927ab9d1co%40googlegroups.com.
[beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
Nobody knows where I should file this bug? On Saturday, June 6, 2020 at 6:34:26 PM UTC-7, Andrew P. Lentvorski wrote: > > It appears that the problem is in rpmsg_pru.c. > > rpmsg_pru_read has the following code: > > if (kfifo_is_empty(>msg_fifo) && > (filp->f_flags & O_NONBLOCK)) > return -EAGAIN; > > > > rpmsg_pru_write presumably needs a similar piece of code with > kfifo_is_full() or it needs to look for O_NONBLOCK and then use > rpmsg_trysend instead of rpmsg_send. > > Unfortunately, I've got nowhere near the Linux kernel programming chops to > debate the implications of that. > > Presumably, I need to file a bug somewhere? > > Thanks. > -- 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/2c824e98-015d-4471-b787-a8c27ceaae5fo%40googlegroups.com.
[beagleboard] Re: Problems Reconfiguring GPIO's
On Thursday, June 18, 2020 at 10:11:20 AM UTC-7, Dennis Bieber wrote: > > > OTOH -- if the author could get it to work on a > BB AI (which has two /pairs/ of PRUs, and currently has nothing for > run-time pin-muxing -- requiring device tree edits for any thing that is > not a default)... > As I understand it, most of the pinmux issues on the AM57xx are due to a *chip* bug. I don't think anybody can work around them. -- 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/c2399ece-0e90-4c8b-9062-8522617e91e1o%40googlegroups.com.
[beagleboard] Re: Problems Reconfiguring GPIO's
On Sunday, June 21, 2020 at 10:45:44 PM UTC-7, Andrew P. Lentvorski wrote: > > > If you must have a pin that changes direction and you need to control it > from the PRU, you can use the digital I/O's on the IEP (industrial ethernet > peripheral). I can confirm that this works. > I probably need to clarify. I can confirm that you can *tri-state* an IEP output pin from the PRU. I actually used an input and output pin wired together so I could dodge the whole question of changing *direction*. -- 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/cabf9bf0-228e-458b-a1d6-dd9c44924ab1o%40googlegroups.com.
[beagleboard] Re: Problems Reconfiguring GPIO's
On Thursday, June 18, 2020 at 1:50:03 PM UTC-7, Dennis Bieber wrote: > > I can only state then, that a quick perusal of the online > documentation > (in particular, the github readme) gives this one the impression that the > package provides a specific program running on a PRU which must be used, > and that a host application, via a library, talks to that PRU to perform > I/O. If setting the configuration and subsequent I/O performed without > involving a PRU, it is not readily apparent. The presence of that warning > about the PRU being able to access any memory reinforces this, as it > implies that a PRU could write to the pin-mux registers to change > configuration. > Pinmuxing *must* be done from privileged mode (effectively: Linux kernel/kernel module only). Neither userspace nor PRU can change a pinmux. If you must have a pin that changes direction and you need to control it from the PRU, you can use the digital I/O's on the IEP (industrial ethernet peripheral). I can confirm that this works. See: https://groups.google.com/forum/#!msg/beagleboard/AcQ3lY03UD0/glUL7Rc-CgAJ https://e2e.ti.com/support/processors/f/791/t/445028 -- 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/f52441e9-53d3-435b-b1a6-d716c172e55fo%40googlegroups.com.
[beagleboard] Re: remoteproc write to PRU over rpmsg device blocks even when set non-blocking
It appears that the problem is in rpmsg_pru.c. rpmsg_pru_read has the following code: if (kfifo_is_empty(>msg_fifo) && (filp->f_flags & O_NONBLOCK)) return -EAGAIN; rpmsg_pru_write presumably needs a similar piece of code with kfifo_is_full() or it needs to look for O_NONBLOCK and then use rpmsg_trysend instead of rpmsg_send. Unfortunately, I've got nowhere near the Linux kernel programming chops to debate the implications of that. Presumably, I need to file a bug somewhere? Thanks. -- 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/f6632a0f-8a9d-47e3-9326-27c8c3a55e3eo%40googlegroups.com.
[beagleboard] remoteproc write to PRU over rpmsg device blocks even when set non-blocking
I was getting some strange bugs from some remoteproc stuff I was doing on a BBB, and eventually I tracked it down to the overunning the rpmsg system which can block for several seconds on a write. Okay, fine. No big deal. This is what poll() was made for--flip "/dev/rpmsg_pru30" to O_NONBLOCK, set up POLLOUT, wait for a write event, write the data, and check the error. Except that my overrun writes to "/dev/rpmsg_pru30" *still* block for several seconds (very bad) and then terminate with an Error 512 (huh?). I can handle the error, but the big problem is the blocking. That absolutely should not be allowed to happen. What's going on? And where do I file a bug about this? Thanks. # uname -a Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux -- 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/43a93c6a-d432-4487-b100-46b8f1981bdeo%40googlegroups.com.
[beagleboard] Re: PocketBeagle is sometimes running very hot with only minimal CPU activity
Agreed. 3G modems can pull a remarkable amount of power (up to 2A!) under certain circumstances. That's going to tax the power systems of the PocketBeagle pretty heavily. You need to have something which you can use to turn on/off the power to the modem which bypasses the PocketBeagle power systems (ie. connects the USB supply directly to the modem supply without diodes or regulators in between). -- 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/91e9ffaf-8103-47d6-abb0-df3d27d99b33%40googlegroups.com.
[beagleboard] Re: Could PRU read this signals?
You can certainly persist, but I'm going to point out the existence of chips like the AWR1843--"Single-chip 76-GHz to 81-GHz automotive radar sensor integrating DSP, MCU and radar accelerator": https://www.ti.com/product/AWR1843 This is about $30, and does all the RF-y things while sending your ADC data straight to a DSP and Cortex R4F with extra Radar-y things to accelerate analysis. This allows you to focus on analyzing the results instead of the guts of "implementing a radar". Anyways, good luck. Sounds like an interesting project. -- 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/efefc883-c17e-4076-a285-aa3e5b285892%40googlegroups.com.
[beagleboard] Re: Could PRU read this signals?
What are you actually trying to do? That's a 50Mbit sustained transfer rate if bit time is 20ns. 100Mbit if 10ns. And 4 channels. That's 200-400Mbps. You're moving a *TON* of data even at slower clock rates--there is no resource on the BBB that can keep that up very long. This seems quite questionable on the BBB ... even moreso if your timing diagram is valid (which I suspect it is not). First, given your diagram, the sampling point would have to be recovered. Note that the Clock, Data, and Frame are all coincident. Normally the clock falls in the middle of the data window. That's not easy to recover without a PLL. I doubt the BBB has enough resolution to hit the data stable point on the data with any reliability at 50MHz. Second, are you *actually* running at 50MHz? Are you considering every *cross* as the frequency (high-to-low on a single line) or are you considering an individual signal rise-to-rise as the frequency. Is that data changing every 20ns or every *10ns*? If it's 10ns, it's probably not possible. I would *STRONGLY* recommend that you use an FPGA. Even an incredibly cheap FPGA would deserialize that with ease and then you could put it into a form in which you might be able abuse something like the RMII from the Ethernet peripheral to transfer it out. But it's still a *LOT* of data. You need something that can handle gigabit speeds if you keep this up even for a couple milliseconds. Your best bet would be to use that FPGA to also decimate the data as well so that you're working with a reasonable amount of data. -- 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/6e6c7cb6-c5f0-45e7-8c0b-3843f21083cb%40googlegroups.com.
[beagleboard] Event for pinmux completion?
Is there some sort of event or flag for pinmux completion? It seems that an overlay can take up to about 10-15 seconds after login is enabled before the pin muxes actually land in the expected state. Thanks. -- 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/466e7792-1d23-41a0-9877-fe4eaaa42c2f%40googlegroups.com.
Re: [beagleboard] Should we put ID EEPROM's on capes anymore?
Thanks, Robert. Then I'll still install an EEPROM on my boards since there is still usefulness. -- 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/49249204-da2c-4ac5-93db-eee322eba75d%40googlegroups.com.
[beagleboard] Should we put ID EEPROM's on capes anymore?
Given that overlays have to be loaded at bootanyway, does it even make any sense to keep adding EEPROM for identification? Thanks. -- 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/57082b9f-c8a9-4873-a6f8-ae9d7a435828%40googlegroups.com.
Re: [beagleboard] How to configure extra USB gadgets on BBB?
Well, that documentation seems to be quite old and the shell script itself
seems to indicate that I should be using a different path to a composite
gadget (via libcomposite?), no? It also doesn't seem like I need to hack
the driver for things llike Ethernet anymore. Finally, that link only
mentions up to Windows 7, so I suspect it is quite old, at this point.
if [ "${kernel_major}" -lt "${compare_major}" ] ; then
use_old_g_multi
elif [ "${kernel_major}" -eq "${compare_major}" ] ; then
if [ "${kernel_minor}" -lt "${compare_minor}" ] ; then
use_old_g_multi
else
use_libcomposite
fi
else
use_libcomposite
fi
What am I missing? I am, quite obviously, unfamilar with all the
incantations around composite devices or I wouldn't be asking.
And my question about "Is there a way to do this without mangling the
am335x_evm.sh script?" still stands. It appears tha answer is "No.", but I
have so little experience around this that I really don't trust my gut
instincts to be useful here.
Thanks.
On Thursday, May 7, 2020 at 11:14:09 AM UTC-7, William Hermans wrote:
>
> https://www.kernel.org/doc/Documentation/usb/gadget_multi.rst
>
> On Thu, May 7, 2020 at 1:48 AM Andrew P. Lentvorski > wrote:
>
>> Is there a way to configure extra USB gadget endpoints in addition to the
>> BBB default ones or do I just have to go in and edit the am335x_evm.sh
>> script?
>>
>> Thanks.
>>
>> --
>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/378ec705-3e00-4fe9-aed1-66ba32506684%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/beagleboard/378ec705-3e00-4fe9-aed1-66ba32506684%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
--
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/8e896415-ddc8-47e2-812a-380b285374a9%40googlegroups.com.
[beagleboard] How to configure extra USB gadgets on BBB?
Is there a way to configure extra USB gadget endpoints in addition to the BBB default ones or do I just have to go in and edit the am335x_evm.sh script? Thanks. -- 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/378ec705-3e00-4fe9-aed1-66ba32506684%40googlegroups.com.
[beagleboard] Re: Full pinmux table for Pocketbeagle?
And of course I figure it out the moment I ask the world ... It's in Table 7 in the System Reference Manual. You have to use the horizontal scrollbar at the bottom of the table to expose the other pinmux modes. https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#711-p1-header Sorry to bother everybody. On Monday, March 9, 2020 at 2:23:40 AM UTC-7, Andrew P. Lentvorski wrote: > > Is there a full pinmux table for the Pocketbeagle headers somewhere? > > I'm specifically looking to see if any of the PRU Ethernet Peripheral > digital I/O (pr1_edio_data_out/pr1_edio_data_in) pins are mapped to > anything. > > Thanks. > > -- 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/5607fe81-13c2-44bf-9b4e-479c303b6785%40googlegroups.com.
[beagleboard] Full pinmux table for Pocketbeagle?
Is there a full pinmux table for the Pocketbeagle headers somewhere? I'm specifically looking to see if any of the PRU Ethernet Peripheral digital I/O (pr1_edio_data_out/pr1_edio_data_in) pins are mapped to anything. Thanks. -- 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/1c682cd9-e580-4e91-a288-7e49ba898230%40googlegroups.com.
[beagleboard] How to get src and dst for pru_rpmsg_send?
I seem to be missing something obvious: Where do I get the values for src and dst in the pru_rpmsg_send() function? The TI examples do a pru_rpmsg_receive() first and then echo back to the same src and dst. That seems ... odd. What's the point of having a variable src and dst if they are effectively hardwired to a single communication channel? Thanks. -- 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/6c621728-d703-403d-a9cd-727249c44d88%40googlegroups.com.
Re: [beagleboard] Can't get overlay to set pinmux for IEP
Much appreciated, Robert. I updated to the PRUCAPE file and tore out a
bunch of stuff I didn't need and that seems to be setting the pinmux
correctly.
Is there anything else in this file that can be removed?
Thanks.
// Code shamelessly copied from AM335X-PRU-RPROC-4-14-TI-PRUCAPE-00A0.dts
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black",
"ti,beaglebone-green";
// identification
part-number = "BB-PRUDAP";
version = "00A0";
/*
* Helper to show loaded overlays under:
/proc/device-tree/chosen/overlays/
*/
fragment@0 {
target-path="/";
__overlay__ {
chosen {
overlays {
BB-PRUDAP-00A0 = __TIMESTAMP__;
};
};
};
};
/*
* Free up the pins used by the cape from the pinmux helpers.
*/
fragment@1 {
target = <>;
__overlay__ {
P9_18_pinmux { status = "disabled"; };/* P9_18: spi0_d1 */
P9_17_pinmux { status = "disabled"; };/* P9_17: spi0_cs0 */
};
};
fragment@2 {
target = <_pinmux>;
__overlay__ {
bb_prudap_pins: pinmux_bb_prudap_pins {
pinctrl-single,pins = <
0x158 0x2D/* P9_18: spi0_d1.i2c1_sda, SLEWCTRL_FAST
| INPUT_EN | PULL_DISABLE | MODE5 (IEP-edio/digio data in 6) */
0x15c 0x2E/* P9_17: spi0_cs0.i2c1_scl,
SLEWCTRL_FAST | INPUT_EN | PULL_DISABLE | MODE6 (IEP-edio/digio data out 7)
*/
>;
};
};
};
fragment@3 {
target-path="/";
__overlay__ {
ocp {
#address-cells = <1>;
#size-cells = <1>;
pruss_soc_bus: pruss_soc_bus@4a326004 {
compatible = "ti,am3356-pruss-soc-bus";
reg = <0x4a326004 0x4>;
ti,hwmods = "pruss";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x4a30 0x8>;
status = "okay";
pruss: pruss@0 {
compatible = "ti,am3356-pruss";
reg = <0x0 0x8>;
interrupts = <20 21 22 23 24 25 26 27>;
interrupt-names = "host2", "host3", "host4",
"host5", "host6", "host7",
"host8", "host9";
#address-cells = <1>;
#size-cells = <1>;
ranges;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_prudap_pins>;
pruss_iep: iep@2e000 {
compatible = "syscon";
reg = <0x2e000 0x31c>;
};
};
};
};
};
};
};
--
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/ca27fc7b-0a17-40d1-8060-e639850ee5e5%40googlegroups.com.
[beagleboard] Can't get overlay to set pinmux for IEP
Am I doing something wrong or are my expectations incorrect?
I created an overlay file BB-PRUDAP-00A0 to take over P9_17 and P9_18 and
set them to the IEP.
I added it to uEnv.txt and apparently it loaded:
root@beaglebone:~/prudap/lkm/prudap_lkm# ls -al
/proc/device-tree/chosen/overlays/
total 0
drwxr-xr-x 2 root root 0 Jan 24 07:11 .
drwxr-xr-x 3 root root 0 Jan 24 07:11 ..
-r--r--r-- 1 root root 25 Jan 24 07:11 AM335X-PRU-RPROC-4-14-TI-00A0
-r--r--r-- 1 root root 25 Jan 24 07:11 BB-ADC-00A0
-r--r--r-- 1 root root 25 Jan 24 07:11 BB-BONE-eMMC1-01-00A0
-r--r--r-- 1 root root 25 Jan 24 07:11 BB-PRUDAP-00A0
-r--r--r-- 1 root root 9 Jan 24 07:11 name
It also seems to have exclusive control over the pins:
root@beaglebone:~# config-pin P9_17 pwm
ERROR: open() for /sys/devices/platform/ocp/ocp:P9_17_pinmux/state failed,
No such file or directory
However, when I check the actual pinmux values, I get:
[ 77.897980] prudap: spi0_cs0 pinmux state: 0x37
[ 77.897986] prudap: spi0_d1 pinmux state: 0x37
That's not what I expect. I expected to see 0x2E and 0x2D like I requested
in the overlay file.
What did I do wrong in the BB-PRUDAP-00A0.dts file. Those values are not
what I wanted, but I can override those values in a kernel module.
However, I expected the pinmux to be already set up due to the overlay file.
Any help would be appreciated.
Thanks.
BB-PRUDAP-00A0.dts file:
/dts-v1/;
/plugin/;
#include
#include
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black",
"ti,beaglebone-green";
// identification
part-number = "BB-PRUDAP";
version = "00A0";
// resources this cape uses
exclusive-use =
"P9.17",// spi0_cs0
"P9.18",// spi0_d1
"pruss_iep";// hardware ip used
/*
* Helper to show loaded overlays under:
/proc/device-tree/chosen/overlays/
*/
fragment@0 {
target-path="/";
__overlay__ {
chosen {
overlays {
BB-PRUDAP-00A0 = __TIMESTAMP__;
};
};
};
};
/*
* Free up the pins used by the cape from the pinmux helpers.
*/
fragment@1 {
target = <>;
__overlay__ {
P9_17_pinmux { status = "disabled"; };/* spi0_cs0 */
P9_18_pinmux { status = "disabled"; };/* spi0_d1 */
};
};
fragment@2 {
target = <_pinmux>;
__overlay__ {
bb_prudap_pins: pinmux_bb_prudap_pins {
pinctrl-single,pins = <
BONE_P9_17 0x2E/* spi0_cs0.i2c1_scl, SLEWCTRL_FAST
| INPUT_EN | PULL_DISABLE | MODE6 (IEP-edio/digio data out 7) */
BONE_P9_18 0x2D/* spi0_d1.i2c1_sda, SLEWCTRL_FAST |
INPUT_EN | PULL_DISABLE | MODE5 (IEP-edio/digio data in 6) */
>;
};
};
};
fragment@3 {
target = <_iep>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_prudap_pins>;
};
};
};
/boot/uEnv.txt for completeness:
root@beaglebone:~/prudap/lkm/prudap_lkm# cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.14.108-ti-r113
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation:
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-PRUDAP-00A0.dtbo
#uboot_overlay_addr5=/lib/firmware/.dtbo
#uboot_overlay_addr6=/lib/firmware/.dtbo
#uboot_overlay_addr7=/lib/firmware/.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_rproc (4.14.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.4.x-ti, 4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (6 = 384KB)
#uboot_fdt_buffer=0x6
###U-Boot Overlays###
cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet
#In the event of edid real failures,
[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux
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/357b76fe-3805-4ff4-b08b-91ddcf05862f%40googlegroups.com.
[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux
Okay, then I'm just missing something obvious. What is a GPIO-SS? What unit and what register address? I see no mention of "GPIO-SS" anywhere in the AM335x Technical Reference Manual. Normally, I associate SS with "slave select" which means SPI. I see that you *can* turn around the CS lines on the McSPI subsystem, but you have to switch from Master to Slave Mode. That doesn't seem like what you are suggesting. On Sunday, January 19, 2020 at 12:38:28 AM UTC-8, TJF wrote: > > > It was your idea to use the PRU-IEP module. I recommended to use a pin on > a GPIO-SS. > I went hunting for GPIO-SS--I didn't find anything. I went hunting for OE (output enable) in the PRU docs. I found one on the digio. I also found that TI used the IEP to implement the 1-Wire interface on the PRUCAPE. You were also implementing bidirectionality on a 1-Wire interface. I drew an, incorrect in retrospect, inference that people were using the IEP digio for bidirectional and tri-state functions. -- 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/a9624428-be6c-4558-a0b3-53acff9aee61%40googlegroups.com.
[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux
Well, sort of, except you omit the *EXTREMELY* important point that you install a custom kernel module in order to expose the clock activation and pinmux system to all users. Okay, yes, if I build a kernel module I now have full access to all registers on the system with no restrictions. That's sort of like swatting a fly with an H-Bomb, but it will work. This means that config-pin has a fairly significant bug in not being able to route the IEP pins. Has that bug ever been filed anywhere? -- 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/e4237fb2-126c-44ab-b7f6-f72071a1fd92%40googlegroups.com.
[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux
As far as I can tell, the old mmap() method fails. What's my next step?
#include
#include
#include
#include
#include
#include
#include
#include
#define CONTROL_MODULE_START ((uint32_t)0x44E1)
#define CONTROL_MODULE_END((uint32_t)0x44E11FFF)
#define CONTROL_MODULE_LENGTH (CONTROL_MODULE_END - CONTROL_MODULE_START + 1
)
// Official pin name for pr1_edio_data_out0 is SPI0_D1 in Mode 6
// Official pin name for pr1_edio_data_out1 is SPI0_CS0 in Mode 6
#define CONF_SPI0_D1_OFFSET 0x958
#define CONF_SPI0_CS0_OFFSET 0x95C
#define MODE_1 0x1
#define MODE_4 0x4
#define MODE_6 0x6
int main(int argc, char *argv[])
{
uint32_t volatile * control_mode_mapped_base = NULL;
int fd = open("/dev/mem", O_RDWR);
printf("/dev/mem opened: %d\n", fd);
printf("Mapping %X - %X (size: %X)\n", CONTROL_MODULE_START,
CONTROL_MODULE_END, CONTROL_MODULE_LENGTH);
uint32_t volatile * const control_module_mapped_base = mmap(NULL,
CONTROL_MODULE_LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
CONTROL_MODULE_START);
printf("Mapped base to: %p\n", control_module_mapped_base);
assert(control_mode_mapped_base != ((uint32_t volatile * const)(-1)));
uint32_t volatile * const u32_control_P9_17 = (control_module_mapped_base
+ (CONF_SPI0_CS0_OFFSET/4)); // / 4 is due to the way C handles a pointer
to uint32_t
uint32_t volatile * const u32_control_P9_18 = (control_module_mapped_base
+ (CONF_SPI0_D1_OFFSET/4));
*u32_control_P9_17 = MODE_1; // Fails to write
*u32_control_P9_18 = MODE_1;
printf("Mode for P9_17: %X\n", (*u32_control_P9_17 & 0x7)); // Read is
fine--config-pin will cause this to change apropriately
printf("Mode for P9_18: %X\n", (*u32_control_P9_18 & 0x7));
assert((*u32_control_P9_17 & 0x7) == MODE_1);
assert((*u32_control_P9_18 & 0x7) == MODE_1);
munmap((void *)control_mode_mapped_base, CONTROL_MODULE_LENGTH);
close(fd);
}
--
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/ed5d010b-fb1d-4809-a919-fa91513a7abf%40googlegroups.com.
[beagleboard] Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux
Is there a way to set the pinmux for a pin to the PRU Industrial Ethernet Peripheral from Linux (for example: set pin P9_17 to pr1_edio_data_out0)? If not, what would be the recommended way to do so? Thanks. -- 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/bc2f4d3b-3153-4dae-84bd-8524ddf25c70%40googlegroups.com.
[beagleboard] Re: Make PRU-controlled pin change direction or go tri-state?
On Thursday, January 16, 2020 at 8:39:20 AM UTC-8, TJF wrote: > > > In order to change direction for a pin on a GPIO-SS, it needs a write > access to its OE register. The PRU can do that. > Let me see if I have this straight, I need access to an output enable from the PRU. The only output enable I can see involves the Industrial Ethernet Peripheral. So, by setting the PINMUX up front to the IEP, I can route my data through the IEP DIGIO in order to gain the tri-state capability I want? That ... might actually be what I need. Thanks. -- 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/350f5a11-afb8-4070-9e17-b0f454f86178%40googlegroups.com.
Re: [beagleboard] Make PRU-controlled pin change direction or go tri-state?
On Thursday, January 16, 2020 at 9:58:39 AM UTC-8, Jason Kridner wrote:
>
>
>
> On Thu, Jan 16, 2020 at 3:39 AM Andrew P. Lentvorski > wrote:
> >
> > I've got to be missing something obvious, but I even after several
> rounds of RTFM, I can't seem to figure out how to get the PRU to change the
> direction of a pin or, at the very least, to let it go to a tri-state value.
> >
> > I would go out over the L3/L4 (although that kinda smashes the whole
> "real-time" thing), but won't that bump into the fact that the processor
> needs to be in supervisor mode?
>
> I see you got some other answers, but it might help you to qualify if you
> are using a chip-level GPIO or PRU-level GPIO.
>
> As mentioned, you don't need a supervisor mode to get to the L3 bus needed
> to configure the GPIO or pinmux. You do need to clear the STANDBY_INIT bit
> in SYSCFG. Then, the PRU can poke all the SoC registers that the ARM can.
> Below is an example that clears this bit, but doesn't need to do so,
> because the PRU GPIO bits are INSIDE the PRUSS, so I'll likely remove those
> lines from this example in the future.
>
>
I guess I'm still missing something because the following program doesn't
work. When I try to write to *u32_control_P9_27, nothing changes. I *CAN*
however read from it and config-pin can change it externally just fine.
So, I got the actual *pointer address* as well as various clocks and
enables correct since I can read it properly.
What did I get wrong?
#include
#include
#include "resource_table_empty.h"
volatile register uint32_t __R30; // 32 output gpios
volatile register uint32_t __R31; // 32 input gpios
#define CONTROL_MODULE_START ((uint32_t)0x44E1)
#define CONF_MCASP0_FSR_OFFSET 0x9A4
uint32_t volatile * const u32_control_P9_27 = (uint32_t volatile *
const)(CONTROL_MODULE_START
+ CONF_MCASP0_FSR_OFFSET);
#define PINMUX_PRU_OUT 0x5
#define PINMUX_PRU_IN 0x6
#define DELAY_CYCLES (5000/2)
void main(void) {
uint32_t const led = 0x0028; // Use pru0_pru_r30_5 and
pru0_pru_r32_3 as an output
// You can now monitor P9_28 frequency as reflecting state of P9_27
pinmux
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
unsigned int ui = 0;
unsigned int ui_fast = 0;
while (1) {
*u32_control_P9_27 = PINMUX_PRU_IN; // No effect on frequency
while config-pin causes expected frequency shifts
++ui;
if (((*u32_control_P9_27) & 0x07) == PINMUX_PRU_OUT) { // This
verifies that I actually got the correct address of the pinmux
ui_fast = 1;
} else {
ui_fast = 0;
}
__R30 = led;
__delay_cycles(DELAY_CYCLES);
if (ui_fast != 1) {
__delay_cycles(DELAY_CYCLES);
}
__R30 = 0;
__delay_cycles(DELAY_CYCLES);
if (ui_fast != 1) {
__delay_cycles(DELAY_CYCLES);
}
}
__halt();
}
--
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/437cd2db-6711-4dbe-ba19-0a781d0f31bd%40googlegroups.com.
[beagleboard] Make PRU-controlled pin change direction or go tri-state?
I've got to be missing something obvious, but I even after several rounds of RTFM, I can't seem to figure out how to get the PRU to change the direction of a pin or, at the very least, to let it go to a tri-state value. I would go out over the L3/L4 (although that kinda smashes the whole "real-time" thing), but won't that bump into the fact that the processor needs to be in supervisor mode? Any help would be appreciated. Thanks. -- 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/16640740-240b-4e94-950d-f4bbe369fb76%40googlegroups.com.
[beagleboard] Re: BBAI USB-C only enumerates as high speed device with cable in one orientation
I haven't checked the Bill of Materials, but if U22 (the TUSB322IRWBR USB-C control chip) is populated along with R533 and R534, then the board is out of spec for USB-C on the CC lines. On Thursday, November 7, 2019 at 7:15:01 AM UTC-8, nick.g...@gmail.com wrote: > > > Hello, > > I have noticed that my BBAI Rev A1, when connected to a PC, will enumerate > as a high-speed USB device with the USB-C connector in one orientation, and > a Super-Speed device with the connector oriented in the other direction > (simply flipped upside down). I have reproduced this across several > software revisions including the production emmc image: > http://debian.beagleboard.org/images/am57xx-eMMC-flasher-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz > > I checked the > https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#board-changes > > page and did not see any changes related to USB in any of the newer > revisions. I was wondering if there are others who also have experienced > this issue, or if it could be isolated to my specific board. I have > reproduced the issue with several different USB-C cables including a USB > A->USB-C and USB-C -> USB-C cable. > > First orientation: > >> Nov 6 13:54:36 lnx-nickg kernel: [606956.216954] usb 1-5: new high-speed >> USB device number 48 using xhci_hcd >> Nov 6 13:54:36 lnx-nickg kernel: [606956.346011] usb 1-5: New USB device >> found, idVendor=1d6b, idProduct=0104 >> Nov 6 13:54:36 lnx-nickg kernel: [606956.346013] usb 1-5: New USB device >> strings: Mfr=1, Product=2, SerialNumber=3 >> Nov 6 13:54:36 lnx-nickg kernel: [606956.346015] usb 1-5: Product: >> BeagleBone >> Nov 6 13:54:36 lnx-nickg kernel: [606956.346017] usb 1-5: Manufacturer: >> BeagleBoard.org >> Nov 6 13:54:36 lnx-nickg kernel: [606956.346018] usb 1-5: SerialNumber: >> 1234BBBK5678 > > Nov 6 13:54:36 lnx-nickg kernel: [606956.347593] usb-storage 1-5:1.2: USB >> Mass Storage device detected > > ... >> > > Second orientation: > >> Nov 6 14:04:53 lnx-nickg kernel: [607573.545068] usb 2-5: new SuperSpeed >> USB device number 32 using xhci_hcd >> Nov 6 14:04:53 lnx-nickg kernel: [607573.562236] usb 2-5: New USB device >> found, idVendor=1d6b, idProduct=0104 >> Nov 6 14:04:53 lnx-nickg kernel: [607573.562246] usb 2-5: New USB device >> strings: Mfr=1, Product=2, SerialNumber=3 >> Nov 6 14:04:53 lnx-nickg kernel: [607573.562252] usb 2-5: Product: >> BeagleBone >> Nov 6 14:04:53 lnx-nickg kernel: [607573.562258] usb 2-5: Manufacturer: >> BeagleBoard.org >> Nov 6 14:04:53 lnx-nickg kernel: [607573.562263] usb 2-5: SerialNumber: >> 1234BBBK5678 >> Nov 6 14:04:53 lnx-nickg kernel: [607573.567404] usb-storage 2-5:1.2: >> USB Mass Storage device detected >> > ... >> > -- 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/08088773-4022-4342-86f7-ee25a3537101%40googlegroups.com.
[beagleboard] Re: I2C Read with length in the first byte of the transaction
Well, if the SMBus Specification Version 2.0 Section "5.5.7 Block write/read" is goofy then, um, okay ... However, since this appears to be a standard part of SMBus, now I really do wish to ask "How do I do this with the Linux I2C drivers?" -- 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/a7b322ee-3e44-45b7-a8cd-1477824d6473%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: I2C Read with length in the first byte of the transaction
Looking at the driver at: https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-davinci.c It looks like i2c_davinci_isr() only terminates a read via terminate_read() which doesn't seem to have an exit path for completion without STOP. It would be nice if somebody with more experience than me could verify this, as I'm going to have to go to a bit-banged driver otherwise. -- 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/ff83fdcf-4a2e-4816-a0ae-fd9779ef61a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] I2C Read with length in the first byte of the transaction
Erm, unless you mean board. I'm using a Beaglebone Black Rev C running debian. uname -a Linux beaglebone 4.9.36-ti-r46 #1 SMP PREEMPT Tue Jul 11 21:05:08 UTC 2017 armv7l GNU/Linux On Monday, February 12, 2018 at 5:07:37 PM UTC-8, Wulf Man wrote: > > what part > > On 2/12/2018 6:03 PM, Andrew P. Lentvorski wrote: > > I'm trying to communicate with an I2C chip which returns the length of the > bytes to be read in the first byte of the transaction. This is fairly > straightforward on most primitive microcontrollers. > > But for the life of me, I cannot figure out how to do this on Linux. A > "read" always wants to put a stop bit after the transaction. I see > "I2C_M_NOSTART" which is probably what I need for the data bytes, but I > don't see a corresponding I2C_M_NOSTOP which is what I need for the first > byte. > > Any help would be appreciated. Thanks. > > What I need is this transaction sequence: > > (PROBLEM HERE--master processes length > byte) > -- > 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/2e7ae77f-21b3-46c2-9aff-4a32201bed55%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/2e7ae77f-21b3-46c2-9aff-4a32201bed55%40googlegroups.com?utm_medium=email_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- 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/b5e27af4-8a2d-41f5-a2aa-732cdc496e21%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] I2C Read with length in the first byte of the transaction
Under NDA. So, not in linux database. On Monday, February 12, 2018 at 5:07:37 PM UTC-8, Wulf Man wrote: > > what part > > On 2/12/2018 6:03 PM, Andrew P. Lentvorski wrote: > > I'm trying to communicate with an I2C chip which returns the length of the > bytes to be read in the first byte of the transaction. This is fairly > straightforward on most primitive microcontrollers. > > But for the life of me, I cannot figure out how to do this on Linux. A > "read" always wants to put a stop bit after the transaction. I see > "I2C_M_NOSTART" which is probably what I need for the data bytes, but I > don't see a corresponding I2C_M_NOSTOP which is what I need for the first > byte. > > Any help would be appreciated. Thanks. > > What I need is this transaction sequence: > > (PROBLEM HERE--master processes length > byte) > -- > 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/2e7ae77f-21b3-46c2-9aff-4a32201bed55%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/2e7ae77f-21b3-46c2-9aff-4a32201bed55%40googlegroups.com?utm_medium=email_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- 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/d81b79b7-69eb-4243-9e95-1c0aa974db54%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] I2C Read with length in the first byte of the transaction
I'm trying to communicate with an I2C chip which returns the length of the bytes to be read in the first byte of the transaction. This is fairly straightforward on most primitive microcontrollers. But for the life of me, I cannot figure out how to do this on Linux. A "read" always wants to put a stop bit after the transaction. I see "I2C_M_NOSTART" which is probably what I need for the data bytes, but I don't see a corresponding I2C_M_NOSTOP which is what I need for the first byte. Any help would be appreciated. Thanks. What I need is this transaction sequence: (PROBLEM HERE--master processes length byte) -- 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/2e7ae77f-21b3-46c2-9aff-4a32201bed55%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Trouble building a configfs for HID device on BBBW
Did you ever get an answer for this. I followed the directions at: https://wiki.tizen.org/USB/Linux_USB_Layers/Configfs_Composite_Gadget/Usage_eq._to_g_hid.ko And am now bumping into the same problem: root@beaglebone:/home/debian/cfg/usb_gadget/g1# pwd /home/debian/cfg/usb_gadget/g1 root@beaglebone:/home/debian/cfg/usb_gadget/g1# ls bcdDevice bcdUSB bDeviceClass bDeviceProtocol bDeviceSubClass bMaxPacketSize0 configs functions idProduct idVendor os_desc strings UDC root@beaglebone:/home/debian/cfg/usb_gadget/g1# ls -al /sys/class/udc total 0 drwxr-xr-x 2 root root 0 Jan 16 09:30 . drwxr-xr-x 58 root root 0 Jan 16 09:30 .. lrwxrwxrwx 1 root root 0 Jan 16 09:29 musb-hdrc.0.auto -> ../../devices/ platform/ocp/4740.usb/47401400.usb/musb-hdrc.0.auto/udc/musb-hdrc.0.auto root@beaglebone:/home/debian/cfg/usb_gadget/g1# echo musb-hdrc.0.auto > UDC -su: echo: write error: Device or resource busy root@beaglebone:/home/debian/cfg/usb_gadget/g1# echo musb-hdrc.0 > UDC -su: echo: write error: No such device root@beaglebone:/home/debian/cfg/usb_gadget/g1# uname -r 4.4.91-ti-r133 -- 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/8336d40f-ba83-4ce4-8de7-a8f6c14926bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BB-BONE-AUDI cape fails to load
Thanks to zmatt on the IRC channel this got resolved. The problem is that the am335x-boneblack-overlay.dtb does not define the symbol "clk_mcasp0". So, I had to use the am335x-boneblack-audio.dtb overlay instead. On Monday, June 26, 2017 at 1:31:27 AM UTC-7, Andrew P. Lentvorski wrote: > > > I'm trying to get my own audio cape to load so I thought I would start by > loading the built-in audio cape configuration and then copy that to make my > own. However, I can't seem to beat the cape manager into submission. I > can load the BB-UART1-00A0 overlay, but I can't load the > BB-BONE-AUDI-02-00A0: > > root@beaglebone:/sys/devices/platform# echo BB-UART1 > >/sys/devices/platform/bone_capemgr/slots > root@beaglebone:/sys/devices/platform# echo BB-BONE-AUDI > >/sys/devices/platform/bone_capemgr/slots > -bash: echo: write error: No such file or directory > root@beaglebone:/sys/devices/platform# echo BB-BONE-AUDI-02 > >/sys/devices/platform/bone_capemgr/slots > -bash: echo: write error: Invalid argument > root@beaglebone:/sys/devices/platform# cat > /sys/devices/platform/bone_capemgr/slots > 0: PF -1 > 1: PF -1 > 2: PF -1 > 3: PF -1 > 14: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-UART1 > > > > Any suggestions as to what I'm doing wrong? > > Thanks. > > root@beaglebone:/sys/devices/platform# uname -a > Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l > GNU/Linux > > > > > > > -- 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/4f9aebfe-74d1-49cf-9982-7512c9bd2bae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] BB-BONE-AUDI cape fails to load
I'm trying to get my own audio cape to load so I thought I would start by loading the built-in audio cape configuration and then copy that to make my own. However, I can't seem to beat the cape manager into submission. I can load the BB-UART1-00A0 overlay, but I can't load the BB-BONE-AUDI-02-00A0: root@beaglebone:/sys/devices/platform# echo BB-UART1 >/sys/devices/platform/bone_capemgr/slots root@beaglebone:/sys/devices/platform# echo BB-BONE-AUDI >/sys/devices/platform/bone_capemgr/slots -bash: echo: write error: No such file or directory root@beaglebone:/sys/devices/platform# echo BB-BONE-AUDI-02 >/sys/devices/platform/bone_capemgr/slots -bash: echo: write error: Invalid argument root@beaglebone:/sys/devices/platform# cat /sys/devices/platform/bone_capemgr/slots 0: PF -1 1: PF -1 2: PF -1 3: PF -1 14: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-UART1 Any suggestions as to what I'm doing wrong? Thanks. root@beaglebone:/sys/devices/platform# uname -a Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux -- 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/64517afa-fe48-49cd-9710-fa4f9015b442%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Applying patches before build_kernel.sh?
Thank you, Robert. -- 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/ca7c77f8-54a7-4d01-8e8d-595a8d1cc3bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Applying patches before build_kernel.sh?
If I'm using Robert C. Nelson's build scripts: (ie: git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git, git checkout tags/4.4.54-ti-r93 and then build_kernel.sh), what is the appropriate file/place/repository to inject patches to be picked up. Do I modify the repo in /ignore? Do I patch the one in KERNEL? Do I modify local_patch in patch.sh? Thanks. -- 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/e906c381-845b-4a76-8510-83d4fb026864%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] ADAU1372 Audio Codec Cape on Debian Jessie (4.4.54)
I've build a codec cape based around the Analog Devices ADAU1372. At this point, I can communicate with the device over I2C using i2cset/get and I can see audio data on the wire using my oscilloscope when I manually configure it. i2cdetect happily sees both my (as yet unconfigured) EEPROM at 0x50 and my codec at 0x3d. Analog Devices helpfully provides a Linux driver which I'm struggling to get built, but I suspect that's merely a matter of me banging my head off of it over enough time as it's sort of a relatively generic Linux task. What I don't have a clear idea about is how to tell Linux what pins are connected to what and how/when to connect to the driver module. I have dug through some of the device tree stuff, but a lot of it is for the 3.X series Angstrom kernels and doesn't seem to work correctly for the 4.X Debian kernels. Can someone point me to some up-to-date documentation or resources that I can dig through about this? Thanks. (Reposted and deleted original to fix horrific formatting ... sorry) root@beaglebone:~# uname -a Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux Linux driver: https://wiki.analog.com/resources/tools-software/linux-drivers/sound/adau1372 Chip datasheet: http://www.analog.com/en/products/audio-video/audio-codecs/adau1372.html root@beaglebone:~# i2cdetect -y -r 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- 3d -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- UU UU UU UU 58 -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@beaglebone:~# -- 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/15de3b6b-303e-441f-a10f-640a6d38c796%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] ADAU1372 Audio Codec Cape on Debian Jessie (4.4.54)
I've build a codec cape based around the Analog Devices ADAU1372. At this point, I can communicate with the device over I2C using i2cset/get and I can see audio data on the wire using my oscilloscope when I manually configure it. i2cdetect happily sees both my (as yet unconfigured) EEPROM at 0x50 and my codec at 0x3d. Analog Devices helpfully provides a Linux driver which I'm struggling to get built, but I suspect that's merely a matter of me banging my head off of it over enough time as it's sort of a relatively generic Linux task. What I don't have a clear idea about is how to tell Linux what pins are connected to what and how/when to connect to the driver module. I have dug through some of the device tree stuff, but a lot of it is for the 3.X series Angstrom kernels and doesn't seem to work correctly for the 4.X Debian kernels. Can someone point me to some up-to-date documentation or resources that I can dig through about this? Thanks. root@beaglebone:~# uname -a Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux Linux driver: https://wiki.analog.com/resources/tools-software/linux-drivers/sound/adau1372 Chip datasheet: http://www.analog.com/en/products/audio-video/audio-codecs/adau1372.html root@beaglebone:~# i2cdetect -y -r 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- 3d -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- UU UU UU UU 58 -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- 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/ad454599-4c75-4871-97fe-dae86d4815d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How write or use Can Bus driver on BBB with Ubuntu?
In the comments from the linked article you have this message: which cape is this tutorial for? I also have several TowerTech Can capes. > http://circuitco.com/support/index.php?title=TT3201_CAN_Cape > To which the original author responds: I did not use any cape when making this tutorial, I simply hooked up a CAN > transceiver to the relevant pins. However, I see now reason why it > shouldn't work with the cape, it may simply be a device tree conflict. > Note the need for a CAN transceiver. If you don't get this, you can't even start. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How write or use Can Bus driver on BBB with Ubuntu?
Huh? CANOpen/SocketCAN SDO transactions can have almost indefinite extent, have toggle bits that persist across frames, and CRC's that span the whole transaction. If you can eyeball that, you are way smarter than me. I think you may only be considering PDO transactions which are only ever 8 bytes max. On Sunday, August 30, 2015 at 8:37:14 AM UTC-7, William Hermans wrote: > > *Side note: wireshark is capable of decoding CAN packets and even the >> SocketCAN protocol!* > > > This is something I guess I'll never get. Whats the point ? socketcan > frames only have up to 8 byte data payloads . . .candump, and a good eye > for your data is all that is needed. > -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Offtopic: Sort threads by most recent post?
I feel really stupid asking this on the forum, but I can't seem to find the setting that would sort the threads by the latest post. Is this a group administrator setting rather than an individual setting? A quick Google search for variants on google groups sort thread by recent post -gmail doesn't cough up anything useful. Sorry to add this noise to the group. Thanks. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How write or use Can Bus driver on BBB with Ubuntu?
You don't get a choice. CAN *requires* a transceiver to convert from the TX/RX signals on the Beaglebone into the differential bus dominant/recessive that is the physical layer for CAN. In addition, you must have *TWO* can nodes in order to test communication. CAN *requires* an ACK before it will release the transmit buffer. I would really suggest that you start with something simpler like SPI or I2C (both of which can be used directly off of the Beaglebone connectors). CAN isn't hard, but it's not for beginners either. If you just want to play with the CAN protocol, use the Linux virtual can drivers. However, those won't put any signals on the wire so to speak as they truly are virtual. Side note: wireshark is capable of decoding CAN packets and even the SocketCAN protocol! On Friday, August 28, 2015 at 11:52:21 PM UTC-7, Onur Duran wrote: Thank you Andrew for your suggestion.But i don't want to use any extra hardware.I want to use direct BBB.Wonder if i couldn't find Can Bus driver for BBB ? 28 Ağustos 2015 Cuma 16:53:08 UTC+3 tarihinde Andrew P. Lentvorski yazdı: Well, you need a CAN cape of some form to provide a CAN transceiver. Something like this: http://www.logicsupply.com/cbb-serial/ After that, follow the directions that the manufacturer provides. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?
I can confirm this with a scope. After porting the kernel module from this topic: https://groups.google.com/forum/#!topic/beagleboard/dyuax5415dc I measured exactly 12.5MHz. Apparently mmap is doing something stupid that slows down the access from user space. On Monday, August 24, 2015 at 5:41:25 PM UTC-7, Charles Steinkuehler wrote: On 8/24/2015 7:26 PM, William Hermans wrote: So this is word of mouth from these very forums perhaps a couple years ago but I do recall someone ( as in someone qualified to know - don't remember exactly who ) saying that technically, GPIO's can be toggled on/off at 100-200 Mhz - Using a PRU. That's using the PRU direct I/O, *NOT* the GPIO pins. There's a difference. :) Even the PRU can only get about 12.5 MHz out of a GPIO pin, although it can _easily_ get 100 MHz toggle rates (200 MHz update rate) from the PRU direct outputs. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Building kernel modules fails for Debian Jessie Linux Arm 4.1.6
I tried a couple of different ways to build the hello world kernel module, but I seem to be lacking the proper build to use in my makefiles. So, I installed the linux headers, but I seem to be missing a classmap.h file. I also managed to get past git crashing by downloading the repo and then rsync'ing it to the BBB. So, after 8 hours(!), the BBB fully compiled a 4.1.6-ti-r12 build. So, if there is something I can do to build a kernel module using that tree and scripts, I can do that, too. What obvious thing am I missing? Thanks. The following NEW packages will be installed: linux-headers-4.1.6-ti-r11 0 upgraded, 1 newly installed, 0 to remove and 9 not upgraded. Need to get 6,992 kB of archives. After this operation, 52.9 MB of additional disk space will be used. Get:1 http://repos.rcn-ee.com/debian/ jessie/main linux-headers-4.1.6-ti-r11 armhf 1jessie [6,992 kB] Fetched 6,992 kB in 3s (2,199 kB/s) Selecting previously unselected package linux-headers-4.1.6-ti-r11. (Reading database ... 84339 files and directories currently installed.) Preparing to unpack .../linux-headers-4.1.6-ti-r11_1jessie_armhf.deb ... Unpacking linux-headers-4.1.6-ti-r11 (1jessie) ... Setting up linux-headers-4.1.6-ti-r11 (1jessie) ... root@arm:~/kernels# cd /lib/modules/`uname -r`/build root@arm:/lib/modules/4.1.6-ti-r11/build# ls arch block crypto Documentation drivers firmware fs include init ipc Kconfig kernel lib Makefile mm Module.symvers net samples scripts security sound tools usr virt root@arm:/lib/modules/4.1.6-ti-r11/build# make scripts scripts/kconfig/conf --silentoldconfig Kconfig HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/genheaders/genheaders.c:13:22: fatal error: classmap.h: No such file or directory #include classmap.h ^ compilation terminated. scripts/Makefile.host:91: recipe for target 'scripts/selinux/genheaders/genheaders' failed make[3]: *** [scripts/selinux/genheaders/genheaders] Error 1 scripts/Makefile.build:403: recipe for target 'scripts/selinux/genheaders' failed make[2]: *** [scripts/selinux/genheaders] Error 2 scripts/Makefile.build:403: recipe for target 'scripts/selinux' failed make[1]: *** [scripts/selinux] Error 2 Makefile:555: recipe for target 'scripts' failed make: *** [scripts] Error 2 root@arm:~/bb-kernel/mymodules# cat makefile obj-m += hello.o all: make -C /root/bb-kernel/KERNEL/tools/build M=$(PWD) modules clean: make -C /root/bb-kernel/KERNEL/tools/build M=$(PWD) clean root@arm:~/bb-kernel/mymodules# make make -C /root/bb-kernel/KERNEL/tools/build M=/root/bb-kernel/mymodules modules make[1]: Entering directory '/root/bb-kernel/KERNEL/tools/build' make[1]: *** No rule to make target 'modules'. Stop. make[1]: Leaving directory '/root/bb-kernel/KERNEL/tools/build' makefile:5: recipe for target 'all' failed make: *** [all] Error 2 root@arm:~/bb-kernel/mymodules# -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How write or use Can Bus driver on BBB with Ubuntu?
Well, you need a CAN cape of some form to provide a CAN transceiver. Something like this: http://www.logicsupply.com/cbb-serial/ After that, follow the directions that the manufacturer provides. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Building kernel modules fails for Debian Jessie Linux Arm 4.1.6
On Friday, August 28, 2015 at 2:11:43 PM UTC-7, RobertCNelson wrote: bb-kernel repo has w.x.y-bonez kernel names... https://github.com/RobertCNelson/ti-linux-kernel-dev has what your are looking for kernel source... Aha! Thank you. That was the piece I was missing. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Building kernel modules fails for Debian Jessie Linux Arm 4.1.6
After I clean up my own two *very* stupid errors of not capitalizing the name of the Makefile and installing the *r12* headers (I had r11), it compiles and inserts. During my experiments, though, I came across something odd. As the missing piece appeared to be this symlink: root@arm:~/mymodules# ls -al /lib/modules/4.1.6-ti-r12/build lrwxrwxrwx 1 root root 35 Aug 26 21:17 /lib/modules/4.1.6-ti-r12/build - /usr/src/linux-headers-4.1.6-ti-r12 To make r12 compile, I tried creating this symlink: root@arm:/# ln -s /root/bb-kernel/KERNEL /lib/modules/4.1.6-ti-r12/build Which does compile, but unfortunately doesn't seem to get the module info correct, so I can't insmod: root@arm:~/mymodules# insmod hello.ko insmod: ERROR: could not insert module hello.ko: Invalid module format root@arm:~/mymodules# modinfo hello.ko filename: /root/mymodules/hello.ko description:A Simple Hello World module depends: vermagic: 4.1.6-bone15 mod_unload modversions ARMv7 thumb2 p2v8 root@arm:~/mymodules# uname -r 4.1.6-ti-r12 The conflict appears to be that vermagic gets set to 4.1.6-bone15 instead of r12. Anyway, thanks for the advice. For the record, here is my new Makefile (careful copying as make is nuts about tabs vs spaces): root@arm:~/mymodules# cat Makefile obj-m += hello.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 -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Best way to build a kernel module *on* the Beaglebone Black?
While on my BBB, I tried to follow the directions for building a kernel from here: https://eewiki.net/display/linuxonarm/BeagleBone+Black Unfortunately, when I try to do ./build-kernel.sh to populate everything to deploy, git dies with error: index-pack died of signal 9555. Presumably, it runs out of RAM. So, what's the best way to build kernel modules on the BBB for 4.1.6? Thanks. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Can't seem to enable SPI0 on Beaglebone Black on Debian Jessie with 4.1.6 kernel
Well, I still don't know why the overlays aren't working, but I seem to
have gotten the clocks toggled correctly to avoid a SIGBUS Bus Error.
This code turns on the clocks and waits for them to become stable. Then it
reads the SPI0 version register for confirmation.
#include stdint.h
#include unistd.h
#include fcntl.h
#include sys/mman.h
#include stdio.h
#include assert.h
// Hunt these addresses down from ls -al /sys/devices/platform/ocp | grep
gpio
// You can also pull them from the TI manual (spruh73l.pdf)
#define CM_PER_BASE 0x44E0
#define CM_PER_SIZE 0x4000
#define CM_PER_SPI0_CLKCTRL 0x4C
#define CM_PER_L4LS_CLKCTRL 0x60
#define MCSPI0_BASE 0x4803
#define MCSPI0_SIZE 0x1000
#define MCSPI_REVISION (0x000)
#define MCSPI_SYSCONFIG (0x110)
#define MCSPI_SYSSTATUS (0x114)
#define MCSPI_SYST (0x124)
#define MCSPI_MODULCTRL (0x128)
#define MCSPI_CH0CONF (0x12C)
#define MCSPI_CH0STAT (0x130)
#define MCSPI_CH0CTRL (0x134)
int main(int argc, char *argv[])
{
uint8_t volatile * bbCM_PERMap = NULL;
uint8_t volatile * bbMCSPI0Map = NULL;
uint32_t ui32tmp = 0;
uint32_t volatile * ppui32tmp = NULL;
int fd = open(/dev/mem, O_RDWR);
bbCM_PERMap = mmap(0, CM_PER_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, CM_PER_BASE);
assert(bbCM_PERMap != MAP_FAILED);
*(uint32_t volatile *)(bbCM_PERMap+CM_PER_L4LS_CLKCTRL) = 0x0002;
// Enable L4LS_CLK
do {
ui32tmp = *(uint32_t volatile *)(bbCM_PERMap+CM_PER_SPI0_CLKCTRL);
sleep(1);
} while (((ui32tmp 16) 0x0003) != 0); // Wait for L4LS_CLK to
come up
*(uint32_t volatile *)(bbCM_PERMap+CM_PER_SPI0_CLKCTRL) = 0x0002;
// Enable SPI0 CLK
do {
ui32tmp = *(uint32_t volatile *)(bbCM_PERMap+CM_PER_SPI0_CLKCTRL);
sleep(1);
} while (((ui32tmp 16) 0x0003) != 0); // Wait for module to
come up
bbMCSPI0Map = mmap(0, MCSPI0_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, MCSPI0_BASE);
assert(bbMCSPI0Map != MAP_FAILED);
ppui32tmp = (uint32_t volatile *)bbMCSPI0Map;
assert(bbMCSPI0Map == ppui32tmp);
ui32tmp = *ppui32tmp; // Read the revision register
printf(SPI0 Revision: 0x%08x\n, ui32tmp);
close(fd);
return 0;
}
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Can't seem to enable SPI0 on Beaglebone Black on Debian Jessie with 4.1.6 kernel
I followed the directions here (as best I could given that device tree
filenames have changed position again ...
sigh): http://elinux.org/BeagleBone_Black_Enable_SPIDEV
Something seems wrong as I'm picking up /dev/spidev1.0 instead of
/dev/spidev0.0
And when I try to mmap the SPI region and read it, I get a bus error.
Any suggestions?
Thanks.
root@arm:~# uname -a
Linux arm 4.1.6-ti-r11 #1 SMP PREEMPT Tue Aug 18 21:36:11 UTC 2015 armv7l
GNU/Linux
I used this file for the overlay:
root@arm:~# cat BB-SPI0-01-00A0.dts
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = spi0pinmux;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
spi0_pins_s0: spi0_pins_s0 {
pinctrl-single,pins =
0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */
0x154 0x30 /* spi0_d0, INPUT_PULLUP | MODE0 */
0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */
0x15c 0x10 /* spi0_cs0, OUTPUT_PULLUP | MODE0 */
;
};
};
};
fragment@1 {
target = spi0;
__overlay__ {
#address-cells = 1;
#size-cells = 0;
status = okay;
pinctrl-names = default;
pinctrl-0 = spi0_pins_s0;
spidev@0 {
spi-max-frequency = 2400;
reg = 0;
compatible = linux,spidev;
};
};
};
};
But when I enable it I seem to be picking up then wrong SPI interface?
root@arm:~# echo BB-SPI0-01 /sys/devices/platform/bone_capemgr/slots
root@arm:~# ls -al /dev/spidev*
crw-rw 1 root spi 153, 0 Aug 25 10:02 /dev/spidev1.0
I can see it in the pin groups:
root@arm:~# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
registered pin groups:
group: pinmux_clkout2_pin
pin 109 (44e109b4.0)
group: pinmux_uart0_pins
pin 92 (44e10970.0)
pin 93 (44e10974.0)
group: pinmux_mmc1_pins
pin 60 (44e108f0.0)
pin 61 (44e108f4.0)
pin 62 (44e108f8.0)
pin 63 (44e108fc.0)
pin 64 (44e10900.0)
pin 65 (44e10904.0)
pin 104 (44e109a0.0)
pin 88 (44e10960.0)
group: pinmux_mmc1_pins_sleep
pin 60 (44e108f0.0)
pin 61 (44e108f4.0)
pin 62 (44e108f8.0)
pin 63 (44e108fc.0)
pin 64 (44e10900.0)
pin 65 (44e10904.0)
pin 104 (44e109a0.0)
pin 88 (44e10960.0)
group: user_leds_s0
pin 21 (44e10854.0)
pin 22 (44e10858.0)
pin 23 (44e1085c.0)
pin 24 (44e10860.0)
group: pinmux_i2c0_pins
pin 98 (44e10988.0)
pin 99 (44e1098c.0)
group: pinmux_i2c2_pins
pin 94 (44e10978.0)
pin 95 (44e1097c.0)
group: cpsw_default
pin 66 (44e10908.0)
pin 67 (44e1090c.0)
pin 68 (44e10910.0)
pin 69 (44e10914.0)
pin 70 (44e10918.0)
pin 71 (44e1091c.0)
pin 72 (44e10920.0)
pin 73 (44e10924.0)
pin 74 (44e10928.0)
pin 75 (44e1092c.0)
pin 76 (44e10930.0)
pin 77 (44e10934.0)
pin 78 (44e10938.0)
pin 79 (44e1093c.0)
pin 80 (44e10940.0)
group: cpsw_sleep
pin 66 (44e10908.0)
pin 67 (44e1090c.0)
pin 68 (44e10910.0)
pin 69 (44e10914.0)
pin 70 (44e10918.0)
pin 71 (44e1091c.0)
pin 72 (44e10920.0)
pin 73 (44e10924.0)
pin 74 (44e10928.0)
pin 75 (44e1092c.0)
pin 76 (44e10930.0)
pin 77 (44e10934.0)
pin 78 (44e10938.0)
pin 79 (44e1093c.0)
pin 80 (44e10940.0)
group: davinci_mdio_default
pin 82 (44e10948.0)
pin 83 (44e1094c.0)
group: davinci_mdio_sleep
pin 82 (44e10948.0)
pin 83 (44e1094c.0)
group: spi0_pins_s0
pin 84 (44e10950.0)
pin 85 (44e10954.0)
pin 86 (44e10958.0)
pin 87 (44e1095c.0)
Program which returns a Bus Error:
root@arm:~/gpio# clang -Wall -g -o spi_test spi.c
root@arm:~/gpio# ./spi_test
Bus error
root@arm:~/gpio# cat spi.c
#include stdint.h
#include unistd.h
#include fcntl.h
#include sys/mman.h
#include assert.h
// Hunt these addresses down from ls -al /sys/devices/platform/ocp | grep
gpio
// You can also pull them from the TI manual (spruh73l.pdf)
#define MCSPI0_BASE 0x4803
#define MCSPI0_SIZE 0x1000
#define MCSPI_REVISION (0x000)
#define MCSPI_SYSCONFIG (0x110)
#define MCSPI_SYSSTATUS (0x114)
#define MCSPI_SYST (0x124)
#define MCSPI_MODULCTRL (0x128)
#define MCSPI_CH0CONF (0x12C)
#define MCSPI_CH0STAT (0x130)
#define MCSPI_CH0CTRL (0x134)
int main(int argc, char *argv[])
{
uint8_t volatile * bbMCSPI0Map = NULL;
uint32_t ui32tmp = 0;
int fd = open(/dev/mem, O_RDWR);
bbMCSPI0Map = mmap(0, MCSPI0_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, MCSPI0_BASE);
assert(bbMCSPI0Map != MAP_FAILED);
ui32tmp = *(uint32_t volatile *)(bbMCSPI0Map + MCSPI_SYSSTATUS);
assert((ui32tmp 0x0001) != 0);
//while(1) {
//}
close(fd);
return 0;
}
--
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.
For more options, visit
[beagleboard] BeagleBone Black GPIO a bit slow via /dev/mem and mmap?
Hi, folks,
I have been trying to bit bang an interface on the GPIO pins. I looked at
a bunch of the tutorials on the web and managed to build something that
worked. However, the speed seems to be a bit slower than I would expect.
My scope shows that I am running at about 2.95MHz (It also roughly matches
the result from here--http://chiragnagpal.com/examples.html of 2.78MHz).
That seems slow--I would have expected closer to 25MHz--so I think I'm an
order of magnitude off somewhere The assembly code seems to be as
expected, so my question is:
What is slowing things down?
Since the assembly is basically ldr/str in a chain, something must be
stalling the pipeline, but I don't know what.
Suggestions would be appreciated.
I'm running Debian Jessie Linux arm 4.1.6-ti-r11 #1 SMP PREEMPT Tue Aug 18
21:36:11 UTC 2015 armv7l GNU/Linux
Thanks.
The assembly code looks optimal at 4 instructions per toggle (I'm using
clang):
.loc2 80 2 @ gpi.c:80:2
ldr r1, [sp, #28]
str r0, [r1]
.loc2 81 9 @ gpi.c:81:9
ldr r1, [sp, #32]
str r0, [r1]
.loc2 82 2 @ gpi.c:82:2
ldr r1, [sp, #28]
str r0, [r1]
.loc2 83 9 @ gpi.c:83:9
ldr r1, [sp, #32]
str r0, [r1]
The C Code I used to toggle the pin P9_23 (GPIO1_17):
#include stdint.h
#include stdio.h
#include stdlib.h
#include sys/mman.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include assert.h
#define GPIO_OE 0x134
#define GPIO_SETDATAOUT 0x194
#define GPIO_CLEARDATAOUT 0x190
// Hunt these addresses down from ls -al /sys/devices/platform/ocp | grep
gpio
// You can also pull them from the TI manual (spruh73l.pdf)
#define GPIO0_BASE 0x44E07000
#define GPIO1_BASE 0x4804C000
#define GPIO2_BASE 0x481AC000
#define GPIO3_BASE 0x481AE000
#define GPIO_SIZE 0x1000
#define PIN_17 ((uint32_t)117)
uint32_t ui32Base[] = {GPIO0_BASE, GPIO1_BASE, GPIO2_BASE, GPIO3_BASE};
uint8_t volatile * bbGPIOMap[] = {0, 0, 0, 0};
int main(int argc, char *argv[])
{
unsigned int ui;
uint32_t volatile * gpio_oe_addr = NULL;
uint32_t volatile * gpio_setdataout_addr = NULL;
uint32_t volatile * gpio_cleardataout_addr = NULL;
int fd = open(/dev/mem, O_RDWR);
for(ui=0; ui4; ++ui) {
bbGPIOMap[ui] = mmap(0, GPIO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
ui32Base[ui]);
assert(bbGPIOMap[ui] != MAP_FAILED);
}
gpio_oe_addr = (uint32_t volatile *)(bbGPIOMap[1] + GPIO_OE);
gpio_setdataout_addr = (uint32_t volatile *)(bbGPIOMap[1] +
GPIO_SETDATAOUT);
gpio_cleardataout_addr = (uint32_t volatile *)(bbGPIOMap[1] +
GPIO_CLEARDATAOUT);
*gpio_oe_addr = *gpio_oe_addr ~PIN_17;
while(1) {
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
}
//*(uint32_t volatile *)(bbGPIOMap[3] + GPIO_SETDATAOUT) = (uint32_t)1
14;
//*(uint32_t volatile *)(bbGPIOMap[3] + GPIO_CLEARDATAOUT) =
(uint32_t)1 14;
close(fd);
return 0;
}
--
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.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] BeagleBone Black GPIO access via mmap is slow
Hi, folks,
I've been poking around to get GPIO to work via /dev/mem and mmap. After
finally pushing a lot of things around, I finally managed to pull the
various flavors of tutorials together into something I now understand
(mostly).
However, what I *don't* understand is that when I put my scope on the pin,
I see it toggle at 2.95MHz. That seems slow. This is the same frequency
as here: http://chiragnagpal.com/examples.html
The question is: Why?
I could understand if it was something like 30MHz, but 3MHz seems off by an
order of magnitude. And when something seems off in embedded programming,
it's usually a bug waiting to bite you when you least need it.
I'm on a BeagleBoard Black with Debian Jessie Linux arm 4.1.6-ti-r11 #1 SMP
PREEMPT Tue Aug 18 21:36:11 UTC 2015 armv7l GNU/Linux
Any suggestions? Given that the assembly seems to be spot on, *something*
appears to be stalling the pipeline.
Is the core being throttled? Is the peripheral bus at some strange
frequency? Is the memory mapping hardware inserting cycles? I'm
completely at a loss.
Thanks for any advice.
The assembly looks exactly optimal with a ldr/str sequence at maximum
density (I'm using clang):
.loc 2 83 9 @ gpi.c:83:9
ldr r1, [sp, #32]
str r0, [r1]
.loc 2 84 2 @ gpi.c:84:2
ldr r1, [sp, #28]
str r0, [r1]
.loc 2 85 9 @ gpi.c:85:9
ldr r1, [sp, #32]
str r0, [r1]
.loc 2 86 2 @ gpi.c:86:2
ldr r1, [sp, #28]
str r0, [r1]
And here's the C code I used to generate the pulse train on P9 Pin23
(GPIO1[17])
#include stdint.h
#include stdio.h
#include stdlib.h
#include sys/mman.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include assert.h
#define GPIO_OE 0x134
#define GPIO_SETDATAOUT 0x194
#define GPIO_CLEARDATAOUT 0x190
// Hunt these addresses down from ls -al /sys/devices/platform/ocp | grep
gpio
// You can also pull them from the TI manual (spruh73l.pdf)
#define GPIO0_BASE 0x44E07000
#define GPIO1_BASE 0x4804C000
#define GPIO2_BASE 0x481AC000
#define GPIO3_BASE 0x481AE000
#define GPIO_SIZE 0x1000
#define PIN_17 ((uint32_t)117)
uint32_t ui32Base[] = {GPIO0_BASE, GPIO1_BASE, GPIO2_BASE, GPIO3_BASE};
uint8_t volatile * bbGPIOMap[] = {0, 0, 0, 0};
int main(int argc, char *argv[])
{
unsigned int ui;
uint32_t volatile * gpio_oe_addr = NULL;
uint32_t volatile * gpio_setdataout_addr = NULL;
uint32_t volatile * gpio_cleardataout_addr = NULL;
int fd = open(/dev/mem, O_RDWR);
for(ui=0; ui4; ++ui) {
bbGPIOMap[ui] = mmap(0, GPIO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
ui32Base[ui]);
assert(bbGPIOMap[ui] != MAP_FAILED);
}
gpio_oe_addr = (uint32_t volatile *)(bbGPIOMap[1] + GPIO_OE);
gpio_setdataout_addr = (uint32_t volatile *)(bbGPIOMap[1] +
GPIO_SETDATAOUT);
gpio_cleardataout_addr = (uint32_t volatile *)(bbGPIOMap[1] +
GPIO_CLEARDATAOUT);
*gpio_oe_addr = *gpio_oe_addr ~PIN_17;
while(1) {
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
*gpio_setdataout_addr = PIN_17;
*gpio_cleardataout_addr = PIN_17;
}
close(fd);
return 0;
}
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BeagleBone Black GPIO a bit slow via /dev/mem and mmap?
On Monday, August 24, 2015 at 7:27:35 AM UTC-7, Charles Steinkuehler wrote: Optimal would be a sequence of successive stores to the set and clear register, with the addresses pre-calculated and sitting in registers (or with a base address and use the str instruction with an immediate offset). Good point. I can beat the compiler into submission if I want to, but it's probably not worth the effort as I need to do other logic anyway. You might also need to move the volatile on the variable definitions. I'm not a C guru, but I think: uint32_t volatile * gpio_setdataout_addr ...is different from: volatile uint32_t * gpio_setdataout_addr ...you want the uint32_t to be volatile, not the pointer to it. This is one of those C quirks. It's actually a habit from const but it applies to volatile as well. Oddly, the qualifiers generally apply to the *left* except under certain circumstances where they can apply right. This gets people into trouble when they specify: volatile uint32_t volatile * blah; Which is actually a *redundant* specifier as opposed to what they wanted: volatile uint32_t * volatile blah; Not every compiler (*especially* embedded ones) will eject a warning on the duplicate declaration specifier. So, I personally always put them on the right to avoid the issue. ...but I write C code like a hardware guy who programs in VHDL. :) Not a damn thing wrong with that, thank you very much. Software-only people tend to be amazed that you can write a state machine that is *readable* in code. A very experienced programmer once told me: Your code is the most straightforward code I have ever read. Of course, I have to condemn you as a dirty apostate for not using Verilog. :) (Seriously, though, when is somebody going to produce an open-source VHDL simulator/compiler so that I can actually use it on projects?) Regardless, note that the maximum toggle rate of a GPIO pin using the PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a write by the on-chip communication fabric (which means 80 nS period for a high/low toggle of the pin). This assumes the CPU and the PRU have similar bandwidth to the L4 fabric, which may or may not be the case (but I suspect is true). Do you have a pointer to the reference manual for this (if not, don't waste a lot of time, I'll dig it out)? Given that this seems to be *very* fundamental about understanding the architecture, I really probably need to chase this down exactly. Thanks for the advice. I appreciate your taking the time on this. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?
I've been trying to hunt down the maximum frequency on the BeagleBone Black GPIO pins. This *seems* to be dominated by the transaction latency across the L3/L4 interconnect. Fair enough. So ... What's the latency number? I've *measured* about 166ns per transaction (I can create a roughly 3MHz toggle which is 2 pin flips which requires 6MTransactions/s which is 166.66ns per transaction). But I don't know how to *calculate* that number from the documentation. I've been through the TI reference manuals, the TI support forums, and a bunch of other things, but *nobody* seems to be able to cough up an actual number for this. Anybody have some references to frequencies and bus wait numbers? They may be out there, but GTMF/RTFM doesn't seem to be sufficient. I don't need turbo speed, but the fact that it's entirely possible that I may not even be able run at 1MHz (something *painfully* easy for most M0 or M3/M4 cores) is, frankly, a bit of a shock. Thanks. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BeagleBone Black GPIO a bit slow via /dev/mem and mmap?
On Monday, August 24, 2015 at 5:10:11 PM UTC-7, William Hermans wrote: I think the actual scope matters more. e.g. global versus local scope. But maybe I'm remembering wrongly as I recall reading something to this effect years ago. Anyway, I find this link the best single resource for explaining what volatile *is* - And . . I'm not trying to start an argument or anything, I just like discussing programming in general. http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword Um, that article is in violent agreement with me. :) Incidentally, for a great explanation of why you have a choice of where to place volatile and why you should place it after the data type (for example, int volatile * foo), read Dan Sak's column Top-Level cv-Qualifiers in Function Parameters (Embedded Systems Programming, February 2000, p. 63). -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BeagleBone Black GPIO max frequency/bus latency (without using PRU)?
On Monday, August 24, 2015 at 5:39:54 PM UTC-7, Charles Steinkuehler wrote: On 8/24/2015 6:12 PM, Andrew P. Lentvorski wrote: I've been trying to hunt down the maximum frequency on the BeagleBone Black GPIO pins. This *seems* to be dominated by the transaction latency across the L3/L4 interconnect. Fair enough. So ... What's the latency number? I've *measured* about 166ns per transaction (I can create a roughly 3MHz toggle which is 2 pin flips which requires 6MTransactions/s which is 166.66ns per transaction). But I don't know how to *calculate* that number from the documentation. I've measured 40 ns from the PRU. I'm not sure if the CPU can match this, but I'd be surprised if it couldn't. Well, there could be some silliness involving the fact that the memory is mmap'd in Linux. A TLB access or something similar might be required that could add overhead. This is a bit lower level than you'll find in most reference manuals, and falls into the category of if it's _really_ important to you, contact the manufacturer and verify...and I hope you're buying a *LOT* of parts, because this is the sort of thing that is subject to change with die revisions. :) It actually surprises me that this information isn't documented. However, I presume it's because most people using this high-end a processor really only use the peripherals. The only thing most people really use the GPIO's for is generating interrupts. I suspect I could live with things as they stand, but this is really going to make things ... annoying. I may be better off just trying to do nasty things to the McSPI subsystem. SPI really doesn't like bi-directional data lines, though. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Beaglebone Mac OSX = NIGHTMARE
Thanks for this. I'll pull this into a separate thread as we're drifting way off-topic now ... -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Beaglebone Mac OSX = NIGHTMARE
Unlike the original poster, I'm not taking offense. People are doing the best they can. However, I will say that, as a user, spelunking through BeagleBone Black documentation has been kind of painful. If you can stay at the Python/Javascript level, things are quite decent. Even basic Linux stuff is fine. However, once you need to get down into the Linux device level, the number of people who really understand what is going on drops very quickly. And I suspect those vitally important people are so overwhelmed doing real work or paid work and that they really don't have the bandwidth for random documentation and tutorial construction. And, even if they did, how many people would it benefit? Sure, I'd love to have some really detailed tutorials since most of them older than even 6 months generally don't work, but if there are only 5 of us who could make use of those tutorials, is it a good use of time? Especially when there is so much flux right now? I see about 30 BeagleBone Black compatible capes; the fact that some of those don't work directly under Debian shows that even highly knowledgable people don't understand all the implications. So, that bounds the number of people who can talk intelligently about kernel device stuff (and that's of the right order of magnitude for views). That's not a very big pool to draw from. I do agree, however, that the original poster is out of line. Anybody who does real embedded development on OS X knows to keep Windows XP, Windows 7, and Linux virtual machines on tap. If it works directly on OS X, that's a nice bonus, but counting on it is just asking for trouble--and OS X 10.10 has been a general disaster on many fronts. On Tuesday, February 24, 2015 at 6:10:51 PM UTC-8, RobertCNelson wrote: On Tue, Feb 24, 2015 at 8:00 PM, Andrew P. Lentvorski bsd...@gmail.com javascript: wrote: To be fair, ranting at least got him a response. Lots of people seem to be asking questions and I see like single digit views and no responses. It feels like a ghost town in here. Well the unfortunate side of open source.. Most developers are not paid to answer just questions. Instead they are here on their own free time. So unless you entice them with an interesting topic/question, they aren't going to take time to answer it. Sorry if this offends anyone. btw, google groups also emails these topics to registered users, so just because the forum interface shows a few views doesn't actually show the whole story.. Some of us read every 'email' and answer where we can. Regards, -- Robert Nelson http://www.rcn-ee.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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Beaglebone Mac OSX = NIGHTMARE
To be fair, ranting at least got him a response. Lots of people seem to be asking questions and I see like single digit views and no responses. It feels like a ghost town in here. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] CAN-CAPE TT3201 CAN/CANBUS on BeagleBone Black Redux
Anyway ... tl;dr I can verify that 2 of the 3 CANBUS interfaces on the TT3201 work. The third looks like it should work, but I didn't verify it. For those who would like to actually use the thing, here's the notes I was taking as I was going along in case I need to repeat this: Dealing with CANBUS on the TT3201 with BeagleBone Black: 1) Start from Angstrom Distribution (BeagleBone, BeagleBone Black - 4GB SD) 2013-06-20 https://s3.amazonaws.com/angstrom/demo/beaglebone/Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.06.20.img.xz 2) Expanded partition to 16GB--I did everything from a uSD card rather than eMMC which seems to sidestep some collisions and timing problems with certain things that people reported on different groups. 3) opkg update 4) opkg upgrade (This dance required a couple of rounds and I had to shut down services on port 80 to get around an error) Lather/rinse/repeat 34 until it converges. 5) Upgrade the kernel TowerTech's 3.8.13+ custom thing that you have to get directly from them Really guys? You don't just have a public link/repository in this day and age? Sigh. They did provide it within 24 hours, so yay for a vendor who actually responds to their support email address. 5b) Reboot 6) The default can utilities appear to be broken (or maybe I just don't understand them--wouldn't be the first time shrug). You need to compile up a new set of can-utils from here: https://gitorious.org/linux-can/can-utils Standard ./autogen.sh ./configure make dance applies as for anything afflicted with the autotools curse. 7) Connect can0 to can1--Connect Pin 8 to Pin 6 and Pin 7 to Pin 5. Pinout data in the TT3201 user manual does appear to be correct. I verified some stuff on my scope, but can2 exhibits different behavior from can0 and can1. Not surprising since the first two seem to come from the MCP2515 chips and the other is directly from the SoC. CAN0 - IC4 - Pin 7 and Pin 8 on connector CAN1 - IC5 - Pin 5 and Pin 6 on connector CAN2 - IC6 - Odd behavior that I still haven't worked out 8) Push the 3 switches on S1 away from the edge of the board This seems to connect the 120Ohm terminating resistors for the interfaces. 9) Configure can buses root@beaglebone:~# ip link set can0 type can bitrate 125000 root@beaglebone:~# ip link set can1 type can bitrate 125000 root@beaglebone:~# ip link set can0 up root@beaglebone:~# ip link set can1 up CAUTION: My scope shows the TX line as being 15.8us from rising edge-to-rising edge. That's exactly 1/2 of 125000 (as it should be since that's 2 *bits*), but it confused me until I thought about it for a bit. So if you are interfacing to a different CAN system, make sure that you agree on what bitrate actually means. 10) Run cansend and candump in two different windows/sessions/whatever root@beaglebone:~# cd linux-can-can-utils/ root@beaglebone:~/linux-can-can-utils# ./candump can1 can1 1F334455 [8] 11 22 33 44 55 66 77 88 root@beaglebone:~# cd linux-can-can-utils/ root@beaglebone:~/linux-can-can-utils# ./cansend can0 1F334455#1122334455667788 11) Resist urge to crumple up into a gibbering heap in the corner As always, your mileage may vary. Offer not valid anywhere. You're on your own--cope. Be careful out there. Go pound sand. Etc. Anybody want to tackle doing this in straight Debian (TowerTech sends you a repo link)? I'll buy you a beer. Maybe even two. Possibly a six pack. Please? Pretty please? Don't make me do this again ... breaks down crying -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] CAN-CAPE TT3201
I did check the transceiver. The RX toggles fine (I have a board that generates CAN transactions that is not a Beaglebone); the TX doesn't budge. So, the transceiver appeears to be working. Whether that means that the RX and TX on the SoC are connected correctly is a different question. The Linux configuration is certainly not automatic, but I followed the directions here and they seem to work: http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/ The problem is that lots of things are still linked to berlios.de for a subversion repository, and that's all gone with no pointer to where a new one would be. I'm looking primarily at the CAN interface that is directly connected to the DCAN1 interface on the ARM SoC. The *only* thing needed is for the CAN transceiver (a very simple chip) TX/RX to be connected to the correct lines on the ARM SoC. I'm trying to stay away from the CAN interfaces that require SPI communication to the CAN controller chips from Microchip as that's a whole 'nother ball of wax. I haven't physically traced the lines (yet) since I would have to create a Blinky LED switcher test since the pin is underneath the SoC, but it seems that people have managed to get this working in the past so I would be very surprised if those lines moved. Although, I should probably go check the schematics on the Beagleboard or previous Beaglebone to see if something actually did... Mr. Murphy is always hanging around ... I'm more concerned about the fact that the cansend, cancontrol, etc. commands in the tutorials simply don't reflect anything close to reality on the current versions as well as the references to berlios.de. Something major changed, but there is no trace of it. The fact that nobody has created new tutorials means that this stuff may be untested for quite a bit of time. I suspect if I could run *that* down, everything else would probably fall into place. On Sunday, February 15, 2015 at 9:51:14 PM UTC-6, lazarman wrote: I saw similar issues but didnt have a scope. Did you check the inputs to transciever with scope ??. I'd bet the IO is not configured properly for that cape -- *From:* Andrew P. Lentvorski bsd...@gmail.com javascript: *To:* beagl...@googlegroups.com javascript: *Sent:* Thursday, February 12, 2015 8:12 PM *Subject:* [beagleboard] CAN-CAPE TT3201 Beaglebone black newb here. I've been fighting with various problems with getting CAN to work and not really getting anywhere. Does anybody have a detailed set of instructions for the TT3201? I'm trying to use the onboard Beaglebone Black CAN which is routed directly to a transceiver to avoo In addition, it seems like can_utils, can-utils, ceiveror canutils have become a victim of bitrot and berlios.de going down. Almost all the tutorials have cansend can0 -i 0x11 0x22 when the cansend command I have supports cansend can0 FED#DEADBEEF. In addition, I don't even have a cancontrol command. Clearly, *something* has changed significantly. I've got my scope connected, and nothing external is toggling. Do I have to use Angstrom or Debian? Is there a particular image I need to load to make this work? Am I doing something completely stupid (almost certainly)? Any pointers would be useful. Thanks. -- 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[beagleboard] CAN-CAPE TT3201
Beaglebone black newb here. I've been fighting with various problems with getting CAN to work and not really getting anywhere. Does anybody have a detailed set of instructions for the TT3201? I'm trying to use the onboard Beaglebone Black CAN which is routed directly to a transceiver to avoid the extra problems with SPI. I expected this to be built into the distribution, but apparently it is not. In addition, it seems like can_utils, can-utils, or canutils have become a victim of bitrot and berlios.de going down. Almost all the tutorials have cansend can0 -i 0x11 0x22 when the cansend command I have supports cansend can0 FED#DEADBEEF. In addition, I don't even have a cancontrol command. Clearly, *something* has changed significantly. I've got my scope connected, and nothing external is toggling. Do I have to use Angstrom or Debian? Is there a particular image I need to load to make this work? Am I doing something completely stupid (almost certainly)? Any pointers would be useful. Thanks. -- 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. For more options, visit https://groups.google.com/d/optout.
