Hi Marco, > On 30 Jan 2018, at 18:57, Marco Negrini <[email protected]> wrote: > > Hi everybody, > > I have an idea for a project, but I would really like to know what all of you > think about it. > > I am going to develop a project involving RasperryPi with Machinekit and and > a MCU from Microhip (atsame54 in particular). > > The main part of the project is implementing the Hardware Abstraction Layer > on the MCU, and making it communicate with the RPi via SPI (or any other > protocol, for what is worth) > The idea is copying the Sitara (ARM processor with PRU embedded) with RPi and > MCU. > The Machinekit in the Rpi should see the HAL modules in the MCU and manage > signals througth them, just like native modules. > > The MCU should have some predefined HAL module i.e. a PWM module allocable > for certain PINs that takes PWM value from other module i.e a PID. > Examples for MCU modules are PWM, frequency meter, a simple contact, a motor > stepgen, a timer, logic (and, or, xor..), a coutner, a limiter... I think you > got the idea. > HAL signals should be able to go from and to any device (RPi-RPi / MCU-RPi / > RPi-MCU / MCU-MCU) > I think I can make it by implementing an HAL module for the RPi that > communicates via SPI with the MCU, where the firmware receives the HAL > configuration (modules to load and connection between them). > > The reason behind all that is making a PLC where Rpi and MCU cooperate to > manage complex interfaces (video, ethernet, usb) and the machine (fast PWM, > analogic signal, and a big number of PIN), and it would solve a problem of > the comunication between the two. > I.e a thing like OpenPLC uses just readPin(pin) writePin(Pin, value) to > manage the communication, so the MCU is simply a pin expansion, I think it > can do more. > One thing that I consider important is that the MCU could (given the right > implementation...) be stand alone, so RPi could be rebooted or removed where > not necessary (cheaper PLC where no video is requested) > > What do you think about all that? Does it make sense?
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? 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? > Is there anything that I can / should use to avoid reinvent the wheel or to > stick to an API? > I am referring to protobuf, or any piece of Machinetalk. Anything that I > should look before starting? > > Obviously all of this would work with BB instead of RPi, but there is no > reason for having both MCU and PRU. > > Any question is welcome! This could be my graduating project, I will talk > about it with the prof. in these days. > > -- > website: http://www.machinekit.io <http://www.machinekit.io/> blog: > http://blog.machinekit.io <http://blog.machinekit.io/> github: > https://github.com/machinekit <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] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/machinekit > <https://groups.google.com/group/machinekit>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
