Porting to faster hardware

I’d like to test a Teensy with the Maslow. What are the downsides? I will be looking are making a few more of the shields next week also.

Thank you

One downside is - I haven’t gotten the firmware branch brought up to date with v1.15 yet (it’s still v1.08), and it’s the start of haying season here. The heart of the changes live in Config.h and System.cpp, not hard but needing consideration for each change.

1 Like

Ok maybe back burner for a bit on the teensy. I’m looking at smaller heat sinks laying down and active cooling fan all in a sleek, sawdust proof cover.

Thank you

2 Likes

Waiting for the hay to dry, this branch is updated to v1.16 - it compiles and should run, but haven’t had time to run on a Teensy.

1 Like

Since the Pi Zero W came out (which adds onboard WiFi, the original Pi Zero goes for $5.

For that matter, the Pi ZeroW is $10 as well.

1 Like

Yeah, and built-in WiFi. Someone should start work on a Maslow Hat. I wish I had the skills/time to work on something like that!

As I understand it, the new motor board design is 3.3v safe, so you could wire
it to a Pi.

However, while the Pi is MUCH faster than the arduino (multple 1Ghz+ cores vs a
single 8MHz core) and out specs it in just about every way, it is running an OS
(in this case Linux), and that OS gets in the way of doing very precise timing.

I think it can probably still be made to work (see my posts above), but it’s a
very interesting task to make the port.

going to something like an ESP32 would be a FAR simpler task.

David Lang

The ESP32 would be simpler than the Pi, and has double-precision floats as well. In addition, it looks like it might handle the quadrature encoders at a low level, see this post. It can accomodate the EEPROM requirements as well. It is starved for gpio though, but could use an I2C expander for that

Edit - I should have read the link more thoroughly, it specifically does not do quadrature, only 1X and 2X. The a newer version of present Encoder library supports ESP32, though, so not a show-stopper.

1 Like

I do not have personal experience with ESP32 but have read that it is known to miss interrupts while busy handling WiFi traffic. Or maybe that was limited to ESP8266. Sorry, can’t remember the source.

Something to watch out for. In my opinion, WiFi should probably be avoided anyway. The processor’s primary job is managing the Maslow motor/encoders, WiFi would be a distraction.

1 Like

Since the esp32 has 2 cores, I think we should be able to avoid that problem

I wonder if anyone is using RTLinux on Raspberry pi? It would be no small task, but the GPIO code could be contained in a pthread, leaving all the overhead outside the real time threads.

Not sure if it’s worth the trouble to just get to a single-board solution, though.

EDIT: Interesting experiment here: https://medium.com/@metebalci/latency-of-raspberry-pi-3-on-standard-and-real-time-linux-4-9-kernel-2d9c20704495

2 Likes

https://hackaday.com/2018/07/26/grbl-ported-to-the-esp32/ progress is being made, although this is with stepper motors…

also see the topics

HAL for grbl (#374)
and
ARM discussion (#67)

@TheRiflesSpiral, Interesting, my thought on using the Raspberry Pi was being able to use a RESTful API with a short USB cable mounted next to the arduino and controller board. I had experimented earlier with Chillipeppr after reading the forum post on Maslow and Universal G-code Sender. Update for Bar , but sadly never got to far.

I now use the Rasbperry Pi to buffer G code to my recently acquired 3D printer with Octoprint over the network, and it runs without a hitch.

Has anyone else tried running with Universal G-code sender or Chillippr workspaces?

to really be able to use a universal g-code sender, we need to implement the
calibration in the firmware.

David Lang

I haven’t messed with firmware stuff since BASIC stamps were a thing… how realistic is it that the calibration routine could be added to the mega?

1 Like

easy, at the time the calibration calculations are running, the mega doesn’t
have anything else it needs to do, so even if it took minutes, it wouldn’t be
that bad (and it’s probably still under a second or small number of seconds)

remember, the first version was done in an excel spreadsheet :slight_smile:

1 Like

Sure, I guess I was thinking more about the interaction necessary to complete the calibration… Buttons and such. The calibration procedure in GC has an HMI element to it and without the benefit of a screen/keyboard/mouse I’m wondering how it would go.

2 Likes