#linuxcnc-devel Logs

Nov 09 2017

07:36 AM jepler: seb_kuzminsky: looks like the builder might need your attention
09:31 AM homicidlbrainiac: Hello again- anyone here?
09:32 AM homicidlbrainiac: I have been writing my own machine controller to force me to learn how they work. Concurrently, I am learning how linuxCNC works and hope to be a contributor one day.
09:33 AM homicidlbrainiac: right now I'm upgrading the way I am doing HAL
09:33 AM homicidlbrainiac: The current way I am doing this is by treating inputs and output pins differently. In my implementation, outputs are what you would called "signals" in linuxCNC
09:34 AM homicidlbrainiac: I did this so that connecting two outputs together is impossible by design
09:34 AM homicidlbrainiac: but I am wondering why linuxCNC does it differently, where it's theoretically possible, but prevented by code which checks to see if two signals are being connected.
09:36 AM mozmck: I suspect in part it's simpler.
09:37 AM homicidlbrainiac: Thanks, mozmck.
09:37 AM homicidlbrainiac: Could it also have something to do with bidirectional pins?
09:37 AM mozmck: It also allows for bi-directional pins which are quite useful at times.
09:37 AM homicidlbrainiac: There you go
09:37 AM homicidlbrainiac: ok that confirms what I am thinking
09:38 AM mozmck: I'm not the expert on the design details of HAL though. jepler knows everything though.
09:39 AM homicidlbrainiac: right now my HAL is hard-wired at compile time in order to avoid dynamic memory allocation. I figured out how to make malloc play well with RTOS, so now I'm converting my HAL to configure at runtime.
09:39 AM mozmck: and cradek, and seb_kuzminsky, :-)
09:40 AM homicidlbrainiac: Well it sounds about right from my inspection of the code
09:40 AM homicidlbrainiac: Besides, if I do it this way, it would make learning linuxCNC that much easier when I take the leap
09:40 AM homicidlbrainiac: My goal is to port linuxCNC over to PIC32MZ series
09:40 AM archivist: leap first :)
09:41 AM mozmck: Yeah, I haven't done any dynamic allocation in microcontrollers either.
09:41 AM homicidlbrainiac: It would be nice if linuxCNC replaced things like smoothie or repetier
09:41 AM homicidlbrainiac: Well, the current workaround I am using is to never de-allocate memory
09:41 AM archivist: I must admit I sometimes write something myself then I really know
09:42 AM mozmck: By replaced, you mean by being able to run in a small micro?
09:42 AM homicidlbrainiac: Yes
09:42 AM homicidlbrainiac: It won't have axis or anything fancy
09:42 AM homicidlbrainiac: but at its core, it will be a linuxCNC machine controller if I have my way
09:42 AM archivist: quite a lot goes on with some setups
09:43 AM homicidlbrainiac: I've looked at a lot of machine controllers and linuxCNC has the most correct design philosophy.
09:43 AM mozmck: It would be interesting to get HAL and the core planner and all in a micro. It would pretty much need floating point support though I think.
09:43 AM homicidlbrainiac: hehe Archivist. Yeah, I can't learn any other way than by doing
09:43 AM homicidlbrainiac: Yes, floating point would be necessary
09:43 AM homicidlbrainiac: not a problem with most PICs
09:44 AM homicidlbrainiac: I'm not an expert on arduino though
09:44 AM homicidlbrainiac: My gut tells me it's definitely possible for PIC32 series
09:45 AM archivist: how much memory on one of those
09:45 AM homicidlbrainiac: around 32K ram
09:45 AM homicidlbrainiac: program memory can be much larger
09:46 AM archivist: 32 k is tiny for some gcode
09:46 AM homicidlbrainiac: The current machine controller I have going uses external ram and a cache.
09:46 AM mozmck: I haven't used PIC32. Switched from PIC16 to ARM and haven't looked back.
09:46 AM homicidlbrainiac: archivist, yes the way I am getting around that is by external ram and cache. I also read gcode from SD card and process it in place
09:47 AM archivist: people using dumb CAM produce megabyte gcode
09:47 AM mozmck: Partly due to the cost for an optimizing compiler for each PIC family.
09:47 AM homicidlbrainiac: Yeah I am getting fedup with the tools for PIC32, are tools for ARM pretty good?
09:47 AM cradek: well there's gcc
09:47 AM mozmck: I use gcc
09:47 AM mozmck: and eclipse for an IDE
09:48 AM * archivist coughs at eclipse
09:48 AM homicidlbrainiac: I am kinda fed up with Microchip forcing people to use their Harmony library. It's horrifically bad.
09:48 AM mozmck: I think the pic32 uses gcc but microchip charges $1000 to turn on optimizations
09:50 AM homicidlbrainiac: Here is my machine controller running a while back. Just starting back up on the project. https://www.youtube.com/watch?v=qasLhuJFZNU
09:54 AM homicidlbrainiac: I think you guys convinced me to implement HAL the way linuxCNC is doing it- where input and output pins are treated as pointers, with signals being the actual memory allocated.
09:55 AM homicidlbrainiac: It'll also make it easier when I see if I can port it over to midrange microcontrollers
09:55 AM homicidlbrainiac: I'll also have to learn how RTAPI works and maybe write some kind of layer for freeRTOS
11:03 AM seb_kuzminsky: jepler: i'll look at the flaky armhf jessie machine
11:19 AM seb_kuzminsky: bleh, the jessie-armhf buildslave did not come back after a remote reboot :-/
11:19 AM seb_kuzminsky: i'll look at it when i get home tonight
11:19 AM seb_kuzminsky: maybe 2018 will be the year of the arm server and everything will be better
11:24 AM jepler: seb_kuzminsky: thanks for trying
11:24 AM jepler: I'm glad you remain an optimist
11:24 AM seb_kuzminsky: i figured, i can't really make it worse