Packing a pointer (memory address) onto an IO pin
16 Feb 2015 20:48 #56006
by yeltrow
Packing a pointer (memory address) onto an IO pin was created by yeltrow
This may be the worst idea ever, but as I am trying to write things to tie neatly into my generic spi bus driver, I am struggling with pin overload. I have buffers that I am considering making an array of bytes (unsigned char) and passing the address of that buffer (a pointer) to an output (buffer_address). This pointer (buffer_address) would then be used by other fuctions to directly read and write to that buffer memory space. I have a pin called bufflock that signals that somewhere someone is trying to write to the buffer and that it is not safe to read or write the buffer. My user of the data will probably live in the servo thread and the spibus driver will live in the base thread. This would make connecting two functions that talk over these buffers as easy as adding one net. I would initialize the pin to 0 (a null pointer) and anyone that would use it would need to wait until the pointer was initialized before the fun could start.
QUESTIONS:
1) Can I assume that the addresses of per instance variables created with the "variable" declaration will have a constant address from call to call?
2) Will attempting to write to the variable from another function work? (I plan to try it anyway).
3) Are there other dangers I should consider?
4) In all of my code, I am assuming that it can be pre-empted before the function finishes. Is that true? Is it true of both base thread and servo thread functions/components?
QUESTIONS:
1) Can I assume that the addresses of per instance variables created with the "variable" declaration will have a constant address from call to call?
2) Will attempting to write to the variable from another function work? (I plan to try it anyway).
3) Are there other dangers I should consider?
4) In all of my code, I am assuming that it can be pre-empted before the function finishes. Is that true? Is it true of both base thread and servo thread functions/components?
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Offline
- Platinum Member
-
Less
More
- Posts: 4976
- Thank you received: 1373
16 Feb 2015 21:36 - 16 Feb 2015 21:37 #56009
by Todd Zuercher
Replied by Todd Zuercher on topic Packing a pointer (memory address) onto an IO pin
You might have better luck asking your questions on the developers email list.
lists.sourceforge.net/lists/listinfo/emc-developers
lists.sourceforge.net/lists/listinfo/emc-developers
Last edit: 16 Feb 2015 21:37 by Todd Zuercher.
Please Log in or Create an account to join the conversation.
16 Feb 2015 23:23 #56015
by andypugh
Have you seen the existing driver for absolute encoders? That re-uses code written to support the smart-serial devices. There is already code in there that can create HAL pins at run-time and populate them from run-time defined bit-streams.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...77808f436dd87ceb5d69
(I just noticed that the comment at the top refers to things that have already been done).
The way it works is that the HAL loadrt line specifies how the bit-stream should be parsed using a simple encoded string. I would suggest that a generic SPI driver could utilise the same code to parse the strings, create the HAL pins and set the values from the bit-stream, and set the SPI parameters using similar strings.
www.linuxcnc.org/docs/html/man/man9/hostmot2.9.html#Synchronous Serial Interface (SSI)
There is a driver for the Mesa bspi channels, but that was written before the smart-serial and abs-encoder stuff and it is absolutely not how I would do it if I was doing it now.
Replied by andypugh on topic Packing a pointer (memory address) onto an IO pin
This may be the worst idea ever, but as I am trying to write things to tie neatly into my generic spi bus driver,
Have you seen the existing driver for absolute encoders? That re-uses code written to support the smart-serial devices. There is already code in there that can create HAL pins at run-time and populate them from run-time defined bit-streams.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...77808f436dd87ceb5d69
(I just noticed that the comment at the top refers to things that have already been done).
The way it works is that the HAL loadrt line specifies how the bit-stream should be parsed using a simple encoded string. I would suggest that a generic SPI driver could utilise the same code to parse the strings, create the HAL pins and set the values from the bit-stream, and set the SPI parameters using similar strings.
www.linuxcnc.org/docs/html/man/man9/hostmot2.9.html#Synchronous Serial Interface (SSI)
There is a driver for the Mesa bspi channels, but that was written before the smart-serial and abs-encoder stuff and it is absolutely not how I would do it if I was doing it now.
The following user(s) said Thank You: yeltrow
Please Log in or Create an account to join the conversation.
17 Feb 2015 01:19 #56017
by yeltrow
Replied by yeltrow on topic Packing a pointer (memory address) onto an IO pin
Thank you for the links -- I have noticed they are all .c files and not using the component generator. I have been trying to use the component generator to try and take advantage of its abstraction from the intimate details of HAL RTAPI calls, etc.
** Should I abandon the .comp approach? ***
I have written a few programs and attached them. The first is an UNFINISHED spibus.comp. It does work (at least to send -- I have not tested receiving yet.) I lock the buffer, put some stuff in it, change the buffer pointer (count really) to the number of elements that should go out the port, and then chug-chug-chug they wiggle the pins. The other two files illustrate how I attempted to share a buffer. I'm kind of glad it didn't work, because the idea of ANYBODY'S crazy program being able to change variables belong to someone else is a recipe for severed limbs when working with machine tools.
zool.comp creates the buffer and twiddles some bits in it.
the keymaster.comp connects to zool and tries to read and modify the contents of the buffer, with kernel corrupting goodness.
** Should I abandon the .comp approach? ***
I have written a few programs and attached them. The first is an UNFINISHED spibus.comp. It does work (at least to send -- I have not tested receiving yet.) I lock the buffer, put some stuff in it, change the buffer pointer (count really) to the number of elements that should go out the port, and then chug-chug-chug they wiggle the pins. The other two files illustrate how I attempted to share a buffer. I'm kind of glad it didn't work, because the idea of ANYBODY'S crazy program being able to change variables belong to someone else is a recipe for severed limbs when working with machine tools.
zool.comp creates the buffer and twiddles some bits in it.
the keymaster.comp connects to zool and tries to read and modify the contents of the buffer, with kernel corrupting goodness.
Please Log in or Create an account to join the conversation.
17 Feb 2015 01:56 #56021
by andypugh
I think so.
You can compile the comp to a .c as a starting point, that would not mean wasting all your coding so far.
Well, actually, in the HAL shared memory block any component can wiggle random pins. You just have to be sure that they do it properly.
Hopefully there are no "rogue" components in the distributed versions at least.
Ah, yes. You will find it expedient to debug components at the Halcmd prompt rather than in a full LinuxCNC session. HAL can easily get messed up in ways that require a restart.
Replied by andypugh on topic Packing a pointer (memory address) onto an IO pin
Should I abandon the .comp approach?
I think so.
You can compile the comp to a .c as a starting point, that would not mean wasting all your coding so far.
the the idea of ANYBODY'S crazy program being able to change variables belong to someone else is a recipe for severed limbs when working with machine tools.
Well, actually, in the HAL shared memory block any component can wiggle random pins. You just have to be sure that they do it properly.
Hopefully there are no "rogue" components in the distributed versions at least.
with kernel corrupting goodness.
Ah, yes. You will find it expedient to debug components at the Halcmd prompt rather than in a full LinuxCNC session. HAL can easily get messed up in ways that require a restart.
Please Log in or Create an account to join the conversation.
01 Mar 2015 03:33 - 01 Mar 2015 03:35 #56362
by yeltrow
Replied by yeltrow on topic Packing a pointer (memory address) onto an IO pin
Andy -- I have been successful at writing to memory space allocated by one component by passing a pointer to that memory through a pin and casting that back to a pointer. I am both happy and terrified that it has worked. I think this will allow me to:
1) Create any kind of buffer structure/data type I choose
2) Tie components that use this space together by publishing the pointer to shared space via a pin
3) Keep the net list tidy and limited to just a few pointers instead of passing every byte of every buffer as a separate pin (image 32 input bytes, 32 output, 32 slave addresses, 32 slave select pin config flags).
4) Open the door to whole new level of bugs and pain.
To see the insanity in action, watch debug on halmalloctest.0.debug. It is being changed in halpoker.comp.
I have been able to operate within the ecosystem of the component generator thus far; although I may not be far from abandoning it. The passing of memory addresses via pins changes everything.
Please see attached some code that works to have one program twiddle the bits in another private variable space.
I think this is the part where the dev's step in and delete this post so noone uses my template for insanity for future development.
1) Create any kind of buffer structure/data type I choose
2) Tie components that use this space together by publishing the pointer to shared space via a pin
3) Keep the net list tidy and limited to just a few pointers instead of passing every byte of every buffer as a separate pin (image 32 input bytes, 32 output, 32 slave addresses, 32 slave select pin config flags).
4) Open the door to whole new level of bugs and pain.
To see the insanity in action, watch debug on halmalloctest.0.debug. It is being changed in halpoker.comp.
I have been able to operate within the ecosystem of the component generator thus far; although I may not be far from abandoning it. The passing of memory addresses via pins changes everything.
Please see attached some code that works to have one program twiddle the bits in another private variable space.
I think this is the part where the dev's step in and delete this post so noone uses my template for insanity for future development.
![:) :)](/media/kunena/emoticons/smile.png)
Last edit: 01 Mar 2015 03:35 by yeltrow. Reason: Fogot a file.
Please Log in or Create an account to join the conversation.
03 Mar 2015 06:07 #56415
by yeltrow
Replied by yeltrow on topic Packing a pointer (memory address) onto an IO pin
I got tired of the huge list of nets between my spibus driver and my spiclient. Spiclient is a driver template for writing individual chip spi drivers. For example, one could have an analog to digital converter chip, an IO expander, and a SPI LCD all hanging on the spi bus. In the future, each of these will talk to my spibus driver and the driver will hadle generating the clocks and jiggling the chip select lines. Each of the chip drivers is oblivious to the presence of the others using the same spi bus.
SPIBUS.COMP:
- Allocates the buffers and initializes them.
- publishes a pointer to them
- manages the information it gets from the buffers
SPIBUSCLIENT.COMP:
- Checks to see when the spibus has come up
- Receives the pointers to the buffers and checks to see that they are not null
- Generates the byte commands needed to run a chip
- Writes these directly into the hal memory allocated by the spibus.comp driver and pointed to by the pointers it has been given.
THINGS THAT WILL CAUSE A KERNEL PANIC:
Passing some other goofy numbers in on the address_byte_low and address_byte_high pins.
Next to do:
- Find a "not crazy" way to pass the allocated memory handles to the spiclients (EXPORT KERNEL SYMBOLS?)
- Modify the proof of principle code to handle more than one client chip
- Modify the MAX7219DS LED driver I wrote to work with the new buffer architecture.
- Maybe test running parport.update method directly from within my driver to increase the bitrates?
SPIBUS.COMP:
- Allocates the buffers and initializes them.
- publishes a pointer to them
- manages the information it gets from the buffers
SPIBUSCLIENT.COMP:
- Checks to see when the spibus has come up
- Receives the pointers to the buffers and checks to see that they are not null
- Generates the byte commands needed to run a chip
- Writes these directly into the hal memory allocated by the spibus.comp driver and pointed to by the pointers it has been given.
THINGS THAT WILL CAUSE A KERNEL PANIC:
Passing some other goofy numbers in on the address_byte_low and address_byte_high pins.
Next to do:
- Find a "not crazy" way to pass the allocated memory handles to the spiclients (EXPORT KERNEL SYMBOLS?)
- Modify the proof of principle code to handle more than one client chip
- Modify the MAX7219DS LED driver I wrote to work with the new buffer architecture.
- Maybe test running parport.update method directly from within my driver to increase the bitrates?
Please Log in or Create an account to join the conversation.
Time to create page: 0.135 seconds