<mattb0ne>
the counter increments but I am not seeing pulses on my multimeter
<mattb0ne>
so that is independent of the motor and purely on the coding. I suspect since that position does increment so the memory is mapping correctly even though I am not using the near
<mattb0ne>
(cregister "LOCAL",near)*
<mattb0ne>
so that raises the question of why the toggling of the bits of __R30 is failing to cause the pin state the change
<mattb0ne>
to*
<mattb0ne>
I slowed down the PRU to 1 second pulse so its not going to fast that I miss it
<mattb0ne>
could it be the way __R30 is defined
<mattb0ne>
it is not mapped to anything from what I gather based on my naive understanding of how registers work
<mattb0ne>
that would explain the behavior
<mattb0ne>
going afk for research
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
mattb0ne has quit [Ping timeout: 240 seconds]
buckket has quit [Quit: buckket]
buckket has joined #beagle
vagrantc has quit [Ping timeout: 265 seconds]
<zmatt>
hmm, your pinmux seems right for the R30 bits you're using, and you're using the right core... not sure why you wouldn't see any output
<zmatt>
some minor things (this is not going to solve your problems but just some improvements): the halt_request flag in shmem should obviously be set to False _before_ starting the core, otherwise it would immediately halt again
<zmatt>
and you shouldn't halt the core using core_0.halt(), halt it by setting shmem.halt_requested to True and waiting for the core to halt on its own... the point of that is to make sure you don't halt it right in the middle of a pulse
<zmatt>
but maybe start by changing core_0.r30 directly from python (while the core is halted) to confirm the output on the beaglebone is toggling
<zmatt>
the sleep after core_0.halt() is also pointless since calling .halt() will instantly halt the PRU core in the middle of whatever it's doing
<zmatt>
on the other halt, when using shmem.halt_requested to halt the core you obviously do need to give it a moment
<zmatt>
but, you're saying you're using a multimeter to check the output... how are you doing that exactly? you've changed the PRU program to generate 1000us (i.e. 1ms) pulses instead of 1us pulses, but you're still not going to see a 1ms pulse using a multimeter :P
<zmatt>
my guess would be the program is working just fine
<zmatt>
it definitely *should* be working fine based on what you've pastedbinned
<zmatt>
note that putting SharedVars in the SHARED memory region (0x10000-0x12fff) is a bad idea of course since that's where your main program puts its shared variables, but for a standalone test like this it shouldn't cause any problems
<zmatt>
you probably changed it in an attempt to debug the "problem", but I think you were on a wild goose chase and in fact the program was generating pulses just fine. if the stepper driver wasn't reacting to it then my suspicion would be that the problem lies with the electrical interfacing between the beaglebone and the stepper driver
<zmatt>
(hopefully you'll read this in irclog before you waste too much time on it)
Shadyman has joined #beagle
vagrantc has joined #beagle
<set_>
!
vagrantc has quit [Quit: leaving]
buzzmarshall has quit [Quit: Konversation terminated!]
SJFriedl has joined #beagle
vagrantc has joined #beagle
Shadyman has quit [Quit: Leaving.]
vagrantc has quit [Quit: leaving]
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
buzzmarshall has joined #beagle
011AAEBMJ has quit [Remote host closed the connection]
jfsimon1981_b has quit [Remote host closed the connection]
mattb0ne has joined #beagle
<mattb0ne>
back
<mattb0ne>
read the logs
<mattb0ne>
lets get to it!
<mattb0ne>
doh on the us delay length going to increase to a 1 second
<mattb0ne>
lol
vagrantc has joined #beagle
<mattb0ne>
Does the core continue to run if never halted even after the python program end?
<mattb0ne>
I tried adding the line core_0.r30 |= (1<<0) at the end but still nothing
<mattb0ne>
take that back
<mattb0ne>
I thought I had something but no
<mattb0ne>
maybe the way I toggle is incorrect
<mattb0ne>
one question I have is how code declaring __R30 map to the right address without any aditional information
<set_>
I have complications w/ specific ways while handling source w/ offsets and bytes, bits, etc.
<set_>
But, everyone already knows it and that I fail at life.
<set_>
Anyway, off and up to the play at hand. BBAI-64 and some MESA card I found! CNC!
<set_>
Things get more complicated and almost make me who I am. But there is one missing component. Books and literature. Tuts...yea. But, the books and literature are where it is at currently for me.