> my 2 cents:
>
> I think that MK HAL on “dedicated platform x” has less value.
> The power of the HAL is like the name, the Hardware Abstraction Layer. And
> what you’re proposing is to add HAL on a specific hardware, and thus
> removing the “A” in HAL.
>
> What makes more sense is a HAL driver with defined communication between
> “hardware x” and the host. Then the messaging part of "hardware x” could be
> implemented on the hardware specific stuff.
> In essence the PRU’s on a sitara chip take care of hard realtime stuff
> (PWM, step generating, encoder), and communicate in a latency low way with
> the realtime thread on the main processor. So I’m not clear on the benefits
> of using a Rpi with additional hardware. Seems like a lot of work for
> something that’s already there.
>
> What problem are you exactly trying to solve?
>
Sitara alone cannot support both LCD and the amount of contact I need, I
may solve this adding external components, or remoting the LCD. But having
a BB is already
So I am considering using a dedicated controller, that can be as generic as
possible, I will start with a particular Cortex M4, but porting to other M4
or other architectures should be as easy as possible.
At this point, I need to manage the communication between RPi and that
microcontroller.
Like Chris said "You must keep the commands on the serial link at a "High
Level" ":
I want to emulate the way Sitara works with his PRU, they have shared
memory and HAL signals.
Having an external controller I will have message passing and HAL signals.
Doing so the controller should be able to understand that signals, why not
put an HAL module on it like has been done with the PRU? (I am thinking
about hpg)
I will program an HAL module for the RPi that talks with the one on the
controller (SPI, maybe?) and
1) shows the state of that module to the others
2) notify that module when a value change (i.e. if the value of
commanded_position change a message will be sent with the new value)
"remote" component will look just like all the others.
And going on: why only one module on the controller?
The firmware on it could have some modules predefined, that could be
allocated and allocated just like the modules in the actual Machinekit.
The modules may be hardware specific, some of them will eventually have to
write on registers that may change from hardware to hardware.
This leads to having a part of the firmware that manage the connection and
the modules, this part shouldn't be hardware specific, as it has to talk
with the modules and with the module on the RPi.
I think it will be easy to port to other controllers or other architectures
(At least, I think)
Those "remote" components may be connected between them, there is no need
to notify the RPi for every single change.
Now, how should the RPi see these multiple "remote" components?
Maybe for each remote component allocated by the controller the RPi
allocates a virtual one,
and all of those virtual components send and receive notification to the
real ones when the state change (i.e. a contact on the controller is closed
or the commanded_position )
Maybe I will still need a unique process that manage the connection, I
think it will make things easier.
(So... the microcontroller can even be stand alone, after the first
configuration of the HAL signals?)
After all of that, I will have reimplemented HAL on a microcontroller, and
it can be used along with Machinekit's HAL.
Having to produce a PLC this gives me modularity (if I just need a screen I
can just use a RPi zero W)
I will not be bound to Sitara with BB (that is not very cheap, considering
that I will have to add a cape)
Firmare on the microcontroller needs minimum changes, as I can program it
using the HAL modules and signals.
I see a lot of other considerations too. Is this a one-off project “because
> it can be done”? Have you considered what happens if people are going to
> ask for support? Can you support that? Do you expect other people to join
> in?
> You talk about making a PLC out of the Rpi and MCU. Are you going to make
> a product out of this?
>
A product will come out, and I will use it to manage a glue-melting-machine.
For this product I need screen support, connectivity like bluetooth (wifi
is also nice), ethernet will be optional, and lot of contacts.
The product must be modular, a very cheap version that can handle few
common problems with some digital I/O,an SD, and little more (where not all
the contact are used), expandible with RPi, and on the free contact
expansion can be connected:
i.e. If I need more relais at 24volt, or input, or a bunch of led, or
output with a capacitor, I just have do design the expansion.
Talking about support, I plan on using that PLC daily, and is very likely i
will support and improve this in next years, but my plans about future are
not that clear...
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
