<set_>
Oh. PRU has nothing to do w/ cortex-m. Okay.
<zmatt>
are you talking about cortex-m microcontrollers? they're generally around the 100 MHz
<set_>
Hmm. I was looking at the 32-bit MSP430 from ti.com.
<set_>
100MHz is not bad actually. Let me revisit their site. Sorry for the lack of info. I was providing.
<zmatt>
that's a contradiction, the MSP430 is a tiny 16-bit microcontroller
<set_>
Oh.
<set_>
Hmm. Okay.
<zmatt>
(and not cortex-m)
<set_>
Aw.
<set_>
Okay. I clicked the 32-bit MSP430 controllers on their site.
<set_>
And...it popped up w/ a slew of ideas.
<set_>
Okay.
<set_>
LX... and LM... chips are available on their site.
<set_>
Sorry.
<set_>
Those are the Cortex-M processors on their site. I could have sworn GenTooMan just said what he said. Forget it. MSP432 is the 32-bit chips and not the MSP430.
<set_>
Blah.
<zmatt>
MSP430 is 16-bit, MSP432 is cortex-m4f ... I don't know why they chose this bizarrely confusing part numbering, especially since they have a bunch of other cortex-m4 families already
<set_>
Right. Okay.
<set_>
Anyway, my ideas were to sport one on the Cape one day.
<zmatt>
for what purpose?
<set_>
For fun, selling, and learning.
<set_>
I get bored mowing still, i.e. as you are aware of still. Yes, the boss says, "Mow set_, Mow!"
mattb0ne has quit [Ping timeout: 240 seconds]
<set_>
The current Cape I am trying to produce has a TI.com open schematic, open Gerber, and some 30 page instruction on ideas.
<set_>
I figured it could benefit me in learning more.
<set_>
And if, one day, I can get it (them) to work, I can try to sell one and make them more open to the public.
<set_>
So others then can make 'em!
<set_>
So, instead of just breadboards, they can get access to info. they may not be aware of currently. Specific retail operations/mfg./assembly ideas and so on...
<set_>
@zmatt: The TIDA-00320 is the Cape in question for now.
<zmatt>
oh wtf MSP432E is rebranded TM4C129
<zmatt>
I mean, they rebranded the TM4C129 to MSP432E
<set_>
Oh.
<zmatt>
set_: what would you need this for?
<zmatt>
the cape I mean
<set_>
For learning...I can use it for learning purposes, motor movement, dealing w/ specific businesses that produce, and understanding the process of work.
<set_>
Right. I understand.
<zmatt>
8 heavy duty digital outputs with a 500V isolation barrier... sounds like something for industrial process control or something
<set_>
Well, they have it branded as a PLC controller.
<zmatt>
it's not any sort of controller, it's just 8 digital outputs
<zmatt>
yeah it's fairly explicit... it's an 8-channel digital output module
<zmatt>
(the block diagram shows this quite clearly too)
<set_>
Right.
<set_>
yes.
<set_>
output module.
<set_>
But...I did read somewhere in my research where this specific module can be a stand alone application. They could be wrong or I could have read it wrong but I am sure I read it.
<set_>
I will research the idea again.
<zmatt>
you probably misunderstood something
<zmatt>
anyway, afk
<set_>
W/ GPIO
<set_>
I found it!
<set_>
Please hold.
<set_>
5: Getting Started Hardware
<set_>
In that pamphlet book they produced on this product, number 5 states what I read.
<zmatt>
they're saying you can either plug it into a BBB or connect it to some other microcontroller
<zmatt>
now actually afk
<set_>
Ha.
<set_>
Okay.
<set_>
Got it.
<set_>
But...I still need to program the EEPROM on it. I may need help.
<set_>
For instance, to differentiate the Cape0 or Cape1.
<set_>
and then mattb0ne can program the PRUs to handle it!
<set_>
super fast access to I/O!
<set_>
echo!
<set_>
So GenTooMan, how would I handle writing the EEPROM info. to the chip on the Cape?
<set_>
Does that need to be done first, i.e. before mfg?
<set_>
Wow. I can do a write up of the i2c programmin' of the EEPROM chip on the Cape!
<set_>
pyserial?
<set_>
nope.
<set_>
Dang it.
<set_>
That is interesting. So, each chip must be programmed to handle the specified info. for Cape production. EEPROM! smbus!
<set_>
So, here comes the issue. The EEPROM will already be attached. Dang. So, hopefully, powering the EEPROM will not destroy other components when I i2c the ba-gee-bus out of it to program it.
<zmatt>
program the eeprom??
<zmatt>
oh it's not a ready-made cape
<zmatt>
given that it's purely gpio-controlled you could also just not bother programming it
<set_>
Oh.
<set_>
Okay.
<set_>
I just figured I would do things correctly. The EEPROM is coming w/ the mfg. Cape.
<set_>
eight pin!
<set_>
atmel AT24C02D-SSHM-T
<set_>
I am slowly starting to learn how to program this little things.
<set_>
$0.20 in cost but backordered. Blah.
<set_>
Dang man. They bought everything.
<zmatt>
there's not really any benefit for putting an eeprom on this thing
<set_>
Oh.
<zmatt>
the eeprom is normally for cape autodetection, but in this case there isn't really much you could do with it
<set_>
Okay.
<set_>
GenTooMan: Did you ever listen to that song I posted? It is an instant classic.
<mattb0ne>
I made some code that works fine with 4 variables but breaks with 5
<mattb0ne>
specifically adding that speed variable with uint16 throws off my force measurments defined layer. I see just garbage after adding the variable
CrazyEddy has quit [Ping timeout: 268 seconds]
CrazyEddy has joined #beagle
CrazyEddy has quit [Ping timeout: 246 seconds]
Shadyman has quit [Quit: Leaving.]
javaJake has quit [Remote host closed the connection]
javaJake has joined #beagle
CrazyEddy has joined #beagle
<mattb0ne>
zmatt: also the uio mapping is 2 way correct? so I could save something from python and read it in the PRU as long as the memory location align
xet7 has joined #beagle
troth has quit [Ping timeout: 250 seconds]
troth has joined #beagle
m-atoms has joined #beagle
<zmatt>
mattb0ne: I've explained this before but the problem is alignment. you've put 4-byte variables at offsets which are not multiples of 4, due to putting the 2-byte "speed" variable at the front
<mattb0ne>
ok i think i recall that convo
<zmatt>
also, why are you putting these directly in SharedVars instead of using messages? keep in mind that you cannot read multiple pru vars at the same time atomically
<mattb0ne>
I just read once
<mattb0ne>
so did not want to bother setting up a buffer and stuff
<zmatt>
after pru has halted/
<zmatt>
?
<mattb0ne>
i just want to pass a value in and get value back
<mattb0ne>
no before I read then halt
<zmatt>
? how does pru know to stop updating the vars? how does python know pru has stopped updating it?
<mattb0ne>
on the variable alignment thing is that a universal concept or unique to the BBB
<mattb0ne>
yeah i sleep in python then read the value and stop the PRU
<mattb0ne>
seems like a big limitation if I only need 2 bytes of space but I need to use 4bytes
<zmatt>
just put the speed variable at the end
<zmatt>
sort the variables by size
<mattb0ne>
is that what people do in practice just put the odd ball variable at the end to avoid the issue
<mattb0ne>
also since I have you
<zmatt>
alignment is a fairly universal concept, typically if you make a struct all variables neeed to satisfy a certain alignment, though the exact requirements are architecture-dependent. unusually however the PRU C compiler does not impose any alignment requirements, which is why you need to pay manual attention to it
<mattb0ne>
i see
<mattb0ne>
since I have you dram1 vs dram2 in the uio
<mattb0ne>
dram0 is the private memory of PRU0
<mattb0ne>
correct? with dram1 being private memory of PRU1
<zmatt>
if you declare this struct as-is in python (or C on ARM) then two bytes of alignment padding will be inserted between 'speed' and 'max_position' to align the latter
<mattb0ne>
that padding needs to be declared by the user
<mattb0ne>
?
<mattb0ne>
i can do that
<mattb0ne>
now that I know
<zmatt>
it normally happens automatically. however clpru does _not_ insert padding, which is why you're getting problems
<mattb0ne>
makes sense
<zmatt>
there are ways to force a struct to have non-aligned fields, however in this case that wouldn't work since 1. the PRU subsystem is mapped as "device memory" by uio, which does not support misaligned access (you'd crash with a bus error) 2. misaligned memory accesses tend to get broken up into multiple separate accesses behind the scenes, which destroys the atomicity of even accessing a single ...
<zmatt>
...variable, which is undesirable for variables shared between multiple cores
<zmatt>
dram0 and dram1 are designated to be the "private" ram for pru core0 and core1 respectively, and dram2 is designated for shared use, though both pru cores and the ARM core can access all three memories if needed
<mattb0ne>
ok that is what I needed to know
<mattb0ne>
i got confused because on the PRU side their local address is 0x00000 for local for both PRU0 and PRU1
<mattb0ne>
was confused on the addressing
<zmatt>
yes, dram1 is at offset 0 for pru1
<zmatt>
dram0 and dram1 are swapped for pru1
<mattb0ne>
that makes sense
xet7 has quit [Ping timeout: 264 seconds]
<zmatt>
it's still not entirely clear to me what you're doing with SharedVars here... this is just for a little test or something?
<mattb0ne>
my last questions is when you gonna redo this for hte bbai lol
<zmatt>
py-uio already works on the bbx15/bbai
<mattb0ne>
yeah doing some mini programs
<mattb0ne>
i thought you were waiting on something with the GPIOs or soemthing
<zmatt>
??
<mattb0ne>
mapping pins or something like that was not ready
<mattb0ne>
forget it
nslu2-log has quit [Ping timeout: 240 seconds]
<mattb0ne>
probably jumbled convo in my head when I was lurking. I think last time i was chatting there was bottleneck making the bbai jarder to work with
<mattb0ne>
maybe it was the overlays
<zmatt>
pin mapping originally sucks on bbx15/bbai, and still does on the latest official image, though config-pin has been implemented since then and is presumably on the latest testing images
<mattb0ne>
were not simple on the bbai
<zmatt>
none of that has anything to do with py-uio
<mattb0ne>
oh
<mattb0ne>
py-uio just makes the addresses and registers human readable?
<mattb0ne>
and provides hooks to python
<zmatt>
btw if you just want PRU to do a measurement for a bit and then halt and read the results I'd suggest putting a bool in SharedVars to request pru to halt, and then PRU test that bool to exit its main loop and __halt();
<mattb0ne>
good idea
<mattb0ne>
i am going to do that
<mattb0ne>
how many bytes are boolean
<zmatt>
1
<mattb0ne>
cool
<mattb0ne>
let me mess around with this
<zmatt>
that way PRU can also do any cleanup needed before halting
<zmatt>
and you can be sure you're not reading vars while PRU is in the middle of updating them
<mattb0ne>
right
<mattb0ne>
brb
<zmatt>
and what uio enables is 1. mapping subsystems/peripherals into userspace for direct access of peripheral registers and subsystem-local memory 2. receiving interrupts in userspace
<zmatt>
it has nothing to do with pinmux
<zmatt>
pinmux needs to be setup in DT or using config-pin (or its python equivalent, https://pastebin.com/MKtWJ8G8 )
xet7 has joined #beagle
xet7 has quit [Client Quit]
troth has quit [Ping timeout: 264 seconds]
mattb0ne has quit [Ping timeout: 256 seconds]
florian has quit [Quit: Ex-Chat]
set_ has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
troth has joined #beagle
troth has quit [Ping timeout: 240 seconds]
troth has joined #beagle
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
set_ has joined #beagle
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
vd has quit [Quit: Client closed]
vd has joined #beagle
xet7 has joined #beagle
<mattb0ne>
how do I put in the offset to put a structure in dram1
<zmatt>
why would you want to?
<mattb0ne>
because I have stuff in shared
<mattb0ne>
or is it bad form to have the OS touch private memory
<mattb0ne>
i figured since I read from PRU0 all the time to get the encoder output
<mattb0ne>
not a big deal to put something in dram1
<zmatt>
you keep referring to "the OS" ... the OS isn't touching anything
<zmatt>
pru memory is exclusively being accessed by your own code, either python code or pru code
<mattb0ne>
python
<mattb0ne>
kernel space a better term?
<zmatt>
none of the pru memories are ever accessed by the kernel when using uio
<mattb0ne>
user space
<zmatt>
and yes you can probably force allocation of a variable at a specific offset in dram1 (for C code running on pru1), though I'm a bit confused why you need to... generally I leave dram1 fully to the compiler for storing its own stuff while using dram2 for manually allocated shared variables
<zmatt>
if you're using part of dram2 for other stuff, just put it somewhere else in dram2 (similar to how DDRLayout and SharedVars were allocated at different offsets in dram2)
<mattb0ne>
ok
<zmatt>
either way, allocating a var at a fixed offset in the core's private dram probably works the same as for dram2, except for removing the "far" keyword and using a suitable address in range 0x0000 to 0x2000-sizeof(var)... but some addresses might result in linker trouble, it would require experimentation.... or just avoid the entire headache and use dram2
Shadyman has joined #beagle
<mattb0ne>
one other thing the addres for EPWM1B
<mattb0ne>
i do not think it is right I cannot get the motor to go in the other direction
<mattb0ne>
pastebin
<zmatt>
? what does motor direction have to do with the pwm? I'm assuming motor direction is controlled via a gpio or something?
<zmatt>
depending on how the motor driver works
<zmatt>
or does it use two separate pwm outputs?
<mattb0ne>
the two PWM outputs
<mattb0ne>
so sending a value to EPWM1A works
<mattb0ne>
if I send a value to EPWM1B it does not
<zmatt>
can you link to the pastebin I made with the addresses?
<zmatt>
does it work when manually controlled from python?
<mattb0ne>
yes
<mattb0ne>
scratch that
<mattb0ne>
let me reconfirm now
<mattb0ne>
it did
m-atoms has quit [*.net *.split]
russ has quit [*.net *.split]
outrageous_ has quit [*.net *.split]
m-atoms has joined #beagle
<mattb0ne>
i am just going to shut up for the day
<mattb0ne>
it is fine
<set_>
Yes!
<set_>
You guys are always into them PRUs!
<set_>
I want to learn more about them too.
russ has joined #beagle
<set_>
I am waiting on a quote now for my, TI.com's, Cape-zilla!
<set_>
What should I call it? Digital Output * 4?
<set_>
Or just plain, controller?
<set_>
I am learning now how to create the .cmd file, along w/ the .c file, and .asm file(s).
<set_>
I think the .cmd file is the most difficult for me, i.e. as I know very little on how to attain the address values.
<set_>
Does prudebug handle such address values for getting them printed to output?
<set_>
Hey? The PRU software package is no longer maintained. Hmm.
<set_>
at least, not from TI.com outside of their PSDK.
<mattb0ne>
link for the capezilla
<mattb0ne>
zmatt:how would you handle this situation.... So the encoder if I go in the reverse direction and the reading starts at 4,294,967,295 and counts down
<zmatt>
the position will wrap mod 2**32 yes (in either direction)
<mattb0ne>
I turn this into an angle and so I take the modulo of my pulse per rev and use that value to get a value between 0-360
<mattb0ne>
my issue is that the max value starts me at 61 degrees instead of 0 just by nature of that max value
<mattb0ne>
I am not sure how to handle going in either direction and getting the correct angle value
<zmatt>
how many pulses per rev is it?
<zmatt>
mattb0ne?
<zmatt>
if the PPR is a power of two then you can directly reduce the position mod 4*PPR and if desired convert that to degrees, otherwise you need to track relative changes of the position value and convert those
<mattb0ne>
1440
<mattb0ne>
argggg
<mattb0ne>
ok
<zmatt>
but how would an absolute angle be more useful if it's not calibrated? aren't you going to need to work with relative changes anyway?