> > > > I am thinking about split in two with real time threads on micro > > > > controller and the computer for the user interface. It would also be a > > > > flexible solution then it come to choice of user interface but require > > > > extra hardware. > > > > > > > > > > If I were designing this in the current century (the 21st) I'd divide the > > > functions roughly in to three (not two) and place them as follows > > > 1) "Hard" real time functions, on a small micro processor not running any > > > OS. Maybe something like an ARM I'd like size the uP so that it could > > > handle four axis and use multiple uP if more axis were needed > > > > Yes > > > > > 2) The user interface _managment_ and higher level non-real time > > functions > > > on a generic "Posix" platform (written in a portable high level language) > > > This could be a PC, Mac, Linux/86, LinuxARM) > > > > Yes > > > > How to connect the little uP to the larger computer? WiFi? Will the uP > run some OS?
This will be the interface between them and is an important point. WiFi, Ethernet, UART or whatever should not be important. What should matter is format of data sent. > Could this little uP running (say) eCos actually be a soft-core CPU > implemented inside an FPGA? That runs the cost up but gives access to > nearly unlimited hardware support for pulse generation and even directly > doing micro stepping. What kind of CPU used for real time should not matter very much. If real time threads are implemented as functions called regularly it should work equally well to call them from an operating system as from an interrupt. Then it come to FPGA most seems to think about signal generation although current micro controllers are very good at this. A FPGA may however implement as many SPI ports as needed which is a fast communication bus available on most micro controllers. It use three singel direction lines which may be isolated cheap and maximum speed is usually in the range 15-50Mbit/s. > > > 3) Rendering of the GUI, that is driving the actual screen and > > > mouse/keyboard. This would be web-abased and like targeted to a mobile > > > device like a cheep $100 Android but of course could run on the same > > > machine as #2 above. > > > > Then linuxcnc is split in two as in 1) and 2) above it is more or less > > done, Why not gtk as now? > > > > 1) Because it will not be long before someone wants to re-build the PC part > on (say) an iPhone. Why not? Why even use a PC at all? Then GUI have been split in two it should work equally to send command from a GUI as from some kind of other software. For example tell linuxcnc to machine a part, wait for it to finnish then tell a robot to remove the part or whatever is needed. > > So yo are going to update the protocol every time you update the GUI? If you ssh a linux computer possible with the "-x" switch this is exactly what X11 do today. It can run a graphical program remotely. > Use something that already exists. HTML5 might work Or same as today, I think it is GTK. Everything already exist within Linuxcnc so nothing new need to be invented. Nicklas Karlsson ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
