If you want others to use this, and if you want any help at all, please don't tie the code to the ATSAME54. Can you develop it for a generic ARM Cortex-M4.
I'm doing about what you describe for robot motion control. I use R Pi3 with serial data to ARM M4. There are few different kinds of messages that can come over the serial link (which can be SPI) The ARM M4 then does whatever the command says. Some of these command start a process that simply streams back data from an axis encoder or battery voltage. Oner thing I hope you do is use a "free and open source development environment. (gcc works.) I found that i needed an RTOS and use one that is free and runs on a variety of AMR M chips. Now my code is portable to any ARM M. This is important because no chip lives forever. CMSIS-RTOS is a common API for Real-Time operating systems. It provides a standardized programming interface that is portable to many RTOS and enables therefore software templates, middleware, libraries, and other components that can work across supported the RTOS systems. I'm using "mbed" which is a CMSIS based RTOS. This makes the project fairly easy. For example I can have a thread (process) that monitors the serial link and some other threads that runs PID loops or do some kind of sensor monitoring. mbed is build on top of CMSIS and adds some nice to have features. Or you can use CMSIS directly. Either of these only adds about 5K to the size of the image. mbed/CMSIS also provide a standard way to access the on-chip peripherals. So I don't have to connect pins the peripheral units and deal with the difference between different ARM chips. Also mbed is about as easy to use as Arduino. There are a few IDEs that can be used, one is browser based or I can use Eclipse or the command line. It is so much easier to just use "Timer-01" then to stuff hardware registers with bits, where those registers are different on every ARM chip. I think if you use some kind of real-time OS in the ARM and access the hardware via that OS you will not be tied to the specific chip and the RTOS provides services like real time multitasking, locks and queues and so on. If you have not used an OS like this, it is NOT AT ALL line linux. The OS is just a library that gets linked in with your own code. You code and the OS become a single .BIN file that is loaded into FLASH. The ARM M chip is powerful enough to run any machine tool all by itself. I use several of them simply because it is easy to run out of pins and if you buy the ARM M0 boards at the right place they are only about $3 each. No There is a problem with this entire approach. Not a problem if you design it right. You must keep the commands on the serial link at a "High Level". They have to be things like "Run motor #5 at X steps per send" and not a command for each step. In my robot system all the commands I send are even higher level. They are basically the equivalent of g-code because they specify a rate of position of an axis using real word coordinates and SI units, I I might say "move Y at 0.5 meters per second" and that gets executed on the ARM M chip. Much of the safety and house keeping is done on the micro controller, tings like stopping a motor of there is Hanover current or oner temperature problem or id the battery is below a threshold voltage. In your case, Linux EMCMK would still run a HAL file but many of the funtions would just send a command down the serial interface On Tue, Jan 30, 2018 at 9:57 AM, 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? > 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 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. -- Chris Albertson Redondo Beach, California -- 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.
