Porting to faster hardware

From that perspective i would prefer to something that’s arduino compatible. Still the ESP32 looks like a very cool option… (i’m going to sit in a corner to make up my mind on this ESP32)
Mooslake mentioned the $2 STM32 (STM32F103C8T6) in one of the first post in this thread. Is that device a real Arduino compatible by any chance?

I’ve read the whole Blue Pill Wiki but it’s not clear to me if that board is to be considered ‘Arduino Compatible’

The Teensy looks like being the most compatible one, but it’s price is 10 times as high…

But in the neighborhood of three router bits…

1 Like

Let’s break this out -

3 types of Microcontrollers:

Arduino Compatible

Arduino Clone (may or may not be compatible)

Microcontrollers that can be programmed with the Arduino IDE

How this pans out for you depends on your goals.

Hope this helps

1 Like

The fun thing is that with the introduction of the Due, not all boards shipped
by Arduino are compatible with each other :slight_smile:

In practice, if you are going to get anything any faster than the stock arduino
boards, you are not going to be fully compatible. At best you are going to be
source code compatible.

Arduino made their IDE so that it can use libraries and board definitions from
anyone. This means that you can load the ESP32 module and now you have the
ability to compile and flash ESP32 based boards (of many different kinds), some
of the development work to make this possible comes from the ESP32 manufacturer,
a lot of it comes from the opensource community finding libraries that aren’t
compatible and fixing them, and some of it does come from Arduino is being
willing to accept (and support) patches that make their libraries less specific
to their hardware and easier for other hardware to use.

At the bottom, The Arduino IDE lets you program in C nd C++ and helps you load
the result on the board for the processor to run. There is no operating system,
it’s all in the libraries and code that you write.

David Lang

1 Like

I have a very difficult time getting people to understand why and Arduino is different from a Raspberry pi. Why an OS driven system is usually going to crash much more often and why to choose one over the other. I tend to look at things from a toolbox point of view. I run into many people that are making their choice based on cost. A few that will try to use a favorite solution even for the wrong purpose. I want to use the best tool for the job. That said I understand if you have a box of 27 of X that can get the job done with sweat equity. There are many people here with many . different levels of skill sets. I enjoy the conversation in the group.

I have a very difficult time getting people to understand why and Arduino is
different from a Raspberry pi. Why an OS driven system is usually going to
crash much more often and why to choose one over the other.

I want to use the best tool for the job.

Non OS systems can crash a lot too. :slight_smile:

Having an OS makes it much easier to have the system doing multiple things at
the same time.

Not having an OS makes it much easier to do things at a precise time (and tends
to be cheaper, as the OS needs resources to do it’s job)

as chips get faster, it gets easier for an OS-based system to have ‘enough’ time
so that even though it’s not as precise, it’s precise enough for the real world.

Also it gets easier for a bare-metal system to have enough resources to bounce
back and forth between a few different things it’s doing and get multiple things
done at the same time.

If you’re doing a lot of networking or graphics, you are probably better with an
OS.

If you re trying to control a machine directly, you are probably better off
running on bare metal

but in each case, you can work in the othe area, but at a cost in reliability.

1 Like

OS based systems usually come with far better debugging tools. Does the RPi support the source level debugger, one if my favorite tools back when I actively did this stuff?

Worked on a 7 year project that ran on multi board vme systems, my first project was writing an emulator to let (most…) of it run under SysV. Shaved off a lot of debug/test time

1 Like

The RPi is a full Linux system, if it’s available for Linux, you can probably
run it on the Pi (memory is the most limiting factor)

Does anybody use sdb anymore?

Once the cheap chips are powerfull enough to run a real-time kernel then they will be able to do propper real-time work. (Like Linux-CNC does)

After seeing the Odrive post

I’m having an entire new vision.
4 Arduino Nano’s (one per motor) each one dedicated to control 1 motor and one quad encoder
and one Arduino Nano running Maslow.
Using a CAN bus to speak to the motors.

This way it’s also possible to give each motor its own PSU to keep DC lines short and close to the motor. (low loss, more effective power)

BUT

I don’t know if Maslow firmware is written modulair enough to break it into hardware modules.

This also would also open the option to use Odrives for instance.

Will one Arduino Nano be powerfull enough to keep up with the motor speeds?

I have a few Nano boards so maybe we could build a little test? (all in good time)
IF this is at all a feasible way to do things.
I mean, it needs 2 different firmwares that talk to eachother… One main Maslow, and one Motor driver.

Maybe @madcowswe can give us a few hints?

1 Like

To elaborate on the above i made a little sketch for the more visual minded think(er)ers.
modulair electronics

Still the questions remain:
Is the Nano powerful enough for the Maslow FW +
And also for the Motor drivers.

L298 = H-bridge chip
775 = cheap DC motor
encoder = encoder

There would need to be major surgury to the code to make it work with an arduino
on each motor.

There are also ‘interesting’ sync issues when you need to communicate to many
devices at the same time, and they all need to move in sync.

A Nano is just as powerful as any other ATMega (in the processor, not Arduino sense) of the same clock frequency, but it has fewer pins than the 1280 (thus fewer input/output pins), plus possibly a different size ram/firmware memory.

GRBL makes a big effort to run on a 328 (the MCU in many nanos), and the current developer is quite pleased by that (he’s frequently in the shapeoko forum). I see they recently forked off some other versions for more resources hardware.

I see, true that adds another level of brainpower.
Now i think Master and slave clock on the interlinks… Just like in the audio industry…

I’m not very familiar with CAN bus yet, i doubt if that is capable of sync.
Still on the current maslow the motors are quiet far away from the MCU with a lot of noise on the lines…
I thought my approach would somewhat reduce the influence of the noise. I try to see where the sync comes into play here… That’s only the encoder feedback right?

In my experience, having long cables to the motors/encoders is not an issue, but having multiple controllers adds cost. Just my experience.

1 Like

Iirc it was Geckodrive who announced a series of inter-communicating drivers a while back that silently disappeared from their site. It’s not an easy problem to solve

1 Like

multiple power supplies will also add cost

1 Like

I would assume you would still string DC cables around to the controllers in the distributed case.

1 Like

One power source multiple feeds?

1 Like

syncing between multiple devices in real time is hard.

Osker (odrive) was suggestion serial ports spitting positions out multiple times/sec, but without speed instructions, that will result in jerky movement at low speeds and/or problems keeping up at high speeds.

you have more problems with your low-voltage signal wires than with the high voltage power wires.

1 Like