_From @jbrazio on March 30, 2016 20:7_

This is an interesting topic. Following your discussion on the other thread really got me thinking to buy one of these boards (DUE/RADDS).

boelle on 25 May 2016

👍1

_From @Roxy-3DPrintBoard on March 30, 2016 20:18_

@jbrazio Well... If you are not in a super big hurry... It may be best to hold off for a couple of weeks. The real purpose of this thread is to try to identify a 'Reference Platform' for 32-Bit Marlin's. @BioPrinter and I have been exchanging emails. If we can get some consensus on 2 or 3 viable platforms, he is going to start lobbying the microprocessor vendors to see if one of them will step up and provide the development hardware for our group.

The thinking is, if we have 6 or 7 contributors with the exact same hardware being used as a reference platform, we are going to be able to make the transition faster. And then for our users, that exact reference platform is pretty much guaranteed to always work and to have the latest and greatest feature set at all times. The hardware vendor would get a big magnet pulling new 32-Bit 3D-Printer sales in their direction. And given the size of the Marlin user base, that is nothing to sneeze at.

boelle on 25 May 2016

_From @Sniffle on March 30, 2016 20:19_

I would think if we build a hardware interface layer it could be just about
anything even a smoothie...

boelle on 25 May 2016

_From @Roxy-3DPrintBoard on March 30, 2016 20:24_

Yeah... That would be the theory! Maybe I'm just being negative. But having other contributors with the exact same hardware gives me more confidence.

boelle on 25 May 2016

_From @jbrazio on March 30, 2016 20:29_

@Roxy-3DPrintBoard no worries, I believe your approach makes perfect sense and will for sure speed up the effort.

I just see one potential problem, if we want to keep somehow the same existing toolkit and implement some sort of HAL to allow us to have the same code base for 8bit and 32bit then we must stay inside something supported by the Arduino platform ?

boelle on 25 May 2016

_From @Roxy-3DPrintBoard on March 30, 2016 20:40_

It is very possible that Atmel will be the most logical choice at which point, everything is simple. But really... The users don't use the the IDE environment of Arduino to do anything but compile and upload. This is a valid point for discussion, but it is very possible that another environment for the 32-Bit stuff will make more sense. It may be that some version of GCC with a makefile can do everything they need.

(All of these issues need to be put on the table and discussed!!!)

boelle on 25 May 2016

_From @jbrazio on March 30, 2016 20:43_

Users do not use the IDE.. but we do use the Arduino core. :-/

boelle on 25 May 2016

_From @Roxy-3DPrintBoard on March 30, 2016 20:45_

Users do not use the IDE.. but we do use the Arduino core. :-/

At which point we need some type of HAL to move to another vendor's microprocessor! :)

boelle on 25 May 2016

_From @CONSULitAS on March 30, 2016 22:28_

@Roxy-3DPrintBoard @jbrazio
see my https://github.com/MarlinFirmware/MarlinDev/issues/317#issuecomment-203663421

@Wurstnase has a running (but rather old, based on Marlin of 01. Feb. 2015, and experimental) fork for Arduino Due: https://github.com/Wurstnase/Marlin4Due
He just stopped development regarding to his readme.

boelle on 25 May 2016

_From @Wurstnase on April 1, 2016 12:51_

Yes, i've stopped.
Anyhow, there are a lot of 32bit Controller. Take a look at mbed.org for example.
You can use the arm-none-eabi-xxx for stm32, lpc, also the Arduino Due use it. The 'problem' is the HAL or whatever you want to use. But there is no standard lib like avr-lib.

boelle on 25 May 2016

_From @Sniffle on April 7, 2016 5:2_

I already showed this to @Roxy-3DPrintBoard

but what do you guys think?
main board - 2 exruders+ heated bed support + x, y, z drivers
http://www.filastruder.com/collections/electronics/products/duet-controller-v0-8-5

extension board to add 4 more extruders
http://www.filastruder.com/collections/electronics/products/duex4-expansion-board

touchscreen display
http://www.filastruder.com/collections/electronics/products/paneldue

and it's already supported by reprap firmware so we have somewhere to reference for pinouts, etc.

not to mention
http://reprap.org/wiki/Duet
https://github.com/T3P3/Duet/blob/master/Duet0.8.5/Duet0.8.5_Schematic.pdf

is it just me or does this board almost seem too good to be true because it covers pretty much every thing a "moddern" printer could ask for. I'm sure there is a gotcha somewhere but damn talk about a complete package.

edit: think i found the one downside, It uses A4982 steppers so they are hard mounted 1/16th microstepping only. If you can think of more I'm all ears. as far as I can tell the 0.8.5 revision is pretty stable, but if anyone can break it and find faults we can :-P

boelle on 25 May 2016

_From @jbrazio on April 7, 2016 10:59_

I like it uses the same uC as the Due but the drawback (without even deep diving into hardware specs) it's the price, the overall solution you propose is quite expensive ($285).

boelle on 25 May 2016

_From @Sniffle on April 7, 2016 14:35_

Yeah that was my concern as well... It is just kinda the all in one
poackage aside from the 1/16th drivers.

boelle on 25 May 2016

_From @Roxy-3DPrintBoard on April 7, 2016 15:24_

I wonder if they have an updated version of the board they are working on with 1/64 Micro-Stepping? Other than that, and the cost... This is a really good setup.

boelle on 25 May 2016

_From @Wurstnase on April 7, 2016 15:53_

The firmware on this board is not fast enough to support higher
microsteppings. They can calculate Delta without segmentation. But only at
<20kHz.
Roxy-3DPrintBoard notifications@github.com schrieb am Do., 7. Apr. 2016
um 17:24:

I wonder if they have an updated version of the board they are working on
with 1/64 Micro-Stepping? Other than that, and the cost... This is a really
good setup.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/398#issuecomment-206951917

boelle on 25 May 2016

_From @jbrazio on April 7, 2016 15:56_

The firmware on this board

This is were Marlin comes in.. or which firmware are you talking about ?

boelle on 25 May 2016

_From @Bio-Printer on April 7, 2016 16:5_

At: https://docs.google.com/document/d/1whV779t_660hpgTxYxFomgqrOk1CpEQi-8QttTHaI-Q/pub

They say they pre-load the RepRap firmware. They recommend:

The DC42 version of the Firmware covers the widest range of printer configurations - cartesian, delta and core-XY and is recommended for general use. It is available for download at https://github.com/dc42/RepRapFirmware/tree/dev.

boelle on 25 May 2016

If anyone is still tracking this topic, the new Duet board (now called DuetWifi) is available for pre-order. It has a 120MHz Cortex M4 with hardware FPU. Looks really nice but not cheap! More details at https://www.duet3d.com/

bobc on 15 Jun 2016

Thanks for the Heads Up @bobc ! Yes, we are very interested! We just aren't in a position to move forward on the 32-Bit code right now! That really does look like a nice 32-Bit board!!!

Roxy-3D on 16 Jun 2016

I'm keen to follow any topics which bring forward a 32 bit microcontroller. Especially where key features that i'm looking for are

Onboard Micro SD socket
SPI breakout
A USB Type A/C port for flash drives
WiFi and Bluetooth
LAN socket
Run a 3D print server as well, like OctoPrint
The usual drivers and hot ends, thermocouple support preferred

Grogyan on 16 Jun 2016

This is the issue: £118.80

jbrazio on 16 Jun 2016

👍1

Yes, the cost is a little high. But it is an Open Source design. If there are any people buying this board, there will be clones of it showing up. And the good thing is it has everything needed for a 3D-Printer on the board.

Roxy-3D on 16 Jun 2016

I have a duet running my kossel mini, and im building a corexy and now that
this is being released it will be what runs it instead of the duet 0.8.5

Sniffle on 16 Jun 2016

AZSMZ ARM 32bit controller board See
https://m.aliexpress.com/item/32421892934.html for $49 US

On 16 June 2016 at 10:16, Todd Swindoll [email protected] wrote:

I have a duet running my kossel mini, and im building a corexy and now that
this is being released it will be what runs it instead of the duet 0.8.5

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-226356350,
or mute the thread
https://github.com/notifications/unsubscribe/AIOTKdPOt8gM41aBR3DmRLIE1PdSizbCks5qMJXggaJpZM4Imb5C
.

paulusjacobus on 16 Jun 2016

👍2

AZSMZ ARM 32bit controller board See
https://m.aliexpress.com/item/32421892934.html for $49 US

Oh! That is the RIGHT answer! But it is missing the Step Sticks. So it will be a little bit more than that.

Roxy-3D on 16 Jun 2016

As a side thought, what about 64bit SOC's?
That way both the Firmware and the Print Server (OctoPrint) can run on the same device.

Grogyan on 16 Jun 2016

That way both the Firmware and the Print Server (OctoPrint) can run on the same device.

This is a no-go.
https://github.com/MarlinFirmware/MarlinDev/issues/398#issuecomment-220853494

jbrazio on 16 Jun 2016

Unfortunately the Venn diagram of all people's requirements results in no solutions. As I mentioned before, Marlin currently depends on an easily available cross-platform build tool in the form of Arduino IDE in order for the user to configure Marlin.
Other cross-platform IDEs are possible, e.g. PlatformIO, but we don't want anything as heavy as Eclipse.
In practice, that means choosing a board that has a reasonably well-maintained core package for Arduino IDE. That basically means SAM3X (Arduino Due), or maybe one of https://github.com/arduino/Arduino/wiki/Unofficial-list-of-3rd-party-boards-support-urls
Duet/DuetWifi would take a minimal amount of work to make into a downloadable Arduino core package (even if they are not officially supported by Arduino).
Anything based on LPC1769, or Linux capable SOCs is out of scope without a _lot_ of work in Marlin, maintaining a build tool, or developing a new core package.

bobc on 16 Jun 2016

Wow! That is a valuable link!

The only Cortex boards that are supported (in that list) are:

RedBear: https://redbearlab.github.io/arduino/package_redbear_index.json
-- RedBear Duo (Cortex-M3, WiFi + BLE)
-- RedBear discussion forum
Konekt Dash/DashPro (Official): http://downloads.konekt.io/arduino/package_konekt_index.json
-- Cortex M4-based global cellular dev kits, support for all board variants, support for USB and over-the-air programming straight from within Arduino IDE

Roxy-3D on 16 Jun 2016

How about this one
http://www.arduino.org/products/boards/arduino-star-otto

bobc on RepRap has been working on a update to the Due RAMPS card and he is keeping an eye on this one. So there may be all the hardware needed before long.
http://forums.reprap.org/read.php?13,652712

WZ9V on 7 Jul 2016

It's interesting...

esenapaj on 7 Jul 2016

👍1

Enough pins, fast, hardware floating point, Ardurino IDE. Very promising. Sadly not available now. :-(

Blue-Marlin on 7 Jul 2016

http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f446ze.html

http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f767zi.html

All solutions already available

Drk

Drakelive on 7 Jul 2016

I have a Nucleo 411 with just 100MHz. But it works quit well!
https://www.youtube.com/watch?v=lXkOv9qoCp0#t=00m45s

Wurstnase on 7 Jul 2016

Well, it seems that Arduino Due was retired...
https://www.arduino.cc/en/Main/ArduinoBoardDue

esenapaj on 8 Jul 2016

Yes, the ArduinoDue from arduino.cc not from arduino.org. Little bit
confusing. For the STAR OTTO you will need then also the ArduinoIDE from
arduino.org, not that one most of the users uses (from arduino.cc).

Wurstnase on 8 Jul 2016

Otto is promising indeed.

jbrazio on 11 Jul 2016

I haven't seen this before http://www.st.com/content/st_com/en/products/evaluation-tools/solution-evaluation-tools/computer-and-peripherals-solution-eval-boards/steval-3dp001v1.html - a 3D printer eval board from ST. They have a version of Marlin for it called Marlin4ST https://github.com/St3dPrinter/Marlin4ST

Might explain some recent support queries...

bobc on 13 Jul 2016

Not bad, $120 from digikey for a six driver board.

WZ9V on 13 Jul 2016

Not bad, $120 from digikey for a six driver board.

I was thinking the same thing. And they have done an initial port of Marlin to the board. It is too bad they compile their version of Marlin with the Cube software. I wonder if anybody knows how complicated it would be to shift that code base to Arduino?

Roxy-3D on 13 Jul 2016

to shift that code base to Arduino

Possibly "Arduino STM32" + modification realize it?
But it's extremly difficult (probably impossible) for me.

And, it looks like that Marlin4ST is unfinished. For example,
FAST_PWM_FAN, HEATER_0_USES_MAX6675, ADVANCE, etc...

esenapaj on 16 Jul 2016

@St3dPrinter Can you please join this thread? The board shown at the link that @bobc found is impressive. ( http://www.st.com/content/st_com/en/products/evaluation-tools/solution-evaluation-tools/computer-and-peripherals-solution-eval-boards/steval-3dp001v1.html )

If we could get 6 or 8 boards into the right developer's hands, we could make it the reference platform for 32-Bit Marlin and bring up Marlin Release Candidate RC-7 on it.

Roxy-3D on 16 Jul 2016

I ordered a Due for less than $12.. @bobc I only need your magic now ! :-P

jbrazio on 16 Jul 2016

👍1

That reminds me..., new Due-based boards was released few month ago.
Ultratronics - ReprapWorld.com
https://reprapworld.com/?products/listing&cPath=1591__1750

esenapaj on 17 Jul 2016

Are you saying it uses the same processor as the Due ? Because it doesn't look like a Due plugs into that board.

Roxy-3D on 17 Jul 2016

Are you saying it uses the same processor as the Due ?

Yes it is. These are combined type like a Duet. Maybe because my bad English? Sorry.
These boards are already supported by Repetier-Firmware and MarlinKimbra4due (but experimental).

And, these are separated type (plugin type?).
DUE3DOM and DUE3DOM MINI.
http://fabrykator.pl/seasidecustoms/due3dom-elektronika-32bit-dla-drukarek-3d/
These are supported by Repetier-Firmware and my Marlin Duo.

esenapaj on 17 Jul 2016

And, these are separated type (plugin type?).
DUE3DOM and DUE3DOM MINI. http://fabrykator.pl/seasidecustoms/due3dom-elektronika-32bit-dla-drukarek-3d/ These are supported by Repetier-Firmware and my Marlin Duo.

Thank You. That was helpful. The web link https://reprapworld.com/?products/listing&cPath=1591__1750 didn't make everything clear to me. It looks like the difference between the Full and the Lite board is the Lite is only setup for one extruder? Did they just leave parts unpopulated that can be put in later by the user? And one more question, do you know if Arduino can generate code directly for the Ultratronics boards?

Roxy-3D on 17 Jul 2016

Lite is only setup for one extruder?

Compare list says difference between Ultratronics FULL and Ultratronics LITE are
Ethernet port(available/not available) and number of onboard thermocouples(MAX31855?)(four/two).
number of extruders is same.
https://reprapworld.com/?elecinfo

Did they just leave parts unpopulated that can be put in later by the user?

Sorry, I'm not sure.

Arduino (IDE) can generate code directly for the Ultratronics boards?

Yes it is.
Constituent of Ultratronics is Arduino Due + expansion circuit.
It's like a Printboard(Arduino MEGA2560 + expansion circuit) that it's supported by official Marlin.
Also datasheet says:

The design is based on Arduino Due and combines the best features of Megatronics to a new more powerful board.
The board is therefor compatible with Arduino software, but optimized for 3D printers.

esenapaj on 17 Jul 2016

and number of onboard thermocouples(MAX31855?)(four/two).
number of extruders is same.

The reason I was thinking it only handled 1 extruder was because you need 1 temperature sensor for the bed and you need 1 for each extruder. So if the Lite board only handles two temperature sensors, that made me think it was for 1 extruder.

Roxy-3D on 17 Jul 2016

There are another 4 thermistor (!= thermocoupler) inputs.

Blue-Marlin on 17 Jul 2016

Ok! That makes more sense. In that case, I think the Lite board would handle most people's needs. With 4 thermistor inputs, you can have 3 nozzles, or you can have a backup sensor.

It is encouraging that we are seeing multiple 32-bit boards that could work all of a sudden.

Roxy-3D on 17 Jul 2016

I've found some STM32 boards.

・STduino and Marlin_STM32
STduino原型板如何使用(Arduino Compatible) - MakerLab创客实验室
http://www.makerlab.me/guides/2/articles
MakerLabMe/Marlin_STM32: 3d printer Marlin firmware for 32 bit arm cpu STM32F10X
https://github.com/MakerLabMe/Marlin_STM32

But I wasn't able to find where do they sell STduino.

・Rest32
rest32.tk
http://www.rest32.tk/
berryelectronics/ReST32: A modular 3D Printer Controller based on the STM32Duino project
https://github.com/berryelectronics/ReST32
Anyone tried to make a 3D Printer controller? - Page 19 - Arduino for STM32
http://www.stm32duino.com/viewtopic.php?f=19&t=572&start=180#p16470

esenapaj on 1 Aug 2016

There is arduino compatible STM32 board called nucleo. It has similar to arduino pin layout

alexxy on 4 Aug 2016

There are several nucleo boards with different STm32Fxxx processors. But then only have the Arduino uno pins. Not the Arduino mega pins like the Otto.

JustAnother1 on 5 Aug 2016

@St3dPrinter Can you please join this thread? The board shown at the link that @bobc found is impressive. ( http://www.st.com/content/st_com/en/products/evaluation-tools/solution-evaluation-tools/computer-and-peripherals-solution-eval-boards/steval-3dp001v1.html )
If we could get 6 or 8 boards into the right developer's hands, we could make it the reference platform for 32-Bit Marlin and bring up Marlin Release Candidate RC-7 on it.

Sorry, for the late answer but I've just come back from the summer break.
For sure, it will be great to make this board a reference platform for the 32-bit Marlin.
The problem is that stm32 (and particularly the stm32f401 which is the board MCU) is not natively supported by the Arduino Ide.
For now, we are preparing an adaptation of the RC7 for this board as the existing FW, the Marlin4ST, is based on the "old" 1.0.2 version.
Its project tree should be closest to the Marlin's one but it will require an OpenSTM32 IDE (based on Eclipse).

Regarding the possibility to provide some boards for evaluation to Marlin's firmware member, it is something that can be discussed, particularly if you think it is possible to natively supported it.

St3dPrinter on 8 Aug 2016

@St3dPrinter
I'm not a Marlin's firmware member but I'd like to ask to you,
Is connectivity of STEVAL-3DP001V1 compatible with STM32F4 Nucleo?
If it's true, there is some possibility of supporting that STEVAL-3DP001V1 can be supported by Arduino IDE with Arduino STM32 library.

And, I make a request.
Would it be possible that you exclude STEVAL-3DP001V1 from EAR?
Because EAR interdicts that STEVAL-3DP001V1 is exported to my country (Japan).

esenapaj on 8 Aug 2016

@St3dPrinter

Sorry, for the late answer but I've just come back from the summer break.

Not a problem! :)

For sure, it will be great to make this board a reference platform for the 32-bit Marlin. The problem is that stm32 (and particularly the stm32f401 which is the board MCU) is not natively supported by the Arduino Ide.

I don't know that the reference 32-bit platform has to be natively supported by Arduino's IDE. But it probably does need to be something Arduino's IDE can generate code for. We are having problems with older versions of Arduino and trying to keep the code running on both the 8-bit and 32-bit platform is going to be a challenge. Adding an extra compiler and development system into the mix might be too much.

I'm not sure this is possible, but I think Arduino's IDE can be extended to support that microprocessor. We do not have the expertise to do that. But some of the Marlin fans like @Bobc might be able to help guide us on that topic. Bobc, can you please offer your thoughts on this topic?

With that said, I'm not sure the Reference 32-bit platform for Marlin has to be natively supported by Arduino's IDE. I think it would be acceptable to have a set of working board files that a person could use to supplement their Arudino IDE environment to handle the 32-bit platform. We could package the additional board files with the 32-bit version of Marlin and also the documentation and support to use them.

Regarding the possibility to provide some boards for evaluation to Marlin's firmware member, it is something that can be discussed, particularly if you think it is possible to natively supported it.

The entire Marlin Team would want to tie out on this decision. But if we can get the Arduino IDE to compile code for the board, it will make the decision much easier! May I suggest that you consider the possibility of getting your board supported by Arduino's IDE as more important than porting the RC-7 code base to the board? If we had the ability to compile and debug using the Arduino IDE, we can bring up RC-7 and start the process of putting a HAL (Hardware Abstraction Layer) in place to insulate the code from differences in the hardware. In that scenario, the users would configure the Arduino IDE environment for the type of board they have (8-bit or your 32-bit) and we would make the code adapt to what is selected.

Roxy-3D on 8 Aug 2016

...but there are already ways to compile STM32 with the Arduino IDE. It's just not out-of-the box.
screen shot 2016-08-08 at 17 34 34

tcurdt on 8 Aug 2016

👍1

...but there are already ways to compile STM32 with the Arduino IDE. It's just not out-of-the box.

That is what I was hoping was the case. Can you tell us what else has to be changed to configure the Board Menu to support the STEVAL-3DP001V1 board? I presume the additional Board files would have to specify things like where the interrupts are and memory configuration. And most likely they would also have to set up the various options like clock speed and how the timers and GPIO registers work.

That is why I suggested:

May I suggest that you consider the possibility of getting your board supported by Arduino's IDE as more important than porting the RC-7 code base to the board? If we had the ability to compile and debug using the Arduino IDE, we can bring up RC-7 and start the process of putting a HAL (Hardware Abstraction Layer) in place to insulate the code from differences in the hardware.

If we could get Arduino to generate code for the board, I'm pretty sure we can bring up RC-7 on it and start the process of formally supporting the board!

Roxy-3D on 8 Aug 2016

@Roxy-3D I've created 3 CPU packages for Arduino, so I have a pretty good idea what is involved. I did the original Arduino_STM32 package, it was quite easy as Leaflabs already wrote the code for Maple, I wrapped it up for the latest IDE. The hard part is bringing the codebase up to date, fixing bugs, and supporting many variants, which Roger Clark and others have been doing very well over at STM32Duino.

But the question is still, does Marlin team want to use an "unofficial" CPU package, or support an in-project package? An Eclipse based IDE like SWSTM32 is fine for developers like me (in fact I much prefer it to Arduino IDE), but Marlin still requires Arduino IDE for users to configure their firmware.

Personally, I still think the best board for an "official" Marlin32 is one based on SAM3X8E (ie. Due compatible), or close relative such as Duet.

It seems I can't order STEVAL-3DP due to "export restrictions", so it's a non-starter for me. I am also very unimpressed with ST's aggressive approach to IP (i.e. patent trolling), so I would not consider them as a good Open Source partner.

bobc on 8 Aug 2016

But the question is still, does Marlin team want to use an "unofficial" CPU package, or support an in-project package?

It would not take much arm twisting for me to feel OK about using an 'unofficial' CPU package. Especially if I could ask questions about it and examine how it gets its work done. At that point it is only a small amount of work for the user to follow our directions to get the CPU package installed and working in their environment.

It seems I can't order STEVAL-3DP due to "export restrictions", so it's a non-starter for me. I am also very unimpressed with ST's aggressive approach to IP (i.e. patent trolling), so I would not consider them as a good Open Source partner.

You would obviously be on the list of 6 or 8 Developers where I would want a board sent!

It would be good to hear @St3dPrinter 's response on both of these topics. Why is the STEVAL-3DP export restricted? If we declared a 32-Bit board as the Reference Platform, it would need to be widely available for the Marlin users to acquire!

With regard to the IP issues, I don't have a problem with them protecting their IP. But most certainly that can't be done in a manner that precludes Marlin from eventually running on other 32-Bit platforms. @bobc can you give us more details and examples so it makes it easier for us to understand and for @st3dPrinter to address your concern?

Roxy-3D on 8 Aug 2016

Just checked ST Web Site states Country of Origin Italy, Digikey has none available and Mouses says due to US Export restriction it can not deliver it to my country (Germany). I didn't know that the US Export Restrictions apply to Italy. Maybe I should drive there and just pick it up ;-)

@St3dPrinter So maybe there is a mistake somewhere?

JustAnother1 on 8 Aug 2016

So maybe there is a mistake somewhere?

My guess is there is a mistake with regard to the Export Controls. Why would I be able to get a board in the USA and you can't get one from your neighbor in in Italy? Let's let @St3dPrinter clear this up for us!

Roxy-3D on 8 Aug 2016

If the IDE is the problem here: In my experience make files are supported by nearly every IDE that is out there. There are a bit of a point to set up. But done right it is a one time pain.

This would also make it easier for people like bobc and me to use the IDE that we are most productive in.

If the normal user should use Arduino IDE and needs to install an unofficial package then handing them a package that uses makefiles wouldn't be any different, right?

Just my 2c though.

JustAnother1 on 8 Aug 2016

@JustAnother1 I don't think the Arduino IDE is a religious issue. It is probably more of a practical concern. If we have good solid support for the 32-Bit platform with Arduino it just makes our job easier. I think we would still want to embrace Makefile's for the more sophisticated user (and developers).

Mostly, I'm concerned that if we don't have Arduino support the migration path to running on a 32-Bit platform is going to fork the code base in such a way it is difficult to keep both sides up to date and current with the good things that evolve on the other side of the fork. It is possible that concern is without merit, but mostly that is why I want our Marlin 32-bit Reference Platform to be capable of being built by Arduino.

Roxy-3D on 8 Aug 2016

@Roxy-3D : The Issue I see is that there might be issues if more than one way of building the firmware is supported. (someone introduces a patch that needs a change in the build environment, but he updates only one not the other) But I personally would be very happy if it would be possible to build Marlin without the Arduino IDE. I don't know how many people think like me though. By the way there are many Vendors selling 32bit ARM-Cortex chips. The Arduino iDe seems to have the Atmel chip covered. We now struggle with ST. But there is also NXP, TI, SiLabs,..

Having Marlin as one code base that supports AVR and ARM seems to me to be a big challenge. I'm very interested if you will be able to pull this off. But I think that having the same IDE is probably one of the smaller issues. I worked in very successful teams were everyone had sort of his own development environment and it never had been an issue.

My guess would be that to keep the fork from happening the Ardunio side must open up to the requirements from the ARM side. If a fork happens then the developers who fork will state their reasons to fork. I suspect that it will be code related issues related to the differences of the platforms. But limiting tools might also be a reason.

But right now I'm just standing on the side lines eager to learn how a 8bit-32bit common code base can work.

PS. Germany and Italy have no common border. So not real neighbours, but also not far away.

JustAnother1 on 8 Aug 2016

But right now I'm just standing on the side lines eager to learn how a 8bit-32bit common code base can work.

I think everybody agrees we want to put a HAL in place so that the bulk of the code doesn't care about the hardware that is underneath it. If we had a suitable HAL in place, I think the concerns about using a common IDE start getting less and less important. And in fact, that approach has already been proven to be viable with 'Unofficial' 32-Bit versions of Marlin. There is a lot of knowledge already out there that we can leverage.

PS. Germany and Italy have no common border. So not real neighbors, but also not far away.

Yes, but both are inside the EU with the 'free trade' pacts in place and both using the Euro currency. It really makes no sense to me that I can buy the board (using US $'s) and have it shipped to the USA but somebody in Germany can not buy it. That really doesn't sound right. I'm thinking there is a misunderstanding or something. Soon... We will have the explanation!

Roxy-3D on 8 Aug 2016

To be clear, there isn't a generic "ARM-Cortex" architecture that we could
support, since every vendor has different register sets, and also within
vendor families. It has to be specifically STM32 or NXP. Probably specific
families, eg. STM32F10x or STM32F40x, since there are significant
differences.

There just isn't any comprehensive Open Source library that covers every
Cortex M3 and M4 chip out there, libopencm3 has support for many chips but
that is still only a fraction. ISTR that just STMicro have something like
900 Cortex chips. Most vendors support their own chips, but there is no
common API, so it's a case of cobbling together code from each vendor, or
writing from scratch (!)

That's why I recommend picking something very close to Arduino already,
otherwise frankly Marlin32 will never happen.

bobc on 8 Aug 2016

The "Country of Origin" is the place of last significant manufacturing
operation, but it doesn't mean it will be generally on sale there. So it
might go the USA to have a sticker put on it, but once there it is subject
to export controls.

God knows why 3D printing is subject to export controls, pretty ludicrous
really. Terrorists are going to print a bomb? Unfortunately if companies
don't enforce US foreign policy they get slapped with a massive fine, so
they have little choice.

bobc on 9 Aug 2016

Thank You for explaining that @bobc !!!! That was helpful.

May I ask a couple of follow up questions? If we agreed on a particular ARM-Cortex type processor that had an All-In-One board in place for our needs (such as the steval-3dp001v1 board), I think the bulk of the 32-bit activity for Marlin would center around it for a while. Later, I would expect other people to want to use different 32-bit ARM boards. At that point, wouldn't it just be small changes to the Arduino Board files to support a different version of the ARM processor?

Your perspective is very helpful to understanding this mess. The way I'm thinking is if we can just get up and running on a board that has everything we need (and is easy and cost effective for the users to acquire), we can fan out to other boards later. Do you agree with that thinking? Am I missing something?

Roxy-3D on 9 Aug 2016

@Roxy-3D I agree with what @bobc said. I never wanted to imply that Marlin should support every processor out there.

The Cortex-M is a Processor design created by ARM and licensed to the Vendors. The Vendors are then free to configure and extend it to their needs. So an approach as you suggested(starting with one ARM-CPU and then having others added later one by one is a smart way to go. Wanting to have something that supports everything will be impossible.

The thing to look out for is the "Vendor supplied code". ST supplies the Cube package that has all the drivers and stuff to get you going on their CPUs. Basing a HAL on those code will probably give results soon. Allowing other ST CPUs will also be possible rather easy. Having non ST chips working with the ST Cube code will most likely be much harder. (There is a business case here, so you probably can't blame them as all the vendors do this.)

Finding the right API for the HAL will IMHO be the hardest part. But that is something the core developers need to come up with.

JustAnother1 on 9 Aug 2016

@Roxy-3D @JustAnother1 @esenapaj I was not aware of these exportation limitations and I don't see the rational behind it. I dig this point and I inform you when I have news.

St3dPrinter on 9 Aug 2016

I'm aware that Arduino IDE by Arduino.org is supporting stm32f4(STAR OTTO) already.
arduino-org/Arduino at stm32f4
https://github.com/arduino-org/Arduino/tree/stm32f4

esenapaj on 10 Aug 2016

@esenapaj Can you help me understand this a little better? Is this branch a re-mix of the Arduino done by Arduino.cc ? Did this Arduino organization use the other Arduino organizations IDE and extend it to handle the stm32f4 ? Do you know if the current package downloadable at: http://www.arduino.org/downloads has the stm32f4 support in it? (I don't want to install it just to get the answer right now! I don't need any extra chaos in my build environment right now!)

I wish there were not two different Arduino groups. And if there has to be two different groups, I wish they didn't try to make their websites and everything else look identical to each other.

But with that all said (and asked)... This is very good news. Thank You for finding this for us!

Roxy-3D on 10 Aug 2016

I don't when the Otto is likely to go sale - usually these things appear about a year after they are announced - so that might be May 2017. I have a Google news alert set...

bobc on 10 Aug 2016

For people interested in the Otto board, check out this link. It looks like we could plug in any 3.3v RAMPS board to it.

http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-3rd-party-evaluation-tools/ard-otto-stm32.html?icmp=tt3617_gl_pron_may2016#quickview-scroll

@bobc Bob, is it safe to assume these different STM processors do not include a floating point unit unless it states that as one of the features? In this case, it claims it does have a floating point processor:

The STAR Otto’s STM32F469BIT6 MCU is one of ST’s higher-end STM32 models. The 
Cortex-M4 MCU is clocked to 180MHz, and features DSP and floating point operations, 
as well as 2MB flash and 384KB SRAM. This is backed up with the STAR Otto 
board’s 16MB SDRAM and 128KB EEPROM.

I don't (know) when the Otto is likely to go sale - usually these things appear about a year after they are announced - so that might be May 2017. I have a Google news alert set...

On this page, towards the bottom, it says:

Further information

The Arduino STAR Otto (ARD-OTTO-STM32) will ship later this quarter at an unstated price. 
More information may be found in this ST STAR Otto announcement and ST STAR Otto 
product page, as well as at Arduino Srl’s STAR Otto product page.

Wouldn't that be nice if it was true? But this page showed up in May 2016, so it should already be on the shelves to be sold if this statement was true.

That would be really nice if it was true.

Roxy-3D on 10 Aug 2016

@Roxy-3D

Is this branch a re-mix of the Arduino done by Arduino.cc ?
Did this Arduino organization use the other Arduino organizations IDE and extend it to handle the stm32f4 ?

I`m sorry I haven't knowledge of internal trouble in Arduino project and compatibility of their IDE,
but it looks like that IDE by Arduino.cc and IDE by Arduino.org (Arduino Srl?) were same until Mar 10, 2015.
https://github.com/arduino/Arduino/commits/master?page=54
https://github.com/arduino-org/Arduino/commits/stm32f4?page=9

Do you know if the current package downloadable at: http://www.arduino.org/downloads has the stm32f4 support in it?

I downloaded http://download.arduino.org/IDE/1.7.10/arduino-1.7.10.org-windows.zip and examined, it doesn't includes files for STM32F4.
I think that stm32f4 branch is a branch under development.
But when I downloaded a stm32f4 folder and put into hardware\arduino folder of IDE, it looks like that compilation for STAR OTTO done successfully.
default

But I'm not sure that it's no problem absolutely or not, because I haven't any STM32 devices currently.

esenapaj on 12 Aug 2016

But when I downloaded a stm32f4 folder and put into hardware\arduino folder of IDE, it looks like that compilation for STAR OTTO done successfully.

OK! That makes sense. And it is my guess that moving the stm32f4 folder to any (recent and compatible) version of Arduino can be done by doing the same thing! This is good news!

Thank You for checking that out!

Roxy-3D on 12 Aug 2016

Just so that you know. If a Arduino Mega kind of board(Like the OTTO) with a Cortex-M is all you need then maybe this will work:
http://www.ehitex.de/starter-kits/fuer-aurix/2535/hitex-shieldbuddytc275-aurix-powered-arduino-uno-r3-hardware-compatible-platform

JustAnother1 on 13 Aug 2016

@St3dPrinter could you please attach a license file to the Marlin4ST repo as the copyleft GPLv3 requires?

scalez on 15 Aug 2016

@thinkyhead @jbrazio @Roxy-3D @boelle @JustAnother1 @esenapaj @bobc just for reference Ultimachine (@johnnyr) is currently working on an open source board with an Atmel ATSAM3X8E ARM Cortex-M3 (Due's MCU) on it So it works with Arduino IDE.

Here's their work on Marlin thus far: https://github.com/ultimachine/Marlin4Due

scalez on 15 Aug 2016

Ultimachine (@johnnyr) is currently working on an open source board with an Atmel ATSAM3X8E ARM Cortex-M3

@scalez Searching Ultimachine's website doesn't show anything. I guess they are not ready to start shipping. Is there a way to get more information (cost and capabilities) of the board they are developing?

Roxy-3D on 15 Aug 2016

@Roxy-3D it's still under active development; I'm not sure what the cost will be, that's outside R&D.

As for capabilities, all of the designs are permissive: https://github.com/ultimachine/Archim
DRV8825 stepper drivers and an on-board Micro-SD slot.

scalez on 15 Aug 2016

@scalez That is a nice looking board! If you want some extra testing you just have to mention it here! :)

Roxy-3D on 15 Aug 2016

@St3dPrinter could you please attach a license file to the Marlin4ST repo as the copyleft GPLv3 requires?

@scalez A license file has been added.

St3dPrinter on 16 Aug 2016

@St3dPrinter all code that links with Marlin is also GPLv3 (or compatible): https://www.gnu.org/licenses/gpl-faq.en.html#LinkingWithGPL

You must also include the GNU GPLv3 with Marlin. Please include it in your repo.

scalez on 16 Aug 2016

@scalez the license agreement is compatible with GPLv3 as indicated by line:
"(ii)FOR THE SOFTWARE WHICH CONTAINS OPEN SOURCE SOFTWARE: THE APPLICABLE OPEN SOURCE TERMS"

St3dPrinter on 16 Aug 2016

It appears that there is a sticking point in deciding between ST ARM and Atmel ARM as on the Due/Duet. Are there enough of us willing to tackle porting/testing that we could do both? If not, could we just pick one already? XD Anyway, here's my take on the situation...

Availability

While the OTTO board looks promising, and is in the familiar Arduino Mega/Due form factor, I cannot find a vendor selling the board yet. On the contrary, many people already have a Due, and there are more vendors that sell it.

Likewise, in the non-RAMPS world, the Duet and other boards based on the same SAM3X8 are already in use, and the ST board is a relative newcomer and likely has very little penetration into the market.

Atmel wins.

Toolchain/IDE

I certainly don't mind using toolchains outside of Arduino's IDE, but certainly Arduino makes it easy and accessible to more people. Someone doesn't need to be a rocket surgeon to open up the Marlin firmware within Arduino and make changes before flashing their device. Installing and using commandline utilities, especially under Windows and Mac, might be too much of a pain in the ass for most people who are 3D Printer enthusiasts first, and programmers thirtieth.

While there are STDuino Arduino addon packages available for some ST family microcontrollers, there are so many ST micros that it becomes a liability. If we can agree upon an ST micro which has solid Arduino IDE support, then this would be a toss-up, but for the time being, I'm going to have to give this one to Atmel.

Price

ST boards are certainly feature filled and are pretty cheap... the problem is lack of prevalence. Arduino has the opposite problem... The due is $40-$50 from most vendors, and you can get an STM32 board for $12 which will stomp all over the Due from a performance standpoint.

ST wins

Existing 3D Controllers

Finally, there is the issue of 3D Controller hardware. If the ST 3D Printer board used the same CPU as the OTTO, it would be an easy decision, but they are two completely different processors. The difference between the two might be trivial, or it could turn out to be a pain, especially later when we start to leverage the added processing power for better kinematics.

On the otherhand, the Due and the Duet use the same processor, as do a few other 3D controller boards (Archim, Alligator, Tigershark3D)

Selecting an ST board with a non-Mega footprint is certainly a non-starter. We'd either have to develop a new hardware shield, or we'd have to develop an adapter to fit between the devboard and a RAMPS.

To be fair, the Due has a problem with RAMPS... namely the matter of 3.3V vs. 5V. Even if you isolate the 5V on the RAMPS board from reaching the Due, you cannot drive the MOSFETs on 3.3V safely. We'd still have to either build an adapter, or push folks to get a 3.3V-safe RAMPS-like board. Luckily these already exist... but I wouldn't be above designing an updated RAMPS since the design is due for a refresh.

I'm going to have to give this point to Atmel.

Conclusion

Despite having a Due, and a Duet which should be arriving sometime this month, I can still say that I have no dog in this fight. I have plenty of STM32 boards collecting dust, and I can pull them out and put them to use at a moment's notice. I just think that we should pick a processor or two, and solidify that decision so that once 1.1.0 lands, everyone is ready to go with porting. Honestly, I feel that going with Atmel is the best path forward, especially if ST already had plans to port 1.1.0 using their own resources. Once Marlin is ported to the ST evaluation 3d printer board, then much of the same code could likely be used to port to the Otto.

zenmetsu on 16 Aug 2016

Ultimately, I think we will have 3.3v RAMPS boards and things like it. But right now we don't have anything like that to choose from. That is why a single board solution like: http://www.st.com/content/st_com/en/products/evaluation-tools/solution-evaluation-tools/computer-and-peripherals-solution-eval-boards/steval-3dp001v1.html or https://github.com/ultimachine/Archim might make sense.

We need the options boards to actually be designed to work with a 3.3v processor. And we need the heaters to default to a safe state if the processor doesn't boot up and give Marlin control of the heaters. If it wasn't for this fact, I think we would already be trying to use the RAMPS for Due board.

I don't think it really matters too much what 32-Bit processor or board we support officially first. But it should be a viable platform for our users to acquire. (It needs to be available and cost effective) Once we have an Official 32-Bit branch of Marlin I envision that will still be the 'Reference Platform' for a long while after other 32-Bit boards start running Marlin.

The big reason for the Arduino push is this thinking: I don't think we are so worried about the developers getting Marlin up and running using a different tool chain. The problem comes later if we have a 32-Bit and an Arduino fork of the tree. If we can build the 32-bit environment with Arduino, it is going minimize issues of trying to keep the two branches synchronized. And hopefully what happens is an 8-Bit or 32-Bit HAL gets built depending upon how you have your Configuration.h settings.

St3dPrinter is working in the background to answer a few questions we have that affect the suitability of the steval-3dp001v1 board for our purposes. I expect we will hear from him soon and have a clearer view of the landscape.

Roxy-3D on 16 Aug 2016

I hear you on the Arduino point, and I agree.

I'm just looking at the market and seeing the Atmel processor turn up in more and more designs.

I've also noticed the proclivity for folks to copy-pasta hardware designs. I saw common flaws in many RAMPS derivatives. While this sucks when it comes to perpetuating bad design decisions, it is good for keeping the number of microcontrollers to a reasonable number. I think that the SAM3X8 microcontrollers are going to be the next "ATMEGA". Unless anyone wants to argue otherwise, I think that it is pretty evident that ball is already rolling.

That said... here's another tasty board I found online.

zenmetsu on 16 Aug 2016

@zenmetsu That looks very similar to the link I posted in the last message. It looks like an updated layout of this board: https://github.com/ultimachine/Archim/commit/f3092cc149fcad3d60e6064343e2a3c0e30871ce

Is this board available? If so, for how much? From where?

Is this board 'safe' with regard to the heaters if the processor doesn't come up and is unable to manager the heaters?

Does this processor have a floating point unit? I think the speed of the 32-Bit boards is going to make a floating point unit optional. But it would be nice to have a floating point unit built into the chip.

Roxy-3D on 16 Aug 2016

I'd have to look at the header situation, but I can tell you that the SAM3X8U does not have an FPU. Personally I prefer ST's hardware over Atmel's, and hinted at this in my price comment above. Unfortunately everyone and their mom tends to gravitate to Atmel.

The ST parts usually have signal processing capabilities, which we may be able to utilize in the next generation controllers. I'd love to steer this decision towards STM, but I think that there is already a lot of momentum going the other direction.

One thing that we could do, which I think would help immensely, is to design a generic test interface for the RAMPS board. We can come up with a bread-board setup where we can safely attach 3V or 5V logic to a RAMPS board with a standard pinout, that way we can just throw any board at the problem and at least have something on which to test. I don't think that impedance/noise issues will cause issues between the devboard and the RAMPS because it is all relatively low frequency. Do you concur?

zenmetsu on 16 Aug 2016

I don't think that impedance/noise issues will cause issues between the devboard and the RAMPS. Do you concur?

At 16 MHz I think this is true. We have some Electrical Engineer types in this thread that can tell us better. My concern is when we jump to 80 MHz, any impedance mismatch is going to cause reflections on the signals and we need this to be rock solid. It maybe that we can zap a few setup registers and slow down the I/O so my concern is a non-issue.

But in the bigger picture, what we are trying to do is identify a 32-Bit 'Reference Platform' that is ready to go. By the time we worked through a prototype of an interface board, there probably will be real hardware available. There are so many promising options right now. The problem is they all have one issue or another.

I'm hoping we can get good answers for that steval-3dp001 board!

Roxy-3D on 16 Aug 2016

We don't communicate with anything on the RAMPS board at MHz speeds... well, SPI and I2C are the highest frequency, but PWM/Steppers/etc are all relatively immune to impedance mismatching. If there is concern over SPI/I2C, we don't have to include it in a test harness and just wire those components direct to the dev board.

I really want answers on that STM board as well. I really like the STLINK that they use, and I would really like to know what sort of pricing we can get on these. The website says that the MSRP is for budgetary purposes and to call for a quote, so maybe we can get a group purchase discount here, especially if it will drive development. I've got 2 3D printers and a 3rd device in the works, so I am already in the market for another controller. ST already won my vote with that board because they did proper protection on the endstop inputs, something that even the Duet lacks.

zenmetsu on 16 Aug 2016

Also, that STM board has a different type of stepper driver, which may be of importance from a code compatibility perspective. Just a heads-up. [http://www.st.com/content/st_com/en/products/motor-drivers/stepper-motor-drivers/l6474.html] They are limited to 1/16 stepping, so that might be a turnoff for some people. I think in my case higher steppings would only allow me to drive the noise down a bit, but I kinda like the sound of gnarly stepper motors driving delta bots, so I'm OK with it.

zenmetsu on 16 Aug 2016

The 80 MHz is a non issue. This high speed is only within the processor. By the way I clock my ST at 168 MHz.
You are right though that high speeds on unshielded cables can be a problem. The rule of thumb is that the signal quality will go down with higher speed and longer cables.

I personally tested SPI with a 4 MHz clock over 20cm jumper cables and had no problems at all. I don't think that you will have faster signals that leave the processor in version 1.1.0

So a ST Discovery board with Jumper cables connected to a RAMPS or whatever will work for signal integrity. The only thing thing is to get the firmware working.

You should not under estimate the value of a JTAG/SWD debugger. Being able to see the actual values of your variables and watch your code step by step makes finding bugs so much easier and so much more productive. (The cheap ST Boards come with Debugger on board)

JustAnother1 on 16 Aug 2016

So a ST Discovery board with Jumper cables connected to a RAMPS or whatever will work for signal integrity. The only thing thing is to get the firmware working.

Not so fast. Those MOSFETS on the RAMPS will implode if you try to switch them at 3V. Also, we might need some other signal level shifting for inputs back to the devboard. This is why I said we should design a universal test setup for a breadboard. We could step up the voltage TO 5V for the MOSFET control D8, D9, D10... and anything else that needs 5V.

And 100% agree with JTAG point... which is why i have so many STM boards laying around. For instance, I have an STM32F4 Discovery board which I have used for learning. I've done some pretty crazy things with it, including writing my own bilevel (monochrome) OLED video player from scratch. But I don't know my way around Marlin well enough to port the code... mainly stuff like timers and interrupts. Once enough of the code is built up, I can start to be of use for debugging and testing.

zenmetsu on 16 Aug 2016

I really like the STLINK that they use, and I would really like to know what sort of pricing we can get on these.

You should not under estimate the value of a JTAG/SWD debugger. Being able to see the actual values of your variables and watch your code step by step makes finding bugs so much easier and so much more productive. (The cheap ST Boards come with Debugger on board)

Yeah! I was already looking at the STLink stuff! The idea of having an In Circuit debugger really would be nice. If this port lets you set break points and display memory, our 8-Bit Developers would switch to the 'Reference Platform' to do their debugging.

I'm not sure, but this might be all we need to access the STLink port:

http://www.ebay.com/itm/Mini-ST-Link-V2-Stlink-Emulator-Downloader-Programming-STM8-STM32-w-Metal-Shell-/282122691251?hash=item41afd2a2b3:g:kZIAAOSwaB5XoZq1

or

http://www.ebay.com/itm/DZ399-St-link-v2-stm8-stm32-artificial-device-programmer-stlink-1pcs-/271513272420?hash=item3f3773c064:g:xnkAAMXQpPhTjum7

Roxy-3D on 16 Aug 2016

@Roxy-3D The boards that I have used have allowed me to just use the USB port for debugging using gdb.

[http://vedder.se/2012/12/debugging-the-stm32f4-using-openocd-gdb-and-eclipse/]

zenmetsu on 16 Aug 2016

Is ST the only ARM company with an in circuit debugger? If the answer is "Yes." that pretty much makes the decision for me. Having GDB available would be a God-Send !

Roxy-3D on 16 Aug 2016

They are not the only ones... I have Microchip boards which have debuggers as well. Unfortunately I don't see anyone building 3D Printer controllers with them. I tend to use their parts since they are HQ'd in my state.

zenmetsu on 16 Aug 2016

if @St3dPrinter gets back with us with purchasing info and answers to your questions, i might even end up ordering a board today.

zenmetsu on 16 Aug 2016

If you are in the USA, I believe you can order a board from DigiKey. One of the questions St3dPrinter was working on was "Why is the board Export Controlled, and can it be made available to Europe?" That doesn't really affect you being in the USA, but if you wanted to have the same hardware as what gets declared as the 'Reference Platform' it might affect your decision to buy it now.

http://www.digikey.com/product-search/en?keywords=STEVAL-3dp001

Roxy-3D on 16 Aug 2016

Regardless of whether or not ST's board becomes the reference platform for Marlin, it would be of use to me. I am working on a delta machine which cannot be controlled as-is with an ATMEGA due to lack of processing power. I could always take a shot at writing firmware from the ground up. :) I have 6 linear actuators that I am driving... if I pair them up, I get a traditional X,Y,Z delta machine. If I operate them independently, I gain 3 degrees of rotation.

zenmetsu on 16 Aug 2016

"the license agreement is compatible with GPLv3 as indicated by line:"

@St3dPrinter Sorry, it is not compatible. MarlinST is a derived work of a GPL licensed software. A condition of GPL is that derived works must also carry a GPL license. In other words, if you add code to a GPL project, the added code must also be GPL. The "Liberty" license is not listed as an Open Source license, I am sure it is not GPL compatible.

If you want to use Open Source software, that's great, but please conform to the license requirements.

I must admit I don't get the love for STMicro stuff. SAM3X boards are here now, and not encumbered with restrictive license or export policy. I wish I hadn't mentioned ST now :)

bobc on 16 Aug 2016

Jtag Debugging the SAM3X means this:
http://www.ebay.com/itm/Original-Atmel-ICE-Programmer-Atmel-ARM-Cortex-M-SAM-AVR-MCUs-JTAG-SWD-Debugger-/262000883182?hash=item3d007835ee:g:PrsAAOSwLVZVybV0
at $137.99, or what? I have seen cheaper offers where they sell only the board. Bu I think they have been still about 10 times the prices that @Roxy-3D found for the ST Link thingies.

JustAnother1 on 17 Aug 2016

Yeah, but the more I look into the ST offering, it looks like a modified Marlin that talks to middleware on their system. I'm not sure that can translate directly to any sort of "reference platform". Man, I'm so torn... lol

zenmetsu on 17 Aug 2016

When we make a 32-Bit branch, we would put a HAL in place and try to keep as much of the Marlin code intact as possible. I'm sure we would look at what ST did to get ideas and a better understanding. But we would not use the ST branch as the 'Reference Platform'.

Roxy-3D on 17 Aug 2016

Just my 2¢ JTAG programmers are overkill for In Circuit Programming, while some micros will only program via JTAG others only use JTAG for debugging purposes, and a simple ICSP is good enough.

As for programming interfaces, any open source tool chain capable and free of cost should be considered.

Grogyan on 17 Aug 2016

@Grogyan We aren't talking about in-circuit programming. We are talking about interacting with the firmware while it is running, using tools like GDB to step through code, set breakpoints, and retrieve internal values. The added-value when developing something as complex as Marlin should not be overlooked.

Besides, it looks like the ST 3D Printer board does have a slave microcontroller for handling USB debugging as I mentioned earlier, so the need for a separate piece of hardware is obviated.

zenmetsu on 17 Aug 2016

@bobc The license agreement mentions that for open source software, the terms of the license which are applicable are those of the open source software. So, in our case, for all the code of the repo which is linked to the Marlin FW, the applicable license is the GPLv3. The ST liberty V2 license which is mentionned in the license agreement does not apply for this part of the code.

St3dPrinter on 17 Aug 2016

@zenmetsu Besides, it looks like the ST 3D Printer board does have a slave microcontroller for handling USB debugging

I confirm: the ST-LINK is embedded on the steval-3DP001V1 thanks to a dedicated slave STM32. So, you do not need to buy external debuggers.

St3dPrinter on 17 Aug 2016

@St3dPrinter Thanks for the confirmation. I find the ST-Link interface to be valuable.

The only thing holding me back right now from making the investment in this board is the development environment. I try to remain minimalist when I can, and while I can tolerate having one or two IDEs, like Arduino, it drives me bonkers when I have to install some behemoth dev environment since I typically work from a linux box at home, my macbook when I'm on mobile, or a Windows10 machine when I'm carrying my On-Call laptop.

If the libraries can be installed in linux and everything handled from a commandline using standard toolchains, I'd be thrilled. Likewise if someone manages to get a package put together for integrating within the Arduino IDE, I think a lot of people would be happy.

zenmetsu on 17 Aug 2016

@zenmetsu For the debug under linux, you can use Eclipse and dedicated pluggins but for sure this is not what we can call a minimalist environment!

St3dPrinter on 17 Aug 2016

@St3dPrinter Sorry, you are not getting it. ALL of YOUR code must be published as GPL, if you include it in a work derived from a GPL project. Refer to section 5 of GPLv3 "Conveying Modified Source Versions".
Really, I strongly suggest you consult your legal dept.

In the meantime, I will be flagging an issue with github and maybe they can explain how the GPL works.

bobc on 17 Aug 2016

@zenmetsu a pure command line development is possible. For programming/debugging you can use this:
https://github.com/texane/stlink

plus GDB. You can compile with gcc or llvm. All that big IDE and STCUBE stuff is just "to get you started faster" and for people who are afraid of the data sheet.

I do development for an STM32F405 for this board:
http://forums.reprap.org/read.php?13,524276

JustAnother1 on 17 Aug 2016

@JustAnother1 Thanks. I do dev on my STM32F4 Discovery board and I used gcc and basic tools. I saw mention of all the STCube and MonstroIDE stuff and got hit with the doubthammer. As long as development similar to what I do with the Disco board is possible, then I'm not so put off by this board.

I'm just worried now about the licensing bit. Is there really an issue?

zenmetsu on 17 Aug 2016

I was wondering if using/building Marlin on a RTOS would be viable? Something like FreeRTOS handles both AVR, ARM, PIC...
I personally don't have any experience using a RTOS, what do you think? Would the hardware become more trivial? I know there are technologies out there that are almost a swear word to developers, is RTOS one of them? Lol

apballard on 10 Sep 2016

I was wondering if using/building Marlin on a RTOS would be viable? Something like FreeRTOS handles both AVR, ARM, PIC...

There are some of us here that believe strongly it would make sense to put an RTOS under Merlin when we move to a 32-Bit platform. There are others that are much more skeptical on the topic. It may be one of those things that what happens depends on who actually does the work.

It would probably be easier to keep the 8-Bit and 32-Bit branch of Marlin synchronized if we did not put an RTOS under Marlin (on the 32-Bit platform). But in my mind, that isn't a good reason not to do it. I think everybody is in agreement some type of HAL (Hardware Abstraction Layer) should be used for the migration. It maybe that we could hide much of the RTOS from the main Marlin code by using the HAL to abstract it also.

Much more work and discussions will be done once we get a few developers with viable 32-Bit platforms.

Roxy-3D on 10 Sep 2016

I have a very poor opinion of Geeetech, but does any body have a GTM32 board? I can't find a price for it on Geeetech's website. And I can't find what IDE or compiler is used to build firmware for it. I think the ST-Link debugging capability is available with it. If anybody can provide any information about it, PLEASE DO! Thanks!

Roxy-3D on 11 Sep 2016

@Roxy-3D

I don't have one and I can't seem to see any pricing or anywhere it's for sale. It would seem that most stm32 based boards are using stm's programming environment that uses eclipse.

http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-ides/sw4stm32.html?sc=sw4stm32

There are documents and forums indicating that ST-Link is used, you have most probably seen it already. But no first hand experience. Sorry.

http://www.geeetech.com/forum/viewtopic.php?f=13&t=17173

apballard on 11 Sep 2016

To program and debug STM32s all you need is a ST-Link debugger (Part of each Discovery board and each Nucleo board) and this Software:
https://github.com/texane/stlink

JustAnother1 on 11 Sep 2016

In the meantime, I will be flagging an issue with github and maybe they can explain how the GPL works.

@bobc is totally right.

Here is an interpretation from Apache about compatibility of their license with GPL:

Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0.

Wurstnase on 14 Sep 2016

👍1

Or in other words. Adapt the license, write your own Firmware or find a Firmware with a license which is compatible.

Wurstnase on 14 Sep 2016

👍1

Cant wait until something is settled with how Marlin will go 32bit. Im holding on on buying any hardware for my new custom made Corexy printer, I almost went Smoothieboard as im impatient but I really like Marlin.

adamfilip on 14 Sep 2016

@adamfilip
+1

apballard on 14 Sep 2016

The Marlin4ST license has been updated. The GPLv3 license applies for all the code.

For the moment this code is based on 1.0.1 of Marlin but a new version, based on 1.1.0-RC7 is almost ready. Just a Z-homing issue to solve.

To build and debug it, you can use the "System Workbench for STM32" GUI (www.openstm32.org), which is based on Eclipse. Installers for different platforms (Win, Linux and Mac) are available.

St3dPrinter on 28 Sep 2016

👍1

@St3dPrinter Were you able to find out if there really were export restrictions on that board? I'm in the USA and this link says I can get the board for $118.

http://www.digikey.com/product-search/en?keywords=steval-3DP001V1

I would appreciate it if some of our European Marlin users can confirm they can also order the board! And if not, maybe search a little bit and see if they can obtain the board from a European source such that export restrictions are not a problem.

Roxy-3D on 28 Sep 2016

I think this answers it roxy.

http://www.mouser.co.uk/Search/m_ProductDetail.aspx?STMicroelectronics%2fSTEVAL-3DP001V1%2f&qs=sGAEpiMZZMuzPc6elQUKoBymz5KZS1icyMoP4Tx%252bVkaeKgYRWqW1nA%3d%3d

On Sep 28, 2016 3:13 PM, "Roxy-3D" [email protected] wrote:

@St3dPrinter https://github.com/St3dPrinter Were you able to find out
if there really were export restrictions on that board? I'm in the USA and
this link says I can get the board for $118.

http://www.digikey.com/product-search/en?keywords=steval-3DP001V1

I would appreciate it if some of European Marlin users can confirm they
can order the board! And if not, maybe search a little bit and see if they
can obtain the board from a European source such that export restrictions
are not a problem.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-250285649,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN4flZF6evy4WZGvk1hgwHW9BXyHZmEks5quspTgaJpZM4Imb5C
.

Sniffle on 28 Sep 2016

I'm in the uk and seems we can buy them direct from http://www.st.com/content/st_com/en/products/evaluation-tools/solution-evaluation-tools/computer-and-peripherals-solution-eval-boards/steval-3dp001v1.html

Unless they were going to charge me but not send it.

brainscan on 29 Sep 2016

In my case ST gave the order to Mouser and they denied the delivery (to Germany) for the known reasons.

Blue-Marlin on 29 Sep 2016

At the moment i begin to experiment with:
ST NUCLEO-F429ZI (http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f429zi.html)
Arduino CNC Shield (http://blog.protoneer.co.nz/arduino-cnc-shield/)
4 MOSFET IRF540 board (like http://www.ebay.de/itm/New-Switch-Module-Mosfet-Four-Channel-4-Route-Button-Irf540-V2-0-For-Arduino-/272299961016?hash=item3f6657aab8)
and some resistors and thermistors.

Hopefully the F429 has enough 'bang' to use mbed, instead of programming down to the bare registers.

PlatformIO seems to work as a multi platform IDE for Arduino and mbed - Win, Linux and Mac.

Blue-Marlin on 29 Sep 2016

👍1

OK. But the DigiKey site doesn't seem to have any of those restrictions. I wonder if somebody in Europe can see if they can buy the board from DigiKey. The point is, it would be really nice if the hardware to run the 32-bit version of RC-7 of Marlin can actually be obtained by everybody!

Roxy-3D on 29 Sep 2016

Digikey.co.uk simply do not list items you can't order, and STEVAL-3DP001V1
is not listed. Meanwhile digikey.com has this to say:

Export

By submitting this order you acknowledge that these commodities,
technology or software will be exported from the United States in
accordance with the Export Administration regulation. Diversion contrary to
U.S. law is prohibited. This information is collected by Digi-Key for
export purposes, is confidential and will be used to ensure compliance with
U.S. Export Law. For more information on U.S. Export Regulations visit
www.bis.doc.gov.

So order it from the US and break US law, there is no way round that. You
might be able to evade US export restrictions on a one-off basis but that
is not a road I would go down.

There are other 32 bit boards we can all use, which don't have stupid
restrictions, and are even Open Source, so I don't know why we are fixated
on this ST one. I'm genuinely sorry I ever mentioned it.

On 29 September 2016 at 03:06, Roxy-3D [email protected] wrote:

OK. But the DigiKey site doesn't seem to have any of those restrictions. I
wonder if somebody in Europe can see if they can buy the board from
DigiKey. The point is, it would be really nice if the hardware to run the
32-bit version of RC-7 of Marlin can actually be obtained by everybody!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-250352079,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR4ouihw0P_rG_fhyPabHZsL4okbrks5qux0ngaJpZM4Imb5C
.

bobc on 29 Sep 2016

@Roxy-3D
Take a second look. No prize and a hint at the bottom of the page.

Blue-Marlin on 29 Sep 2016

I will check why there is this kind of restriction.
These restriction are not due to ST. This board is produced in UE (in france), not in US.

St3dPrinter on 29 Sep 2016

Digikey.co.uk simply do not list items you can't order, and STEVAL-3DP001V1 is not listed.
Meanwhile digikey.com has this to say:

By submitting this order you acknowledge that these commodities, technology or software will be exported from the United States in accordance with the Export Administration regulation. Diversion contrary to U.S. law is prohibited. This information is collected by Digi-Key for export purposes, is confidential and will be used to ensure compliance with U.S. Export Law. For more information on U.S. Export Regulations visit www.bis.doc.gov.

OK, Thanks! That is really bad news. We need a board that everybody can lawfully use!

So order it from the US and break US law, there is no way round that. You might be able to evade US export restrictions on a one-off basis but that is not a road I would go down.

Right! Everybody is in full agreement. We need a board that can be easily obtained by everybody. And in a fully legal manner.

There are other 32 bit boards we can all use, which don't have stupid restrictions, and are even Open Source, so I don't know why we are fixated on this ST one. I'm genuinely sorry I ever mentioned it.

Yes. But St3dPrinter is going to have a version of RC-7 running on this board very soon. A lot of 'Good' has come out of you mentioning that board.

Roxy-3D on 29 Sep 2016

bobc started years ago a really good starting point for a port. I guess, that no 'normal' user can compile this ST-project. Unfortunately when I took his work, I made a Due-only version of it, because my knowledge in the past was very low.

Anyhow, there are several ArduinoDue-style boards in the world. RAMPS-FD, AlligatorBoard, DUET...

Grab one, take a look into the old ports, and make it compatible to current source.

Wurstnase on 29 Sep 2016

👍1

To keep you informed.

Firstly, the export restriction is about to be solved (some missing documents for exportation). I will keep you informed.

Secondly, the schematics of the board are available and can be freely used, freely modified... . I'm not aware of the Open Hardware definition but I think we are no(t) so far of(f) it. I will also check this point.

St3dPrinter on 30 Sep 2016

👍1

Arduino LLC and Arduino srl will be united at the end of 2016.
Arduino Blog – Two Arduinos become one
https://blog.arduino.cc/2016/10/01/two-arduinos-become-one-2/

Two Arduinos Become One
http://www.arduino.org/blog/two-arduinos-become-one

esenapaj on 2 Oct 2016

👍3

And with a little luck, the 32-bit version of Arduino will get merged into the 'official Arduino'.

Roxy-3D on 2 Oct 2016

@Roxy-3D
Isn't the DUE 32 bit? What do you talk about?

Blue-Marlin on 3 Oct 2016

The Due is 32-bit and there is already a shield for it called RADDS you can buy today.

WZ9V on 3 Oct 2016

Isn't the DUE 32 bit? What do you talk about?

I thought that came from the other side of the Arduino split. I might be mistaken about that.

UPDATE: Here is what caused the confusion in my mind:

esenapaj commented on Aug 10: I'm aware that Arduino IDE by Arduino.org is supporting stm32f4(STAR OTTO) already. arduino-org/Arduino at stm32f4
https://github.com/arduino-org/Arduino/tree/stm32f4

That was for the OTTO board.

The Due is 32-bit and there is already a shield for it called RADDS you can buy today.

If I remember right, Due is 'retired' now. And I forget, but there were problems with RADDS. I think the issues were either it did not reliably drive the 5v step sticks because it was 3.3v or else it was not safe because at reset the heaters turned on at full power and relied on the processor to turn them off very quickly. Maybe I'm mistaken. It is hard to keep all of this straight.

Roxy-3D on 3 Oct 2016

it was not safe because at reset the heaters turned on at full power

Well, It's RAMPS4DUE.
In case of RADDS, it's no problem.

esenapaj on 3 Oct 2016

Mass produced 32bit hardware catalog part1: Arduino Community

・Shield for Arduino Due

・Atmel SAM3X8E MCU integrated boards (Arduino Due compatible)

esenapaj on 7 Oct 2016

Mass produced 32bit hardware catalog part2: Smoothie Union

・ SmoothieBoard and compatible boards of it

esenapaj on 7 Oct 2016

Mass produced 32bit hardware catalog part3: Other's Frontier

・ Shield for BeagleBone Black, evaluation board by STMicro, etc

| Name | ChiTu | ChiTu Mini | Teensy 3.1 |
| :-: | :-: | :-: | :-: |
| Picture | | htb1slwlkxxxxxbsxxxxq6xxfxxxc | teensy31 |
| Type | Controller and Shield unified | Controller and Shield unified | Controller |
| MCU | STMicro STM32F103ZET6 | STMicro STM32F103ZET6 | NXP MK20DX256VLH7 |
| Architecture | ARM Cortex-M3 | ARM Cortex-M3 | ARM Cortex-M4 |
| FPU | No | No | No |
| Freq. | 72MHz | 72MHz | 72MHz |
| SRAM | 64KB | 64KB | 64KB |
| Flash | 512KB | 512KB | 256KB |
| Stepper | Allegro A4988 x 4 | Allegro A4988 x 4 | No |
| Supported firmware | chitu firmware | chitu mini firmware | Marlin (for Teensy 3.1) |

esenapaj on 7 Oct 2016

Mass produced 32bit hardware catalog part1: Arduino Community

@esenapaj Thank You! I wonder if we should restart the discussion from the top with this new set of information. I guess we should hunt down prices for all those boards. That will factor into the discussion.

Roxy-3D on 7 Oct 2016

We need to compile a spread sheet, with all of these boards and features. and then start to cross them out until we end up with a selection

I have created a shared / editable google spreadsheet. perhaps we can all work on this together to fill in details

Link to doc

adamfilip on 7 Oct 2016

We need to compile a spread sheet, with all of these boards and features. and then start to cross them out until we end up with a selection.

I agree. And besides what you just said, we need a cost column and an 'Available from:' column. I don't think it is super important, but I would also like to know which boards use a 32-bit processor that has a built in floating point unit. (as well as RAM, FLASH and EEPROM size) Oh... And for sure the developers would like to know which boards have debug support like the ST-Link gizmo. If all things are equal, having good debug capability is going to be appreciated.

Roxy-3D on 7 Oct 2016

everyone can all in any coloumns required to help make a decision.

adamfilip on 7 Oct 2016

Is everybody convinced that having a "reference platform for Marlin" is a must?

I think from the past we can conclude that there will be new board popping up all the time. And Marlin always supported many boards. Do you agree with me that in the end ideally Marlin should be able to run on all these boards?

If so then I would suggest a different approach. I think right now we have some developers that have some kind of ARM based board sitting around. They probably all have different boards, but they are all developers, so they are probably able to fix the problems with their board or find a work around.

So all that would be needed is to get these people together to agree an on HAL API and on which features go into the HAL and which don't. Then everybody could start implementing their HAL and work together on the features that are not in the HAL part of Marlin. They can also work together (and with the other Developers) on getting the AVR boards working with that HAL API.

I know that this approach sounds a bit chaotic, but I think it very well matches the Open Hardware/ Open Source way of doing things. I also don't think that we will have 10 developers with 11 different boards. There will be people that have the same board that can directly work together.

The additional benefit is that boards that are good available will have a better chance to land in the hands of a developer. And boards that are easier to port to or have really cool features will get a working port sooner. Maybe even some of the board designers will help to get their board supported sooner.

The HAL layer would also get the full complexity of requirements thrown at it right at the start. So we either find a really good HAL API or it won't work. That is probably much better than to start with an API that works on the one Board and then to have it all the time to get it working on other boards.

Does that sound like a plan or am I just being stupid?

JustAnother1 on 7 Oct 2016

There needs to be a first board that all other boards build off of. Once
that first board is fully supported further boards can be added in easily
just as they are currently added now.

On Oct 7, 2016 10:46 AM, "Lars Pötter" [email protected] wrote:

Is everybody convinced that having a "reference platform for Marlin" is a
must?

I think from the past we can conclude that there will be new board popping
up all the time. And Marlin always supported many boards. Do you agree with
me that in the end ideally Marlin should be able to run on all these boards?

If so then I would suggest a different approach. I think right now we have
some developers that have some kind of ARM based board sitting around. They
probably all have different boards, but they are all developers, so they
are probably able to fix the problems with their board or find a work
around.

So all that would be needed is to get these people together to agree an on
HAL API and on which features go into the HAL and which don't. Then
everybody could start implementing their HAL and work together on the
features that are not in the HAL part of Marlin. They can also work
together (and with the other Developers) on getting the AVR boards working
with that HAL API.

I know that this approach sounds a bit chaotic, but I think it very well
matches the Open Hardware/ Open Source way of doing things. I also don't
think that we will have 10 developers with 11 different boards. There will
be people that have the same board that can directly work together.

The additional benefit is that boards that are good available will have a
better chance to land in the hands of a developer. And boards that are
easier to port to or have really cool features will get a working port
sooner. Maybe even some of the board designers will help to get their board
supported sooner.

The HAL layer would also get the full complexity of requirements thrown at
it right at the start. So we either find a really good HAL API or it won't
work. That is probably much better than to start with an API that works on
the one Board and then to have it all the time to get it working on other
boards.

Does that sound like a plan or am I just being stupid?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-252287714,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN4fs9wu_fwO6hBKdY_Axfv17tOMqtNks5qxmlDgaJpZM4Imb5C
.

Sniffle on 7 Oct 2016

You don't really need one board. Start with that you have already. The AVR!
This will need also a HAL-Layer!
Todd Swindoll [email protected] schrieb am Sa. 8. Okt. 2016 um
00:50:

There needs to be a first board that all other boards build off of. Once
that first board is fully supported further boards can be added in easily
just as they are currently added now.

On Oct 7, 2016 10:46 AM, "Lars Pötter" [email protected] wrote:

Is everybody convinced that having a "reference platform for Marlin" is a
must?

I think from the past we can conclude that there will be new board
popping
up all the time. And Marlin always supported many boards. Do you agree
with
me that in the end ideally Marlin should be able to run on all these
boards?

If so then I would suggest a different approach. I think right now we
have
some developers that have some kind of ARM based board sitting around.
They
probably all have different boards, but they are all developers, so they
are probably able to fix the problems with their board or find a work
around.

So all that would be needed is to get these people together to agree an
on
HAL API and on which features go into the HAL and which don't. Then
everybody could start implementing their HAL and work together on the
features that are not in the HAL part of Marlin. They can also work
together (and with the other Developers) on getting the AVR boards
working
with that HAL API.

I know that this approach sounds a bit chaotic, but I think it very well
matches the Open Hardware/ Open Source way of doing things. I also don't
think that we will have 10 developers with 11 different boards. There
will
be people that have the same board that can directly work together.

The additional benefit is that boards that are good available will have a
better chance to land in the hands of a developer. And boards that are
easier to port to or have really cool features will get a working port
sooner. Maybe even some of the board designers will help to get their
board
supported sooner.

The HAL layer would also get the full complexity of requirements thrown
at
it right at the start. So we either find a really good HAL API or it
won't
work. That is probably much better than to start with an API that works
on
the one Board and then to have it all the time to get it working on other
boards.

Does that sound like a plan or am I just being stupid?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-252287714
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAN4fs9wu_fwO6hBKdY_Axfv17tOMqtNks5qxmlDgaJpZM4Imb5C

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-252288785,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AITlJzPQPIuZ8lfwYvt_71rmMooQ1eGwks5qxmo9gaJpZM4Imb5C
.

Wurstnase on 7 Oct 2016

@JustAnother1 I believe we could do it the way you suggest. And it is true we have a few early adopter type developers that have 32-bit boards.

Mostly, I'm trying to plan ahead and minimize chaos for the users. If there is a 'Reference Platform' for the first year that is known to have all the new Marlin features in a fully debugged state, it makes things easier for them. And I guess it makes it easier on the people supporting users too if there is a rock solid 'Reference Platform' to compare against.

As for the HAL, hopefully that discussion and coding goes smoothly. I'm not sure it plays out exactly like this, but even right now we have a few 32-Bit HAL's to look at. If we extract what they have in common, probably it makes sense for us to abstract those same attributes. It maybe we discuss a different way to do it, but if multiple HAL's already abstract something, we are likely to find we need to do that also. Just starting with the common attributes being abstracted will get us pretty far along.

Roxy-3D on 7 Oct 2016

@Roxy-3D Even with all developers just magically having this one first board right now. That wont get you a rock hard 32bit Marlin anytime soon.

I agree with @Wurstnase here. We already have the rock solid reference platform. It is called Atmel AVR.

With already some 32bit HALs out there isn't the next logical step to, as you said, look at them and find the best solution?

With AVR as the reference crazy stuff that is not compatible with AVR could be declined.

Basically we are talking header files here. So implementing an AVR HAL that has all the stuff needed to also support ARM would be a good first step. With that the HALs out there could adopt to support the new API. The API would be tested with AVR and the ARM people could see how far they can go with it.

It would mean that in the next time the AVR is the rock solid "safe choice" and the ARM ports are a bit more risky. But I think the ARM developers will need this time to get their stuff solid. It will also be a competition between the ARM developers. And once in a while a user will try the new stuff and we will see which board will get the most attention. We could have tags for the different HAL implementations on issues. We could also have a Wiki with a table showing which features are already implemented by which HAL on which board.

Letting the developers and users decide on which board they want to use is probably better than having a vote on which board to use.

If you are not convinced then at least add AVR to the table as a valid choice when doing the vote on which board to be the reference.

Designing the HAL API (even if this is only a header file) is a big piece of hard work. We will not get it right the first time. There will be some testing and failing involved. And we need a way so that this can happen without causing everything else to break.

JustAnother1 on 7 Oct 2016

We already have the rock solid reference platform. It is called Atmel AVR.

With already some 32bit HALs out there isn't the next logical step to, as you said, look at them and find the best solution?

With AVR as the reference crazy stuff that is not compatible with AVR could be declined. Basically we are talking header files here. So implementing an AVR HAL that has all the stuff needed to also support ARM would be a good first step. With that the HALs out there could adopt to support the new API. The API would be tested with AVR and the ARM people could see how far they can go with it.

@JustAnother1 I do believe this idea (or approach) has a lot of merit. If one or two people put together a first version that abstracted hardware attributes from the AVR, it would be very natural to use that as the basis for the 32-Bit processors to dove tail in. I'm willing to give it a try. Should we start a new thread to discuss which attributes need to be abstracted to create a AVR HAL and potentially how that code should be organized?

Roxy-3D on 7 Oct 2016

Actually, I already did a HAL version for AVR and Due. As a result of that,
I don't think the AVR version is suitable for a HAL, the extra overhead is
likely to screw things up as the AVR version is finely tuned and really on
the limit. Maybe Marlin-32 should be a separate development from Marlin-AVR.

It really makes sense to start with a single 32 bit platform, preferably
Due based, otherwise the question "this works on mine, does it work on
yours?" becomes impossible to answer with different platforms.

I was waiting to have another go when Marlin reaches another stable version.

On 7 October 2016 at 17:36, Roxy-3D [email protected] wrote:

We already have the rock solid reference platform. It is called Atmel AVR.

With already some 32bit HALs out there isn't the next logical step to, as
you said, look at them and find the best solution?

With AVR as the reference crazy stuff that is not compatible with AVR
could be declined. Basically we are talking header files here. So
implementing an AVR HAL that has all the stuff needed to also support ARM
would be a good first step. With that the HALs out there could adopt to
support the new API. The API would be tested with AVR and the ARM people
could see how far they can go with it.

@JustAnother1 https://github.com/JustAnother1 I do believe this idea
(or approach) has a lot of merit. If one or two people put together a first
version that abstracted hardware attributes from the AVR, it would be very
natural to use that as the basis for the 32-Bit processors to dove tail in.
I'm willing to give it a try. Should we start a new thread to discuss which
attributes need to be abstracted to create a AVR HAL and potentially how
that code should be organized?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-252300153,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VRxkxXmuhkzfIbjaeUuk__z5jAUNcks5qxnUQgaJpZM4Imb5C
.

bobc on 7 Oct 2016

@Roxy-3D thank you for the offer. I'm interested in finding a good solution and would be willing to put effort in it. But right now I'm not the right person to step forward. I watch this from the sidelines. Mostly for two reasons:

I fear that @bobc is right saying "I don't think the AVR version is suitable for a HAL". I don't know any firmware that runs on 8bit and 32bit. So if Marlin would be able to pull something like that off that would be a major break through. I realized how different programming for 8 and 32 bit is only after starting to work on an ARM board. (Having done mostly AVR and 8051 stuff before) I don't say that it is impossible, but it is extremely hard to get this so that both sides are happy with it.
I read a bit of the Marlin code a few years back. And I thought "What a crab" but maybe that is what open source code done by mostly hobbyists and makers and not engineers looks like.
I then looked again just recently and everything was full with C++ classes. I think I understand the reasoning behind this. But I don't feel comfortable with this decision. I'm not sure if the code is now in a better shape than it has been back then. And I don't know if embedded C++ and Arduino as Build system are a good match. But I might be wrong.

Anyway I also think that a Issue does not provide enough space to discuss such a complicated HAL.

I disagree with @bobc on the "single platform" argument. I suspect most Marlin developers don't have all the supported boards available for testing. The reality is that each developer does only very limited tests (only on the hardware he/she has available) but that is the benefit of Open source. Once a user finds a bug with enough engagement of the user and the developer they can figure it out even if the developer has no access to the hardware. The question "this works on mine, does it work on yours?" is what the Marlin community can easily answer. And in the Ideal case it results in "OK I have changes something, does it work now?"

JustAnother1 on 7 Oct 2016

I fear that @bobc is right saying "I don't think the AVR version is suitable for a HAL". I don't know any firmware that runs on 8bit and 32bit. So if Marlin would be able to pull something like that off that would be a major break through. I realized how different programming for 8 and 32 bit is only after starting to work on an ARM board.

Yes. There is truth to this. However, there may be good compromises too. For example, most of the things the AVR touches that are very speed sensitive are done via FastIO. If we go into this HAL effort realizing that we can't slow down the AVR version very much, it is possible the AVR HAL becomes mostly #define's with inline function calls that pre-process into FastIO calls.

I do see a lot of value in getting the AVR version to sit on top of an AVR HAL just because that would keep the bulk of the code base the same between the different versions. The big trick would be to make sure we don't slow down the AVR version in areas that it can't afford it.

And if this is true... Wurstnase's advice is prudent.

You don't really need one board. Start with that you have already. The AVR! This will need also a HAL-Layer!

If we can get most of the hardware access to go through an AVR HAL (maybe just a finely tuned .h file!) we might be able to have the bulk of the code the same up above that layer. (I do still like the idea of a reference platform for the 32-Bit work. But right now, anything that makes progress into the 32-Bit area is very welcome.)

Roxy-3D on 7 Oct 2016

Besides the hardware and the HAL problems there is an other one.
The world of the Arduino IDE is too small.

Pure Make?
Eclipse?
VisualStudio???
PlatformIO?
...

Blue-Marlin on 7 Oct 2016

Dear all,

Some update about the ST 3D Printer board.

1) Regarding the restriction to exportation of the board: The problem is due to the presence on the board of a Wifi component that require CCAT approval before exporting (US law). I agree that this requirement is stupid for export to UE because this board is produced in UE but it is the law. We solved this issue for Farnell and now Farnell will be autorized to export this board to UE. ST will in // will provide Farnell with enough boards to satisfy customers.

2) The schematics, as I've writed previously, can be freely used. I didn't have time to check what we have to do to be compliant with the Open Hardware license. Help is welcome.

3) Marlin firmware. I've succeed to print the ST logo with firmware based on Marlin RC7. So, the first version is ready. I have just to clean my code and after I will push it on GitHub. Give me this week.

4) 3D Printer v2: At beginning of next year, we will design a new board for 3D Printer. It will be an opportunity to add and/or remove some features. Your feedback is welcome on what you need in a 3D Printer controller board. A new thread has been created for this: https://github.com/St3dPrinter/Marlin4ST/issues/3

St3dPrinter on 10 Oct 2016

+1 for Duet Wifi with PanelDue considering I just ordered one to play with :)

adamfilip on 11 Oct 2016

Dear all,

New status regarding the ST 3D Printer board:

1) Availability of the board: Farnell will sell the board in UE. A production is ongoing to provide Farnell with enough stock. This stock will be sent to Farnell at beginning of November and will be available to their customers in middle of November.

2) Board schematics: Available in pdf format. I still have to check how to be compliant with Open Hardware License.

3) Marlin firmware: The new version, based on Marlin 1.1.0-RC7 is now available on GitHub ( https://github.com/St3dPrinter/Marlin4ST) in master branch (v1.1.0). This is a first version that will continue to evolve. In particular these features will be added:

Makefile to avoid utilization of OpenSTM32
Support of LCD
Support of EEPROM

St3dPrinter on 13 Oct 2016

@St3dPrinter Regarding open Hardware. The situation is not clear what _needs_ to be released. But it is very clear that the more you _can_ release the better.
It is essential to have the schematic, to do any development on the board. The Layout would also help. Especially some information how to locate the components is helpful (The schematic says I have to measure at R45, so where is R45 on the board? ).

JustAnother1 on 13 Oct 2016

Thank you for these informations.

Regarding the board layout, you're right. We provided the gerber files but the layout in pdf format is missing. I will put these document on our GitHub.
I'm studying the possibility to provide the schematic in Orcad format. For the moment it is provided only in pdf format (with complete features like search to ease searching a specific component).

Here is the layout with the R45 location :

g70226

And the layout in pdf format:

STEVAL-3DP001V1.pdf

Hope this will help.

St3dPrinter on 14 Oct 2016

Arduino SRL started a contest (but details are unknown).
Arduino STAR OTTO Fall Contest 2016
http://www.arduino.org/foundation/arduino-star-otto-fall-contest-2016

We are inviting makers, designers, developers,and enthusiasts to enter the first phase of our contest.
If you are interested in working on an exciting new platform, submit your information to our contest before the entry deadline, November 30.
We will ship up to 150 Arduino STAR OTTO boards to the most skilled applicants.

esenapaj on 17 Oct 2016

From that link:

Flash memory 2 MB
SRAM 384KB + 16MB ext SDRAM + 128KB EEPROM
Clock Speed 180 MHz

That certainly would give us some headroom!

Roxy-3D on 17 Oct 2016

I found that developer of Teensy made a Marlin for Tennsy 3.1 (About Teensy 3.1: NXP MK20DX256VLH7 32bit ARM Cortex-M4 72MHz).

3D Printer Software with Teensy 3.1
PaulStoffregen/Marlin: Reprap FW with look ahead. SDcard and LCD support. It works on Gen6, Ultimaker, RAMPS and Sanguinololu

esenapaj on 20 Oct 2016

The Teensy is a bit limited in I/O.

I am certain that there is enough talent here that we can make a shield or dedicated all-in-one board that is custom tailored for Marlin. Is there any reason why this hasn't been discussed?

The way that I see it, the existing solutions are all deficient in one way or another. The RAMPS/RADDS boards share common flaws and are both dated designs which haven't seen updates in ages.

So far, my vote is on the ST board since it appears that there is already a working Marlin 1.1.0-RC7 port.

zenmetsu on 20 Oct 2016

I am certain that there is enough talent here that we can make a shield or dedicated all-in-one board that is custom tailored for Marlin. Is there any reason why this hasn't been discussed?

The issue with a custom board is that if you don't want to go the Gen7 way and print your own PCB then it is very expensive to just produce a few boards. To get to an acceptable price point you will need to at least do 1000 boards. If you buy 1000 boards, or know enough people who will buy 1000 boards, that will maybe be able to run a future version of Marlin then let me know and I will tell you where to send your money ;-)

JustAnother1 on 20 Oct 2016

Eh? I have designed my own boards and sent them off before, and you don't need to hit the 1000 board mark, or even the 100 board mark, to do so. Sure, you get volume discounts, but some are willing to pay a premium just to have a better product in their hands. Ram enough desirable features on a board, throw it up on github or hackaday, and you'll have people begging you to send them a board regardless of cost. Been there, done that.

zenmetsu on 20 Oct 2016

@zenmetsu Thats why I said " expensive to just produce a few boards". That is the same as saying "some are willing to pay a premium".
If you "Been there, done that." Then just do it. Just make a board that is better and cheaper than all those already listed in this thread.
If you just want a very expensive board then you can get one of mine: http://forums.reprap.org/read.php?13,524276

JustAnother1 on 20 Oct 2016

If you just want a very expensive board then you can get one of mine:

Very nice board! I left a few comments in that thread!

Roxy-3D on 20 Oct 2016

@JustAnother1 I would, and in fact I have. I have an STM32F429 board here at home that I etched and populated myself, which is fully capable of running a 3D printer. The problem is, I am not good at porting code yet. I have dozens of 32bit development boards, but I have failed miserably to port Marlin to any of them. Trust me, i've tried. I've gotten close. I don't bother posting my issues with porting here because I still consider myself a novice C programmer, and the devs have better things to do than tutor someone like me on how to port code.

zenmetsu on 20 Oct 2016

So far, my vote is on the ST board since it appears that there is already a working Marlin 1.1.0-RC7 port.

This isnt a good enough reason to go with a custom ST Board.
DuetWifi is a really nice platform as well.. why not use that, boards are already available. seems similar to @JustAnother1 board

adamfilip on 20 Oct 2016

The Duet boards, in my opinion, are crippled by the Atmel chip and its lack of an FPU.

The board that @JustAnother1 posted is already superior to the Duet by the simple fact that it is using an STM32F4 series MCU.

zenmetsu on 20 Oct 2016

the board @JustAnother1 posted about looks great, except it doesnt exist yet. So right now its superior perhaps on "paper" but the duet exists and has a decent install base. sure its not perfect but its pretty good.

adamfilip on 21 Oct 2016

@adamfilip the board exists. Prototypes exists. Scroll down in the RepRap thread to see a picture of the board in existence.

JustAnother1 on 21 Oct 2016

@JustAnother1 that board looks a hell of a lot better than mine.. :) I didn't even think to interface the thing to a Pi... That's a pretty slick setup you got going. It is going to be awesome once the code gets to a workable state on the STM32 boards because a lot of us are going to have different designs working.

zenmetsu on 21 Oct 2016

@JustAnother1 you're right of course, sorry what I meant was that it wasn't currently available. what is the timeline like to get final board it in the hands of users

adamfilip on 21 Oct 2016

It may not look like it, but this is a hobby project of mine. I work on it when I have time, when I'm busy it gets delayed. I would be happy to see it available to many people and I do what I can to make that happen.
These first boards are prototypes and a mass produced board would probably need some tweaks. And it will be expensive. So mass production will probably never happen as nobody will be willing to pay the price I fear.
But everything is open and available. So maybe someone wants to help or can base his mass produced board on what I have released.

JustAnother1 on 21 Oct 2016

But everything is open and available. So maybe someone wants to help or can base his mass produced board on what I have released.

Kickstarter?

clefranc on 21 Oct 2016

I too do this as a hobby. As for time to get a board in the hands of others, I'd say it took me maybe 2 weeks to design my board, then had I decided to send it off to be fabricated and populated, the board house that I go through typically takes 2-3 weeks to turn around a board of this size. That nets you a prototype, and most places that I have worked with will make 2-3 prototype boards whenever you make a one-off order like this.

So then, assuming everything works in the first revision and there are no needs for changes, you can give/sell any duplicate boards to those who want to test/develop. To that extent, maybe a month total to get a board into the hands of someone who wants one.

If you need to make changes and run a second rev prototype, you're looking at maybe another 3-4 weeks. Repeat until you get it right.

Now as for selling boards in a production capacity, you have to make some decisions. Does the board need to be tested/certified? If so, certifications like UL are going to cost you a crapload of money. You can save money if you market it as a devkit, but still, you are looking at thousands of dollars. It just becomes too cost prohibitive for us hobbyists, and this is a good reason why you see tons of prototype boards on the internet, with no consumer version as a follow-up.

zenmetsu on 21 Oct 2016

@zenmetsu I have 3 boards made. I'm currently in the step you left out: Bring up the firmware and see if there are "needs for changes". The firmware is here: https://github.com/JustAnother1/pmc

Schematics are in the RepRap post. If someone wants to help, that would be appreciated.

@clefranc Or crowd Supply, or Indigogo, .. I know. Problem is it has to work first. I'm not there yet.

Oh and the baseboard as well as the Stepper boards are 4 Layer. If you then add the cost of the components STM32F405, Trinamic TMC260 and all the Mosfets, Caps, connectors. You might get an impression of the price point,..

JustAnother1 on 21 Oct 2016

@JustAnother1 Yes, I did leave that step out, mainly because that is where I am at.

I have a test firmware which just lets me test I/O, whether digital on/off, pwm, or analog... as well as testing of all peripherals, both on-chip as well as on-board. So far, I'm good on that front, with the first revision no less. The problem, however, is getting Marlin to run on it. I'm just not that good at coding. Once there is a functional stm32 port of the code, I'll probably have a simple task ahead of me.

And yes, the 4-layer boards are a killer when it comes to cost... especially when you have high-current requirements which end up taking a good chunk of real estate. :D

zenmetsu on 21 Oct 2016

Your Duet info is outdated. The 0.6 and 0.8.5 are as described above but the new Duet Wifi has most all of what people said they wanted.

WZ9V on 21 Oct 2016

Alas, I stand corrected. It looks like they updated the Wifi version to the SAM4E8E.

zenmetsu on 21 Oct 2016

But the Duet Wifi does have a Cortex M4 with FPU... as I suggested way back.

Anyone else feel like they are trapped in a never ending loop?

On 20 October 2016 at 21:53, Jason Westervelt [email protected]
wrote:

The Duet boards, in my opinion, are crippled by the Atmel chip and its
lack of an FPU.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-255224961,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR8W5xPO1irIpG_arfCPXTYBLBMa7ks5q19S3gaJpZM4Imb5C
.

bobc on 25 Oct 2016

Duet Wifi FTW! LOL

So what are the objections to starting with this board?

adamfilip on 25 Oct 2016

Let's shift gears... Let's assume Duet Wifi makes sense. Is there any reason to NOT use this as the 'Reference Platform' ??? It looks like it would:

Be sufficient to drive a basic 3D-Printer
It has plenty of RAM and Program space for our needs
It has plenty of CPU speed and a floating point processor
With some 'Minimal Work' it can be used with the Ardiuno IDE

The one downside is cost. But the cost right now is not crazy, and people are going to start cloning that board and doing knock-off designs. Especially if both Marlin and RepRapFirmware support it.

Let's shift to a final 'Sanity Check Mode' where we hear and discuss all problems with the Duet Wifi board as a platform before we put it to a vote.

Roxy-3D on 25 Oct 2016

👍2

One thing that I haven't been able to find regarding the Duet WiFi is the schematic. I have found the schematic for the non-WiFi board.

zenmetsu on 26 Oct 2016

@Roxy-3D

It can be used with the Ardiuno IDE

No, it can't. Currently, Arduino IDE doesn't support Atmel SAM4E8E(ARM Cortex-M4).
If you 'd like to use Duet Wifi with Arduino IDE, you need to meke a additional library like a Arduino STM32.

Especially if both Marlin and Smoothieware support it.

No, it doesn't... Currently, Duet Wifi works with RepRapFirmware. not a Smoothieware.

esenapaj on 26 Oct 2016

👍1

Especially if both Marlin and Smoothieware support it.

No, it doesn't... Currently, Duet Wifi works with RepRapFirmware. not a Smoothieware.

Oh! My mistake. I was looking at the table you generated in this comment. And I saw the Smoothieware highlighted for the board above it: (AZSMZ Mini)

https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-252179314

But as you say RepRapFirmware runs on it. So that combined with Marlin will still be a big user base to insure the board gets used and doesn't just vanish.

It can be used with the Ardiuno IDE

No, it can't. Currently, Arduino IDE doesn't support Atmel SAM4E8E(ARM Cortex-M4).
If you 'd like to use Duet Wifi with Arduino IDE, you need to meke a additional library like a Arduino STM32.

Bobc said:

That basically means SAM3X (Arduino Due), or maybe one of https://github.com/arduino/Arduino/wiki/Unofficial-list-of-3rd-party-boards-support-urls
Duet/DuetWifi would take a minimal amount of work to make into a downloadable Arduino core package (even if they are not officially supported by Arduino).

What is 'minimal amount of work' ? Are these .bin files what you are talking about?

https://github.com/dc42/RepRapFirmware/tree/dev/Release/Duet-WiFi

Roxy-3D on 26 Oct 2016

@zenmetsu

Wiring Diagram
https://duet3d.com/wiki/Duet_WiFi_wiring_diagrams

Schematics
https://duet3d.com/wiki/Source_Files

adamfilip on 26 Oct 2016

Source files for Duet Wifi are at
https://github.com/T3P3/Duet/tree/master/DuetWifiv1.0 and there is also a
schematic in PDF.

On 26 October 2016 at 09:41, Jason Westervelt [email protected]
wrote:

One thing that I haven't been able to find regarding the Duet WiFi is the
schematic. I have found the schematic for the non-WiFi board.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-256285019,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR3aBUI0MbvFHzVUzZfh1zAghJ2L5ks5q3xJAgaJpZM4Imb5C
.

bobc on 26 Oct 2016

Source files:
https://github.com/T3P3/Duet

On Oct 26, 2016 5:03 AM, "esenapaj" [email protected] wrote:

@Roxy-3D https://github.com/Roxy-3D

It can be used with the Ardiuno IDE

No, it isn't. Currently, Arduino IDE doesn't support Atmel SAM4E8E(ARM
Cortex-M4).
If you 'd like to use Duet Wifi with Arduino IDE, you need to meke a additional
library http://playground.arduino.cc/Main/CustomizeArduinoIDE like a Arduino
STM32 https://github.com/rogerclarkmelbourne/Arduino_STM32.

Especially if both Marlin and Smoothieware support it.

No, it isn't... Currently, Duet Wifi works with RepRapFirmware
https://github.com/dc42/RepRapFirmware. not a Smoothieware
https://github.com/Smoothieware/Smoothieware.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-256303459,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN4fgsUfixAIfZ31EqUiRwDii7TKKJaks5q3yVlgaJpZM4Imb5C
.

Sniffle on 26 Oct 2016

@Roxy-3D I added the package files required for Arduino IDE for the Duet board, https://github.com/bobc/coreduet, so you can compile sketches in Arduino IDE and run them on Duet. The download requires a manual sequence to get the Duet into its bootloader.

The package files are a couple of text files and a JSON file. There may also need to be some small changes to the source code. I also got some way into porting Marlin to Duet.

To support Duet Wifi, we need to add the package files to the "CoreNG" repo which supports Duet and Duet Wifi.

bobc on 26 Oct 2016

👍2

Oh, that's a pity. I just went to order a Duet Wifi and now they are out of stock on our side of the pond! More in November it says.

bobc on 26 Oct 2016

Oh, that's a pity. I just went to order a Duet Wifi and now they are out of stock on our side of the pond! More in November it says.

Nothing is ever easy...

Roxy-3D on 26 Oct 2016

😄1

And what about the debugging feature, wasn't it important for developers?

clefranc on 26 Oct 2016

Ugh... same problem with DuetWifi as RAMPS... no current protection on the endstops and probe connectors. This was a common failure mode on the RAMPS boards.

On the Duet WiFi, 3.3V is taken from the VR which can source, at most, 500mA. The TC2117 has overcurrent protection, but if I recall properly it will not be protected in the event of a hard short to ground due to improper endstop hookup. Probably worth mentioning that putting a resistor in line series with your endstop switches would be prudent.

Otherwise, the board appears to be a pretty solid contender. Lack of Arduino IDE support isn't the end of the world. :D

zenmetsu on 27 Oct 2016

👍1

Otherwise, the board appears to be a pretty solid contender. Lack of Arduino IDE support isn't the end of the world. :D

Of course I can't speak for Bobc. But my guess is he can get Arduino support in place faster than we can get our developers organized.

Roxy-3D on 27 Oct 2016

get our developers organized

All it takes is one determined soul!

thinkyhead on 27 Oct 2016

👍1

@clefranc The DuetWifi has a footprint for a JTAG connector, but a connector needs soldering. Then I use an Eclipse set up with a Segger JLINK for debugging on Duet, same should work for Duet Wifi.

bobc on 27 Oct 2016

@bobc That narrows the final choice even further.

clefranc on 27 Oct 2016

https://www.kickstarter.com/projects/1204283/zeropi-arduino-and-raspberry-pi-compatible-develop

fiveangle on 1 Nov 2016

_blech_ everything Zeropi seems a ghost town: https://github.com/ZeroPiProject

:(

fiveangle on 1 Nov 2016

That is very unfortunate.
It says "Estimated Delivery: December 2015"
Otherwise, I would order one with a debugger!

Roxy-3D on 1 Nov 2016

December 2015

People have received their ZeroPis and have been reporting their experiences in various fora since late 2015. Here's their user guide.

thinkyhead on 1 Nov 2016

Is the ZeroPi for sale? I can find a lot of ZeroPi stuff, and even images. But not any web sites dedicated to it and talking about prices. And on the GitHub Project page it shows them plugging it into a Raspberry Pi. ( bottom of page: https://github.com/ZeroPiProject/ZeroPi_lib )

In that scenario, there would be two 32-Bit processors in the system!

Roxy-3D on 1 Nov 2016

I'd inquire with the Kickstarter. Perhaps the order links on the Kickstarter page are still working.

Meanwhile, I've started a branch so we can see the differences that apply to the Atmega SAM D3.

https://github.com/MarlinFirmware/Marlin/tree/arch_samd_support

thinkyhead on 1 Nov 2016

The ZeroPi appears to be a one-off Kickstarter project, it is no longer on
sale. There is a schematic published but no other design files. Would be a
nice Open Source design project for someone?

The SAM D3 is a Cortex M0, they are really quite slow as ARM chips go. They
are basically a low cost option to capture market share from 8 bit CPUs.

On 1 November 2016 at 18:15, Scott Lahteine [email protected]
wrote:

I'd inquire with the Kickstarter. Perhaps the order links on the
Kickstarter page are still working.

Meanwhile, I've started a branch so we can see the differences that apply
to the Atmega SAM D3.

https://github.com/MarlinFirmware/Marlin/tree/arch_samd_support

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-257647178,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR83mHiCOHrHlu3_fwXj-ddLFz37nks5q54GkgaJpZM4Imb5C
.

bobc on 1 Nov 2016

I notice that the MarlinKimbra 4 Due branch is separate from the MarlinKimbra for AVR branch. I wonder, when we go forward with DUE support whether we will also need to keep the branches separate, or if it's relatively easy to unify them…?

thinkyhead on 2 Nov 2016

I notice that the MarlinKimbra 4 Due branch is separate from the MarlinKimbra for AVR branch. I wonder, when we go forward with DUE support whether we will also need to keep the branches separate, or if it's relatively easy to unify them…?

My hope would be that our HAL's are sophisticated enough we can make some minor tweaks to the code to get it to use the HAL, and then we just have one code base. At least, that would be my vote and I think it is worth some effort to try to make that the case.

Roxy-3D on 2 Nov 2016

Up to now the only branch integrating AVR and DUE, i have seen, is https://github.com/esenapaj/Marlin/tree/Duo. The integration is not a beauty, but at least there is an integration - and it's relative up to date.
Thanks @esenapaj

Blue-Marlin on 2 Nov 2016

About MarlinKimbra and MarlinKimbra4due, updating of those were stopped, and those were united to MK4duo.

About Repetier-Firmware, source folder for AVR and Due are being separated.
But when you compare those files, you realize that those files are completely same except HAL.*, fastio.h, Makefile, and pins.h.
It means that folders are being separated, but sources of AVR and Due are being united.

In case of separated source:
・pros
Implementation is freed from any restrictions of 8bit AVR, it enable a thorough optimizing for 32bit ARM (or other) architecture.
Performance of AVR will keep up because HAL isn't introduced.

・cons
It increase a time for the management of sources. Development team of Marlin will have to be managed two or more separated sources or separated projects.

In case of united source:
・pros
Source is easier to manage than separated source.

・cons
There is a possibility that optimizing for 32bit is inhibited by restrictions of 8bit AVR architecture.
It has risk that performance of AVR is deceased by overhead of HAL.

esenapaj on 3 Nov 2016

In my opinion, I'd like to recommend a united source.
Because working resources of development team of Marlin is extremely limited at this time.
If SAM3E4E fork forked from original (8bit) source, it will become different from the original as time passes.
In addition if STM32F401VE fork forked from original, it will become different from the original as time passes, too.
If one person have to be managed those different sources every architecture, It seems that it likes a hell.

About risk of deceasing performance of AVR by overhead of HAL, it's problem certainly, but it seems that HAL for AVR isn't impossible.
Because Repetier-Firmware fulfilled it.

esenapaj on 3 Nov 2016

👍1

What does separated sources mean?

My first impression was that separated sources means that there will be one set of files for the AVR version and another set of files for the ARM version.

The last post implies that there will be separate sets of files for each and every different processor, or even each board-processor combination.

I think that separate sources for each processor/processor-board will be too much overhead and therefore impossible to maintain.

One source tree for AVR and another for ARM with a HAL in the ARM part and therefore the ARM part supporting all processors (SAM3E4E and STM32F401VE and others) is probably the easiest way. The HAL overhead doesn't hurt on the ARM chips.

Having a united source and therefore a HAL for all ARMs and the AVR will make the HAL very tricky. One always has to choose between supporting new shiny features that use the ARM peripherals to their max against being able to have these features also on AVR.

A solution might be to allow for ARM only features. The risk with that approach is that the AVR firmware stops as all new features become ARM only.

JustAnother1 on 3 Nov 2016

What does separated sources mean?

I assumed that

there will be separate sets of files for each and every different processor

, but probably united source for all the 32bit ARM architectures is possible as you say.
But even if in that case, source is separated to two (for AVR and for ARM), and development team of Marlin will have to manage two separated sources.

About pros and cons of dual-source, I think so too as you say.

esenapaj on 3 Nov 2016

About risk of deceasing performance of AVR by overhead of HAL, it's problem certainly, but it seems that HAL for AVR isn't impossible. Because Repetier-Firmware fulfilled it.

I haven't looked at it deeply enough to know for sure... But my initial thinking on the subject is this:

We should try very hard not to hurt the performance of the AVR processors.
We might be able to turn any code that touches the hardware on the AVR processors into a macro. We probably can do this at 100% efficiency such that the AVR's do not get any performance penalty.
We then try to implement ARM versions of those macros. It doesn't matter if the macros generate code that takes a few more cycles than what it could be done in a fully targeted implementation. The ARM processors are running the rest of the code at a 4x (minimum) speed increase.
If we proceed as much as possible along this line of thinking, we may be able to keep everything but the HAL 100% the same. (I know it won't play out this way... But for the sake of discussion... I think this is a valid goal!)

Roxy-3D on 3 Nov 2016

turn any code that touches the hardware on the AVR processors into a macro

This is more-or-less what that ZeroPi code is doing, if you've had a look at the branch I made yesterday. It replaces some of the fastio.h stuff with its own. I'll have to take a look at that Duo branch to see another approach.

may be able to keep everything but the HAL 100% the same

I think so. We should continue to make static class wrappers for the existing codebase, split up the code into smaller units, and so on, because that will help to reveal patterns and guide us towards a better overall architecture. The code should continue to be lean where it matters (planner, stepper), whereas we can be more "class-oriented" with the menu system and the majority of GCodes. We should aim to group what we can into sub-systems, piece-by-piece. Grouping all the SD-related code together, for example, would be a worthwhile exercise.

thinkyhead on 3 Nov 2016

Hi all,

Check out this 32 bit controller, supposed to be a drop in for the ramps 1.4
https://www.kickstarter.com/projects/1245051645/re-arm-for-ramps-simple-32-bit-upgrade/description

They are currently advertising as supported by Smoothieware.
Maybe this is an opportunity to have Marlin supported on Smoothieware hardware and derivatives.

psavva on 11 Nov 2016

👍1

@psavva I think that board shows a lot of promise, and hits all the buttons except for a debug connector. I have not used Panucatt kit but they seem to have a decent rep. I have pledged for a December delivery board.

bobc on 12 Nov 2016

I have also pledged for the December board.
I will also help towards the 32bit support development.

Let's reach out to the campaign owners, and ask if they are able to donate some boards to the Marlin Development Team.

psavva on 12 Nov 2016

and hits all the buttons except for a debug connector.

Supposedly, the December delivery will be using the FIRST batch of boards:

$43 Re-ARM December 2016 Delivery - This is for one Re-ARM board on the FIRST batch with estimated delivery of December 2016 (In time for that holiday vacation!!).

@bobc The 'Debug Connector' just goes to specific pins on the processor chip, right? Is it possible the pins we need for that can be wired up with stray wires? Do you know which pins we need brought out to a connector?

Let's reach out to the campaign owners, and ask if they are able to donate some boards to the Marlin Development Team.

@psavva If we are going to 'Reach Out', let's also request they bring out the 'Debug Connector' signals on the next turn of the board. They don't have to solder a connector in. But if they could just put the pads down (in a reasonable location) for people that do need a connector, that would be really good!

@psavva Are you willing to do the 'Reach Out' ? This is a very small start up operation so it probably will be difficult to get 8 or 10 boards. But please make sure they know that if the Marlin developers have 4 or 5 boards we will get Marlin up ASAP and they can add that to their list of 'Support Software'.

Roxy-3D on 12 Nov 2016

@Roxy-3D There are basically 5 signals, ground, +3V and Reset are easy, SWDIO and SWCLK need soldering direct to CPU pins, which needs some fine soldering. Here's how I did it for Smoothieboard:

I glued connector to top of CPU.

bobc on 13 Nov 2016

@Roxy-3D, I have reached out :)
Let's wait for Roy Cortes (Re-ARM) to come back to us.

psavva on 13 Nov 2016

Here's how I did it for Smoothieboard:

@bobc If I had a picture of one of these boards done like that, I think I could get a debug connector on it! (I would rather have solder pads, but if it got us hardware with debug support, I'm 100% On-Board!)

At this link:

It says this: http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf

8.31 Emulation and debugging
Debug and trace functions are integrated into the ARM Cortex-M3. Serial wire debug and
trace functions are supported in addition to a standard JTAG debug and parallel trace
functions. The ARM Cortex-M3 is configured to support up to eight breakpoints and four
watch points.

Roxy-3D on 13 Nov 2016

Regarding the Re-ARM, i'm not familiar with smoothieware, why does there need to be a second micro SD slot for cofiguration settings? Surely the ARM has enough EEPROM storage to configure settings, and general settings should be in the firmware SD card.
Again I don't understand why Smoothieware uses an external SD card for firmware, maybe I don't understand the mechanism.
From a Marlin perspective, I guess that a JTAG breakout would enable much more effective flashing. And use the on-board micro SD card for external storage for prints, thereby eliminating the need for an SD card slot on displays.
Ideally the second SPI port should be set up for communicating to an on-board USB controller, enabling flash drives to be used.

Just leave me an SPI port for connecting a thermocouple MAX31855, and i'll be happy

Grogyan on 15 Nov 2016

@Grogyan If you look at the data sheet of the Re-Arm or the used Soc you will see that is has no EEPROM at all.
Smothieware uses a text file for configuration. This allows the user to change the settings with a simple text editor. Then put that SD card in the board an go. So no Firmware Flashing necessary for simple parameter changes.
The ARM chips also have USB so using a SPI to connect to an external USB makes no sense. (Maybe I got you wrong there.)
The biggest benefit IMHO of the JTAG interface is not flashing but debugging!

JustAnother1 on 15 Nov 2016

@JustAnother1 Cheers, just reading through the datasheet.
By Another USB, I mean to have the option for a USB thumb drive to be used. Something that I see has been a snagging point for many transferring gcodes manually with an SD card, instead of using a hot swappable device like a flash drive.

Grogyan on 15 Nov 2016

@Grogyan You don't need a second USB to be able to do thumb drive (USB Mass storage). All chips have at least a OTG Port. Meaning it can act as client (PC connected to board by USB) and Host (Thumb Drive). So it is just a matter of good firmware and smart Board Schematics.

Smoothie does Mass storage also in client mode. It presents the SD cards as thumb drive to the PC. So if you don't want to handle the SD card, you can upload G-Codes and configuration that way. Or use the printer as (very expensive) SD Card reader ;-)

JustAnother1 on 15 Nov 2016

Cheers, You might want to consider our ARM4RAMPS LPC1769 based direct replacement for Mega2560 board. JTAG and ISP available. LAN and ESP8266 integrated. 5V tolerant, high speed buffers.
https://github.com/elaboratecircuits/ARM4RAMPS

And our new RAMPS derivative with logic level SMD MOSFETS, integrated smart display connectors, dual pwm FAN support.
https://github.com/elaboratecircuits/EC_RAMPS

elaboratecircuits on 16 Nov 2016

🎉1

@elaboratecircuits

Is the EC-RAMPS board designed 'Fail Safe' such that if the processor doesn't come up, the heaters are not turned on?

Roxy-3D on 16 Nov 2016

Another potentialy interesting board is MKS Robin from MakerBase its based on STM32F4

https://github.com/makerbase-mks/MKS-Robin

And its available via aliexpress

alexxy on 18 Nov 2016

There will always be a new chipset, or a new board that was just announced or a update coming around the corner, or a kickstarter with a cool new controller. How will this selection process ever be settled. who is going to make the executive decision?

adamfilip on 18 Nov 2016

It would be nice if the people with the knowledge and skill set could come to an agreement. But it doesn't feel like that is going to happen. There seems to be too many polarizing topics.

There are a couple of ways it can get resolved. One way would be for a company (or Kick Starter project) to say: "Here are 6 or 8 boards for developers that can help bring up and test a 32-Bit version of Marlin." That would be a Win-Win deal. The party donating the boards would get Marlin support on their 32-Bit Platform. And Marlin would have an entry point into the 32-Bit side of the world.

Assuming that doesn't happen, it is very possible that a highly motivated individual with a 32-Bit board will bring up RC-7 and say "We can close this thread, RC-7 (or RC-8) is up and running on the 32-Bit board set I have." And the rest of us can Dog Pile onto that board set.

In either case, once something is up and running, it is very easy to envision other people saying "What about this or that 32-Bit platform?" My guess is the support for other board sets will fan out very quickly if RC-7 is working on something.

Some of the early adopters have already brought up 32-Bit versions of the older Marlin code bases. We just need that to happen again except with RC-7 (or RC-8).

Roxy-3D on 18 Nov 2016

👍1

@Roxy-3D Yes, the EC_RAMPS board is designed "fail safe", and planning to make it more fail safe. making an intelligent PSU adapter to EC_RAMPS board (and compatible with any RAMPS of course).

I’d happily invest in the effort porting Marlin to 32bits. The boards I am proposing are about this. And I am ready to donate boards to developers. I do have quite serious production facilities (SMT+PTH) so I can be agile and design on specs.

elaboratecircuits on 18 Nov 2016

🎉2

I would be happy to donate $50 to a pot, so we can hire a developer willing to dedicate time to port marlin to 32bit and buy them a board. that the Marlin Development team has selected.

anyone else willing to chip in?

adamfilip on 18 Nov 2016

I guess all interested should look at
https://docs.google.com/spreadsheets/d/1YHvs5xxan2gO7NOX-_D04EB-NCUBVvKPKLbIFVuyzEI/edit?usp=sharing
and make sure it is updated, then we could have a vote or something...

Looking at the list, there are 3 main chips used, so we should target those.

On the MKS-Robin, there isn't enough info and what there is in Chinese.

The Re-Arm is my favourite so far, considering all factors.

bobc on 18 Nov 2016

Yes please everyone check the google doc.. make sure we have all available options. I will create a online survey for everyone to vote on. Once done the Marlin Dev team can make a decision (i hope) lol

adamfilip on 18 Nov 2016

Forget to mention, there is an Arduino package for LPC1768 from Explore-M3
which should make porting to that chip a lot easier.
https://github.com/ExploreEmbedded/Explore-M3

bobc on 18 Nov 2016

We would be happy to send Archim boards and work towards porting from our
branch if we knew it would be accepted and maintained.

Johnny Russell
UltiMachine

johnnyr on 18 Nov 2016

Have you ever thought about using an RTOS like FreeRTOS?

alexborro on 18 Nov 2016

@johnnyr @elaboratecircuits @St3dPrinter And any other 32-Bit hardware maker:

If you can donate viable 32-Bit hardware: Please speak up and tell us what is possible! That will help us stretch @adamfilip effort to get the current Marlin code base up an running a 32-Bit platform!!!

Roxy-3D on 19 Nov 2016

Have you ever thought about using an RTOS like FreeRTOS?

@alexborro I think a lot of us see merit to doing this. Probably what makes sense is to get Marlin up and running on a 32-Bit platform first. And then slip a RTOS under Marlin (as one big task) and get that stable and working correctly. At that point, it probably would be fairly tame to start identifying different threads that can be separated from the main Marlin body one at a time.

There are a number of very obvious tasks that could be broken out:

the temperature control would be a likely candidate.
with more processing power it won't be as big of a deal but having a separate (low priority) task to update the LCD Panel would helps us a lot right now on the 8-Bit AVR's.
a task to buffer GCode commands might make sense.
watch dog functionality
etc.

Roxy-3D on 19 Nov 2016

@Roxy-3D I am confused:

with more processing power it won't be as big of a deal but having a separate (low priority) task to update the LCD Panel would helps us a lot right now on the 8-Bit AVR's.

The high performance of the ARM allows for a separate Task for LCD update. So Far I understand it.
And then you probably say that a separate task for LCD would help resolve issues or increase maintainability (you are not clear there) for AVR

But how do you get the more performance into the AVR ? Or if the separate tasks also work on low performance AVR then why not just implement them anyway, why the need for 32bit?

Then just in case people are not aware. If a HAL is introduced (What was suggested here) then development for everything but the HAL is possible without access to Hardware.

Maybe a second spreadsheet is in need to list the developers that want to work on the 32bit Marlin. That spreadsheet could then list the 32bit boards these peoples have and what they need. Would that be a way to move forward?

JustAnother1 on 19 Nov 2016

@JustAnother1 I probably wasn't clear. What I meant to say is it would be very helpful in today's AVR code base if we could kick off a very low priority thread to manage the LCD Panel. That way, we would not be burning CPU cycles if something else more important was happening.

And conversely... If nothing else more important needs CPU cycles, it would be nice to have the LCD Panel updated constantly so there is no lag in what it displays. But obviously, we don't have an RTOS to do that in today's Marlin.

Roxy-3D on 19 Nov 2016

@Roxy-3D That is what I understood. The question is why don't you do it? For what I think the answer is that the AVR has not enough performance to do such a thing.

If that is true then doing such a thing on the 32bit ARM - Marlin would only split the code base into AVR and ARM. As that is nothing that could be done in the HAL only. Is that what you suggest?

JustAnother1 on 19 Nov 2016

Well... I'm not sure what the future holds. It would be good to keep one code base with the only difference being the HAL for a given processor.

The reason I'm hedging is I have a hunch 5 years from now, nobody is going to be using AVR based boards. That could even happen within 2 years.

The point being, when that does happen, does it make sense to expend lots of effort to keep the two code bases the same? It might be better to just freeze the AVR code base and say "It is what it is..."

The question is why don't you do it? For what I think the answer is that the AVR has not enough performance to do such a thing.

I actually think putting an RTOS under the current Marlin on AVR's would give us back a bunch of CPU cycles. The LCD Panel update is very expensive and consumes a bunch of CPU cycles. If it was its own low priority task, we don't even need to ever call it. It just runs when there are free cycles.

But the interrupt structure of the AVR is kind of lame. The interrupts don't nest.

Roxy-3D on 19 Nov 2016

@Roxy-3D I also can't tell the future (at least not now, ask again in the future ;-)
But I would put your question differently.
We seem to agree that having ARM and AVR in one firmware is hard.
So if the Future is full of AVR Boards, then why have a 32bit Marlin crippling the AVR version?
If the Future is full of ARM boards, why carry the old AVR stuff along ?

Marlin is not a company. We do not need to do everything it needs to stay in business. So just having the best Marlin there can be for AVRs, ignoring everything ARM,is an option.

Starting completely new for a ARM firmware is also an option. This option is called Smoothieware ? Or what would a Marlin-32-ARM do better than smoothie?

Or do we need to have this one firmware to rule them all (AVR + ARM) ? Why?

I don't know it. But I'm not a Marlin core developer. But I think we need to be clear on this before talking about who gets which board. Or am I wrong?

JustAnother1 on 19 Nov 2016

It is hard to look far into the future. But for the near term (next 2 years???) I think as much as possible we have one code base. I think this happens for one main reason. The fact is, right now, 99% of the users have AVR boards. It will take time for that to shift.

So right now, the big question to resolve is this: Is it possible to have one code base to support both platforms? If everybody can get comfortable with an affirmative answer to that question, we can wait years to resolve the question of when to abandon support for the AVR based platforms.

Roxy-3D on 19 Nov 2016

Happy to transfer ownership to @roxy or another marlin developer if it will add confidence.
I have no ill intentions. every penny available will go to help this team.

There is no need for that! If anybody has questions, they can join this thread. Adam is trying to help the effort. I have full confidence any donation is going to be 110% beneficial to the cause!

And in fact... I think I would argue the current setup helps guarantee that. I'm just making stuff up with this example, but suppose a hardware vendor with a suitable board set says "We can't outright donate 8 board sets. But we can give them to you for 35% of the retail price." It would be Adam's call if the money is well spent. And Adam has a very good handle on what the development issues are and where it would make sense to place the boards. And remember... It isn't just about getting the code moved to the 32-Bit platform. We do need people actively testing all the corner cases too!

Roxy-3D on 19 Nov 2016

👍1

low priority thread to manage the LCD Panel

Is that technically possible? I thought AVR interrupts cannot interrupt other AVR interrupts. So having the (very long) graphical LCD update block the stepper ISR would be very bad. Also, the main problem with the (graphical) LCD update is that it blocks the planner (well, the main thread generally) for too long, resulting in a starved buffer. That would be just as true if it were in an interrupt. We also don't know if the U8glib is interrupt-safe.

The one potential advantage of updating the graphical display in an interrupt is that it could perhaps be split up a bit more, giving extra opportunity for the GCode parser and planner to do their thing.

thinkyhead on 19 Nov 2016

I thought AVR interrupts could interrupt other AVR interrupts.

Did you mean to say "AVR interrupts can NOT interrupt other interrupts!" ???? I'm guessing what you said was a typo. (I haven't checked... But I was under the impression AVR interrupts can not interrupt each other. They all run to completion before another interrupt can be serviced.) Even so... It would be more difficult, but an RTOS can still be put on the AVR processors. It would not be as elegant or clean or efficient. But for sure... The AVR processors can have an RTOS!

and the main problem with the (graphical) LCD update is that it blocks the planner for too long, resulting in a starved buffer.

Yes. And in a typical RTOS, what would happen is the LCD Update task would be very low priority task. If no work is available (because the serial buffer task has filled up the command queue and every other task is just waiting for an interrupt to say something has to be done), it would run.

But if there was anything more important... The LCD Update task is suspended (automatically) and just waits until there are free cycles to be spent there. The way the LCD Task would get suspended is some interrupt would fire and wake up the task that needs to deal with what ever happened.

The problem with the AVR's interrupt structure is the interrupts do not nest. Very typically, interrupts are used to "wake up" high priority tasks. But because the interrupts do not nest, a higher priority interrupt has to wait until the lower priority interrupt runs to completion. That is kind of a philosophical disconnect to what RTOS's are supposed to do. (You have a high priority interrupt... But you are ignoring it until the low priority interrupt finishes. That is not 100% consistent with a 'True' RTOS philosophy!) However, it doesn't stop an RTOS from being put on the AVR. It just means it isn't 100% pure. Low priority interrupts get to run (if they fired first) even if a higher priority interrupt needs CPU cycles.

Admittedly, this is beating a dead horse. But in a typical RTOS, any interrupt is higher priority than any task. So the fact that a lower priority interrupt can finish before a higher priority interrupt can run is kind of a moot point. Both of the interrupts will end up waking up some task. The RTOS will resolve that and the higher priority task will run first with just a slight delay. It isn't 100% pure. But for sure, it would be better than what we have now.

PS. This wasn't available at the time of the original post:

So having the (very long) graphical LCD update block the stepper ISR would be very bad.

Yes. But it doesn't play out that way. Remember... This is probably not 100% true, but it is 99.5% true. In any RTOS I know about this statement is true:

in a typical RTOS, any interrupt is higher priority than any task.

What would happen is the low priority LCD Update task might be running because nothing else needs CPU cycles. An interrupt fires because something happens. Part of the interrupt routine would do something that wakes up a suspended (higher priority) task. It might send a message to an important task. It might release a mutex. It doesn't matter. When the interrupt service routine exits, the RTOS jumps in and makes a decision about what task gets to run. The interrupt service routine (in an RTOS environment) does not return directly to what was running. The RTOS gets to arbitrate things. And the RTOS will schedule and run what ever is the highest priority task that needs CPU cycles.

We also don't know if the U8glib is interrupt-safe.

All interrupts are going to save registers. We already have interrupts firing while U8glib is doing its thing. We wouldn't be sending any 'messages' to U8glib. Only to the LCD Task that uses U8glib. And the RTOS would sit in the middle of that and arbitrate all that. The LCD Task can ask the RTOS for the messages in the queue. But U8glib would not even know there was an RTOS scheduling its CPU cycles. And in fact... It could be argued that the LCD Task never receives any messages and doesn't block on any mutex's. It just runs if there are CPU cycles available. In that case... it can get suspended (because an interrupt happens and schedules a higher priority task) but it doesn't even know that happened.

In that scenario, the one thing the LCD Task (and U8glib) could know is this: If it is running... Nothing else more important is happening on the printer.

Roxy-3D on 19 Nov 2016

I've been following this since since it was linked from the Re-Arm Kickstarter comments section. Sadly it seems that Roy is unwilling to accept backer suggestions or requests. I started looking around for other options and I may have found something that hasn't been considered. Seeed Studio has an open source ARM/Mega footprint board for $39. It seems to tick many of the request above. and a ramps board should drop on. https://www.seeedstudio.com/Arch-Max-v1.1-p-2632.html. Thought I might suggest it. My apologies if for some reason this board is incompatible. My knowledge of Arm products is minimal.
-Edit- More board information https://seeeddoc.github.io/Arch_Max_v1.1/

DirtyEngineer on 19 Nov 2016

and a ramps board should drop on.

@DirtyEngineer I am very encouraged so many 32-Bit platforms are starting to show up. I read everything on the page and all links it pointed to. I don't know that what I'm thinking is correct. But I see two problems:

First, it would be nice if it was supported in Arduino. That will lets us keep one main code base for the next couple of years. But the other problem is RAMPS isn't 'Fail Safe' with an ARM processor. The GPIO signals reset to the opposite state of an AVR and what will happen is if the processor does not come up, or Marlin is sick, the heaters will all come on full bore. They will start fires. That might be OK for the developers, but that can't be a 'Reference Platform' that a user puts on their dining room table with a table cloth!

PS. I like your icon !!!

Roxy-3D on 19 Nov 2016

@Roxy-3D I corrected that typo immediately. You must be a fast reader!

the LCD Update task would be very low priority task

As it now is. But, the update itself takes up a lot of time. It's not how often it's called, but that it blocks the main thread (idle()) for a long duration.

thinkyhead on 19 Nov 2016

You must be a fast reader!

No... I don't have a life. I'm watching Blind Spot and my laptop lit up with a new message on the thread!

Roxy-3D on 19 Nov 2016

😄1

task is suspended

Ah… I wonder how it manages all that fanciness. Real threads?

No... I don't have a life.

Tell me about it. I've been in Austin for months working for MakerArm, and the isolation is killing me. Fortunately (or not) on December 3rd I'll be moving into a place in Austin with a friend and one other guy, and will at least have human interaction in my off time. Maybe I should take up darts?

Sorry to clutter the thread. I'll delete the off-topic messages pretty soon.....

thinkyhead on 19 Nov 2016

task is suspended

Ah… I wonder how it manages all that fanciness. Real threads?

Yes. It is real easy. No interrupt goes straight to the interrupt handler. Everything funnels through the RTOS. So when the ISR finishes and returns... It goes back up into the RTOS. And the RTOS checks to make sure nothing of higher priority is unblocked as a result of the work the ISR did.

Roxy-3D on 19 Nov 2016

It's not entirely impossible to have interruptible interrupts on AVR, but it's a bit tricky and a bit dangerous - especially with our interrupts lasting 'for ever'.
https://github.com/grbl/grbl/blob/master/grbl/stepper.c#L281-L304

And there is no 'selectable' interrupt priority.

Blue-Marlin on 19 Nov 2016

An RTOS can be useful to manage multiple processes, but there is an overhead in both memory and CPU cycles, so if you have really time critical code or are short on CPU cycles, it makes things worse.
If you have spare CPU and memory, and something like a TCP/IP stack then an RTOS starts to become useful, but still not necessarily better than cooperative multitasking (superloop).
I tried FreeRTOS in the R2C2 printer firmware for Cortex M3 (LPC1758), but it rapidly ate up RAM, so I abandoned it.

I think that to move forward with 32 bit Marlin either
a) we keep the architecture very similar to 8 bit Marlin, and regard the ARM as just a fast AVR
b) we create new fork for 32 bit which is not bound by AVR limitations, can use RTOS etc

I think a) provides an easier transition in the short term but quickly becomes very limiting. Long term, b) is really the only way to go.

bobc on 19 Nov 2016

👍1

Seeed Studio has an open source ARM/Mega footprint board for $39. It seems to tick many of the request above. and a ramps board should drop on. https://www.seeedstudio.com/Arch-Max-v1.1-p-2632.html.

I took a close look at that board but there are two major problems:
a) 3.3V IO not compatible with RAMPS, needs RADDS or RAMPS-FD
b) designers did not follow Arduino standard pinout, so some functions may not work or worse cause damage to CPU

To be fair to Roy, running a small business and a Kickstarter is very time consuming, and to deliver in December requires design to be frozen now. There are significant lead times getting boards built and tested.

bobc on 19 Nov 2016

@Roxy-3D

But the other problem is RAMPS isn't 'Fail Safe' with an ARM processor. The GPIO signals reset to the opposite state of an AVR and what will happen is if the processor does not come up, or Marlin is sick, the heaters will all come on full bore. They will start fires.

GPIOs start in the same state on both AVR and ARM. What happens outside the CPU depends on external circuitry. A properly designed circuit should ensure a safe state - some designs fail with that, but that is really not the fault of the CPU.

I think before anyone starts suggesting some CPUs could "start fires", they need to be very sure of what they are saying.

bobc on 19 Nov 2016

@Roxy-3D, @boelle @jbrazio or anyone from the firmware maintainers willing to open a campaign.
Apologies for not knowing, but who is the big brother of the firmware maintainers?

Maybe Kickstarter is the most popular platform that you could try raise the funds for it.

Simply make as to have no rewards, in their rewards tiers.
Or just some "Thank You reward from the Marlin team" :)

psavva on 19 Nov 2016

I think before anyone starts suggesting some CPUs could "start fires", they need to be very sure of what they are saying.

My mistake. And it was an honest mistake. I'm trying to get all this stuff sorted out in my head. If I remember right, the Due with RAMPS was unsafe because the bootstrap inverted all the GPIO pins from what the AVR's do. Or something like that. But then I latter made the mistake of thinking that ARM's in general do that.

Roxy-3D on 21 Nov 2016

@Roxy-3D
RAMPS != RAMPS-FD 1.0 != RAMPS-FD 2.0
Talking about RAMPS in this context is about the same as talking about REPRAP_DISCOUNT_CONTROLLER when talking about displays. As long as your listener knows, from the context, if you are talking about graphical or character displays that may be sufficient. Here you used RAMPS without enough context do decide which one of the tree you are talking about. - And it makes all the difference.

Blue-Marlin on 21 Nov 2016

I do understand that. The mistake I made was early in the process the Due board was the main processor board for 3D-Printer stuff. And the makers of the Due had done something to flip the default logic values for the GPIO signals of the processor in the boot strap. (Or something like that).

I made the mistake of thinking that was the normal operation of the ARM processors in general. It is good that is not the case.

Roxy-3D on 21 Nov 2016

It seems there is not much love for a 32 bit Marlin out there, and downright hostility in some influential quarters. Some of those people dissing Marlin are promoting their own hardware/software solutions, but not all of them.

Makes me wonder if there is really much demand for a 32 bit Marlin in the user community, and whether it is worth pursuing.

bobc on 23 Nov 2016

It seems there is not much love for a 32 bit Marlin out there, and downright hostility in some influential quarters.

No @bobc . I do not believe this is true at all. It is possible this thread got started a little bit too early. Or it is possible this thread could have been run with better vision and better leadership skills. There are a lot of different perspectives and view on the different things that happened.

I was hoping some company with a viable 32-Bit board would see merit in seeding the Marlin development community (including motivated 'testers') with 8 or 10 board sets. I was hoping if we all had the same board set we could make progress faster. That vision was never realized. Perhaps I could have done a better job reaching out to the corporate entities and helping them understand the value to both them and the 3D-Printer community. Perhaps I was too early.

It is true there is a lot of controversy. And some of over issues that are not that important in the big picture. But right now I think we are at an inflection point. So many 32-Bit boards are being announced and starting to show up, we may not need a 'Reference Platform' to make progress.

Probably what is going to happen is over the next 3 months some developer will decided to move Marlin's RC-8 on to what ever 32-Bit board they have. And some other developer will decide to move that code base onto what ever board they have. It isn't going to happen like I was hoping it would happen. But for sure, Marlin is going to be moved to a 32-Bit platform. I have very little doubt about that.

I think what is likely to happen is somebody repeats what you did a while ago. But what will be different is they won't do it for a Due and an old version of the code base. Instead, they will do it for a board set that is more viable and using RC-8.

Roxy-3D on 23 Nov 2016

@Roxy-3D I am referring to comments on Google+ such as

Marlin should not, under any circumstances support both 8bit and 32bit. There are so many hacks to inch out every bit of processing power and memory on marlin, that would no longer be required on a 32bit board.

and reprap.org

Marlin is bloated, its old and hacked to bits and it makes many compromises just to barely function. (some of those are due to trying to run on an under powered processor). If you want to support 32 bit firmware support the smoothieware guys or the duet firmware guys. There is zero reason to port marlin and waste time and money and resources when these other better firmwares options already exist.

I think there are elements of truth in both those comments. Also, the gofundme campaign has attracted only 2 sponsors.

It's been 3 years since a 32 bit Marlin was first discussed, and I'm just not seeing regular users asking for a 32 bit Marlin. The question we really need to ask is exactly what advantages marlin would bring over well established 32 bit firmware like Smoothieware and RepRapFirmware?

We've been discussing in this thread for over 6 months with little progress. I think probably the window for 32 bit Marlin has passed.

bobc on 23 Nov 2016

@bobc, I could not disagree more.

The limitation of 8 bit processor means that the development team need to think more about memory, program size, and if course execution times.

Since more developers such as @thinkyhead have dedicated a lot of time on the once not so great code, it's now become more modularised, and optimised.

Great features such Unified Bed Levelling by @Roxy-3D are bringing a more to the table than what other firmwares may or may not bring.

The great community is what makes Marlin so damn good.

Going 32 bit, with much higher clock frequencies and more instructions will allow Marlin to offer things like embedded web services, higher microsteps, and advanced kinematics, who knows maybe even Octoprint built in.

Stephanie S. has a point in my opinion that 32 bit Marlin should not be in the same codebase as the 8bit Marlin. ( https://plus.google.com/+AnthonyMorris/posts/Yfg3dn1q7eY )
That doesn't however mean that Marlin is "spaghetti" as some people have implied...

It would maybe even be a great idea to start real work on the 32 bit, and start maintaining the current Marin only for bug fixes, and freeze any new features to the 32 bit codebase.

A reference board is nice, but really not a necessity.
I think that even the Smoothieboard can be a reference board given how many people currently use it...
At the end of the day, as long as support starts somewhere, the rest of the boards will follow suite eventually.

I will pledge 50 USD to help get this going, I know that @adamfilip was also pledging.
I'm sure with a proper campaign, enough funds can be found to get the hardware, and time needed to do this.

"Let's make Marlin great again" 🇺🇸

psavva on 23 Nov 2016

❤1

I think there are elements of truth in both those comments. Also, the gofundme campaign has attracted only 2 sponsors.

No... That effort was shut down (at my request) because the logistics were too difficult.

It's been 3 years since a 32 bit Marlin was first discussed, and I'm just not seeing regular users asking for a 32 bit Marlin. The question we really need to ask is exactly what advantages marlin would bring over well established 32 bit firmware like Smoothieware and RepRapFirmware?

Those are valid questions. But Marlin has a loyal user base and now that cost effective 32-Bit boards are starting to show up our users would like to move to a more powerful platform.

We've been discussing in this thread for over 6 months with little progress. I think probably the window for 32 bit Marlin has passed.

Like I said... Maybe I started this thread too soon. But I was hoping some corporate entities would help us have a 'Reference Platform'. I no long believe this is necessary.

foosel has a point in my opinion that 32 bit Marlin should not be in the same codebase as the 8bit Marlin.

I do think the two code bases will diverge. But initially, I would like to have the first 32-Bit version be identical with respect to features as the 8 Bit version. For some period of time... Maybe a year... I would like us to try very hard, where possible to keep both in sync. But after that transition period, it probably would make sense to partially freeze the old 8-Bit version. If a new feature is too hard to make work in both place... It gets left behind. The 32-Bit hardware is already cost effective. In another years worth of time it will be easy to tell users "If you really need that new feature, switch to the 32-Bit platforms."

I do think we end up with two different code bases. But I would like to have a transition period where we keep both in sync and let users choose which hardware platform they want to run. And certainly, there are a lot of printers out there that can keep working just fine without forcing people to upgrade them to new 32-Bit platforms.

That doesn't however mean that Marlin is "spaghetti" as some people have implied...

Having a serious 32-Bit platform will help us a lot to do further clean up of the code.

@bobc I wish I could wave a magic wand and get you to port RC-8 to any ARM platform that makes sense to you. I would do what I could to 'Standardize' that starting point and try to accomplish a common code base out of it. Preferably, some board that has Arduino support.

@bobc The big problem is we need a 'Beach Head'. There are very few people that can 'Eat the Whole Elephant' and get us a version of RC-8 running on an ARM board set. You are one of those people that can get us a 'Starting Point'. If we can just get something, anything close to that limping along, lots of other individuals can start contributing in other areas. Can you please give it some thought? If you can get us something that compiles and even sort of moves the nozzle around in a rational manner, I think you will find lots of other people that want to help out.

"Let's make Marlin great again" :us:

I hate to sound like Hillary! But Marlin never stopped being great! :)

Roxy-3D on 23 Nov 2016

Just an idea. You should look at the reprapfirmware source. A lot if not
most of motion and servo support have been ported from marlin. Dc42 has
done an amazing job with the firmware. The environment is easy to build.
The Web interface is amazing. Setting up a config for multiple hardwares
would probably be easiest among all that are available and it's completely
open source... I realize it's not "marlin" but at the same time it kinda
is...

Sniffle on 23 Nov 2016

I hope you don't mind some comments from a non-Marlin developer.

I've been using Marlin for 11 months with a Geeetech G2S Pro (I know, I know -- crap, but I didn't realize it at the time. :) ) I now have an Original Prusa i3 MK2). I'm quite comfortable using Arduino, or similar development environments. I've been tracking the progress on RC8, as I'd like to get something "fresher" on my G2S Pro with a working bed-level.

From the outside, it looks like the project has a few dedicated developers, but no real leader. RC7 was released in July. RC8 has been "just about ready" it seems for at least a month. The last stable release was nearly two years ago. Folks coming from outside the project might suspect it is now just a playground for a few hobbyists, and not something that is tracking to have regular releases usable by non-developers. Recent notes seem to focus on tweaking new features, not necessarily getting ready for a release (not just a release candidate, but a release).

Take a look at https://github.com/MarlinFirmware/Marlin/releases - regular progress, yes, but no end in sight - and that is just for the existing codebase. I think the 8-bit roadmap needs to be agreed to and buttoned up before much concern goes into thinking about a 32-bit release.

As to the donations -- the gofundme site was mentioned here just a couple of days ago in thread #5277. I was just about to drop in $20, but now it sounds like that isn't the best place.

I do think there is good community desire for a strong Marlin. Look at the sales of the Prusa i3 MK2. It has Marlin (tweaked, certainly) at its core). People won't wait for ever. What are the other players in the industry using? Are they waiting for something from Marlin, or have they moved on?

Just some food for thought.

John

JohnOCFII on 23 Nov 2016

@foosel has a point in my opinion that 32 bit Marlin should not be in the same codebase as the 8bit Marlin.

I'm a bit confused, I can't remember ever voicing an opinion on the whole topic O.o

foosel on 23 Nov 2016

Sorry, my mistake, This was Stephanie S.
https://plus.google.com/+AnthonyMorris/posts/Yfg3dn1q7eY

I'll edit my comment. Sorry again

psavva on 23 Nov 2016

No harm done, I was just seriously confused

foosel on 23 Nov 2016

The general problem is that people who are used to using Repetier, or Smoothieware consider Marlin to be old and unmanaged, due to the nature of the fact of the requirements that users require from an 8bit micro for the advanced 3D printing.
So users have typically driven Marlin to what it is now, which is a bucket load more than what it did two years ago.
Marlin32 should be a separate fork, with it's codebase managed independently of Marlin8 (using this to differentiate between 8 bit micros and 32 bit micros)

Grogyan on 23 Nov 2016

My 2 cents:

I fully agree with the need for a 32 bit Marlin. Over time we have seen a lot of time and effort invested in trying to optimise the code and having to make compromises due to the limitations of 8 bit boards. The team is literally pushing the limits of the hardware (and I can certainly appreciate the effort in developing efficient, elegant code) but it Marlin is to evolve, it will definitely need to use 32 bit boards to remove some of the most critical issues around performance. I for one am willing to put money into buying hardware and doing testing for that code base. I can code Arduino as well but my understanding of the Marlin internals is not as thorough as that of the main developers, but will be happy to contribute as required.

Regards,

Ernesto

emartinez167 on 23 Nov 2016

I can code Arduino as well but my understanding of the Marlin internals is not as thorough as that of the main developers, but will be happy to contribute as required.

And this feeds back to my earlier comment:

The big problem is we need a 'Beach Head'. There are very few people that can 'Eat the Whole Elephant' and get us a version of RC-8 running on an ARM board set. You are one of those people that can get us a 'Starting Point'. If we can just get something, anything close to that limping along, lots of other individuals can start contributing in other areas. Can you please give it some thought? If you can get us something that compiles and even sort of moves the nozzle around in a rational manner, I think you will find lots of other people that want to help out.

We need to get the current code base limping along on any viable, cost effective 32-Bit platform. And then other people can start fixing things that need fixing.

Roxy-3D on 23 Nov 2016

We have already had a Beach Head, several in fact. They have mostly become
unmaintained forks.

What is actually needed to move forward is support for 32 bit within the
official Marlin repository. That is the real sticking point.

However, no one has really answered the question of what is the benefit to
a user of Marlin over and above Smoothieware or RRF, apart from "it's
Marlin".

32 bit Marlin will need to use a runtime config because most 32 bit
platforms are not supported with Arduino bootloader, so they won't be able
to use their existing config.

On 23 November 2016 at 22:38, Roxy-3D notifications@github.com wrote:

I can code Arduino as well but my understanding of the Marlin internals is
not as thorough as that of the main developers, but will be happy to
contribute as required.

And this feeds back to my earlier comment:

The big problem is we need a 'Beach Head'. There are very few people that
can 'Eat the Whole Elephant' and get us a version of RC-8 running on an ARM
board set. You are one of those people that can get us a 'Starting Point'.
If we can just get something, anything close to that limping along, lots of
other individuals can start contributing in other areas. Can you please
give it some thought? If you can get us something that compiles and even
sort of moves the nozzle around in a rational manner, I think you will find
lots of other people that want to help out.

We need to get the current code base limping along on any viable, cost
effective 32-Bit platform. And then other people can start fixing things
that need fixing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-262647181,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR_VxxiVRpXFZAnMkFbzSy8uV19Agks5rBMBdgaJpZM4Imb5C
.

bobc on 23 Nov 2016

👍1

What is actually needed to move forward is support for 32 bit within the
official Marlin repository. That is the real sticking point.

If I had a some what working version of Marlin RCBugFix running on a viable, cost effective 32 bit board, I would be willing to make a branch for it. Especially, if it could be built with Arduino.

However, no one has really answered the question of what is the benefit to
a user of Marlin over and above Smoothieware or RRF, apart from "it's
Marlin".

It has been answered. Marlin has a very large (and loyal) user base. And many of those users would like to move their printers into the future. The future is going to be on 32 bit processors. So Marlin needs to move there to accommodate its users. Moving to a 32 bit processor is also going to help Marlin's developers. It will give them better debug tools, more CPU cycles, more memory and very possibly an RTOS to help organize tasks.

Roxy-3D on 24 Nov 2016

... what is the benefit to a user of Marlin ... they won't be able to use their existing config.

For Marlin developers it should be no problem to come up with a solution for this. A small script or whatever. But,..

32 bit Marlin will need to use a runtime config because most 32 bit platforms are not supported with Arduino bootloader

I don't understand that. The firmware Marlin or whatever needs to be programmed into the Flash of the chip so there needs to be a possibility to program the flash of the ARM chip. So in principle the same functionality (changing a *.h file) could still be used on ARM.

So there exist really no need (other than giving the user better options) to move away from the current configuration mechanism.

JustAnother1 on 24 Nov 2016

@Roxy-3D

If I had a some what working version of Marlin RCBugFix running on a viable, cost effective 32 bit board,

Ok, let me know what board meets your criteria and I'll create a port for it!

bobc on 24 Nov 2016

@JustAnother1

I don't understand that. The firmware Marlin or whatever needs to be programmed into the Flash of the chip so there needs to be a possibility to program the flash of the ARM chip. So in principle the same functionality (changing a *.h file) could still be used on ARM.

Sorry, yes you're right. If the user can build a new firmware in Arduino and download it then a similar config.h could be used.

bobc on 24 Nov 2016

It took me a long time to decide whether I should add my 2ct here or not. But reading through huge parts of this thread I think it's necessary to state this.

You still haven't answered to yourself why users would want Marlin on 32bit when there are established and well working options already.

You fail to understand that the majority of your users don't even know they are running something called Marlin, have never touched an Arduino IDE or any other IDE in their life, aren't the ones editing the configuration because that plus compiling and flashing would be way over their head anyhow and depend on their 3d printer vendor doing all that for them.

Your users don't care how great or not so great your code base is and how many different boards and printer layouts and whatnot it supports. They are only interested in their 3d printer actually printing, and with as little work on their part necessary as possible.

Your users are no longer devs or even ambitious tinkerers. That ship has sailed a couple years ago, yet you still are discussing IDEs and configuration editing by the end user. That's completely irrelevant for your actual user base. Your users are using Marlin because that's what their printer came with. Because the vendor they bought it from used it (or rather, a version forked off 2 or 3 years ago), modified it, and put it on the printer controller. They don't update it. They probably don't even know it has a name and that it's being developed by someone else than the vendor of their printer.

You don't have brand loyalty. And not realizing that for a long time now has hurt you, the Marlin project in general, and is probably also the cause for a lot of bad flak you are getting. Talking about Marlin on 32bit doesn't make sense as long as you don't have a list of valid reasons that speak for that kind of development effort (especially not as long as your next 8bit release is still a moving target). And instead of tackling that and actually talking about why anyone would even want or need 32bit Marlin, you are losing yourselves in discussions about what kind of board to target first.

Start at the beginning. Figure out who your target audience actually is, what their requirements are, if and how you can actually help there and if that makes sense considering your responsibility with regards to current 8bit Marlin. Yes, that's the not-so-fun part. But it's a very important part.

foosel on 24 Nov 2016

👍5

If I had a some what working version of Marlin RCBugFix running on a viable, cost effective 32 bit board,

Ok, let me know what board meets your criteria and I'll create a port for it!

@bobc @psavva @elaboratecircuits I think having RCBugFix buildable on the ARM4RAMPS or the Re-ARM for RAMPS would give us a good starting point. And you two have said:

I think that board shows a lot of promise, and hits all the buttons except for a debug connector. I have not used Panucatt kit but they seem to have a decent rep. I have pledged for a December delivery board.

and

I have also pledged for the December board. I will also help towards the 32bit support development.

And up above bobc said:

Forget to mention, there is an Arduino package for LPC1768 from Explore-M3 which should make porting to that chip a lot easier. https://github.com/ExploreEmbedded/Explore-M3

If this will work to get us started, I'll order myself a set of boards also. Does this work for you?

Roxy-3D on 24 Nov 2016

@Roxy-3D I will donate a board to you, or simply a 50 USD donation towards u getting the board.
Let me know a PayPal account or Fund me account, and I'll donate.

psavva on 24 Nov 2016

I will donate a board to you, or simply a 50 USD donation towards u getting the board. Let me know a PayPal account or Fund me account, and I'll donate.

Thanks! But let's wait and see if bobc is in agreement.

Roxy-3D on 24 Nov 2016

@Roxy-3D Sure, works for me. I've started setting up a build environment for a LPC1769 dev board I have already. I don't expect to get re-ARM board until lat December, but I expect to have lots of spare time in Jan.

bobc on 24 Nov 2016

@bobc @psavva And any others willing to join in...

Sure, works for me.

Does it matter if people use ARM4RAMPS or the Re-ARM board? I'll order which ever one you tell me to order. And do we need the EC-RAMPS board or can we just use a standard RAMPS 1.4 board until the EC-RAMPS are available?

Perhaps we should start a new thread focused on getting the development environment set up.

Roxy-3D on 24 Nov 2016

The Re-Arm is advertised as a drop in replacement for the Arduino Mega, and designed for Ramps 1.4

Quote:
RE-ARM is a 100Mhz, 32-bit ARM controller with the popular Arduino MEGA footprint. It's a plug-in replacement for the Arduino Mega in your RAMPS setup for a quick and easy upgrade to 32-bit goodness.

psavva on 24 Nov 2016

Just wanted to chime in here - Panucatt makes excellent products, but they're not really known for having a robust supply chain. If wide availability to users is something that is important in choice of reference board, it's worth taking this into account.

Hate to throw a wrench into things, I've been following this thread for a while and know how much work it took to get to this point.

caenan0 on 24 Nov 2016

If wide availability to users is something that is important in choice of reference board, it's worth taking this into account.

Thank You for the heads up. There is no 'Perfect Solution'.

If we can get RC-8 up and running on a 32-Bit ARM processor... We can resolve that issue next. We just need to get up and running on something.

Roxy-3D on 24 Nov 2016

I will also buy whatever board you guys settle on. and plug it into my Makerfarm i3v. Unfortunately I cant code to save my life but I can test.

adamfilip on 24 Nov 2016

I'll also have to be a tester, and somehow learn how to code C/C++

I'm an Oracle PL/SQL developer, but also good at C#.

Let's see where that gets me in the world of pointers :O

psavva on 24 Nov 2016

Now that everybody wants to start coding right away, we should probably start thinking about design, right?

Start at the beginning. Figure out who your target audience actually is, what their requirements are, if and how you can actually help there and if that makes sense considering your responsibility with regards to current 8bit Marlin. Yes, that's the not-so-fun part. But it's a very important part.

I think the Marlin users have a Idea of what they expect from 32bit Marlin, right? A list of these things might give the developers the information of where to start and what to consider. So please speak now (or be silent forever) to give this development the right direction.

JustAnother1 on 24 Nov 2016

Currently, getting RC8 to be the gold master is what is holding back from moving forward to the 32bit platform.

As stated already using an 8bit processor, means making a number of compromises.
Which is evident with using Delta's, as the positional coordinates from the inverse kinematics which then gets truncated.
Slow upload speed of uploads to the onbaord SD card with gcodes, is a serious holdback as well, as that still means a lot of moving backwards and forwards from PC to Printer for large files.
Matrix tranformations of bed and skewness, canease the strain on the micro if a 32bit micro was to be used.
Better serial throughput management is also a plus as that has a separate thread that has also been going on for months

Grogyan on 24 Nov 2016

Now that everybody wants to start coding right away, we should probably start thinking about design, right?

Start at the beginning. Figure out who your target audience actually is, what their requirements are, if and how you can actually help there and if that makes sense considering your responsibility with regards to current 8bit Marlin. Yes, that's the not-so-fun part. But it's a very important part.

No. We will not spend 3 years doing this. We will not start at the beginning and go into endless debate about whether this data type is needed or if it should be done as int or float. It won't be a debate about whether we really need this MCode or that GCode.

The first official 32-Bit version of Marlin WILL BE a faithful conversion of the 8-Bit AVR Marlin. We can start the endless debates on this and that after that is accomplished.

I think there is a place for a HAL in this effort. That question and how it is implemented will provide plenty of opportunity for debate.

Roxy-3D on 24 Nov 2016

@Roxy-3D I don't want endless discussions. But the information from @Grogyan is good.

To cut the discussions short:
How do we start?

You said with a 1:1 port - fine with me.

When can we start?

You don't want to spend 3 years - fine with me. How about right now? Or do we need to wait for RC8, RC9,... ?

Why not start a branch today that then people can send pull request to ?

JustAnother1 on 24 Nov 2016

I'm still waiting for bobc's opinion on whether ARM4RAMP's is OK or if I need to order and wait for a Re-ARM board. But as soon as I get that information I will place an order.

Then, with that information... I think we want to target the 'Stable' release that will get tagged when RC-8's BugFix gets promoted. It would be ideal from a user's perspective and a developer's perspective to have the stable release be almost the same code independent of whether it is 8-bit or 32-bit. That will also make it easier for us to maintain two code bases.

What code is used initially probably depends on when we can get boards. We might be able to start the effort with RCBugFix, and track the progression of that to RC-8 and a stable release. In this case... it may not be that bad to have the code base shifting underneath us because much of the work is getting the development environment (and maybe the HAL if we go that route) to handle the compilation of the code base.

So if you have a 32-bit board (it doesn't have to be a ARM4RAMPS or a Re-ARM board) I think the current RCBugFix would be a good thing to see if you can compile and build. And in fact, it may be very helpful to have a few stray boards in the mix that are not ARM4RAMPS or Re-ARM boards just to get early notice on any issues trying to move off of those boards.

What is actually needed to move forward is support for 32 bit within the
official Marlin repository. That is the real sticking point.

@bobc What do want there? The simplest thing would be to put the current RCBugFix there. However long term we know that isn't the target. Please suggest what you think makes sense and I'll get it in place.

Roxy-3D on 24 Nov 2016

@Roxy-3D ARM4RAMPS appears to be in a prototype stage, I don't have much info about it. Anyway, it doesn't seem to be orderable yet.

A branch that tracks RCBugFix should be ok I think.

bobc on 24 Nov 2016

Cough DuetWifi Cough..... LOL

adamfilip on 24 Nov 2016

👍1

A branch that tracks RCBugFix should be ok I think.

@bobc OK! Will do! It is there. I've sent you an invitation to the MarlinFirmware organization. When you accept it, I'll give you administrative privileges to the 32-Bit branch.

Roxy-3D on 24 Nov 2016

👍2

Hi,
Just my 2 cents worth, but why not use a board that's available and has been around awhile and is cheap like the due / radds combo, probably more users out there with this than up an coming boards that are unproven. Besides facility for only 5 on board stepper drivers in my opinion is no longer enough (dual x carriage), how much extra would it cost a forward looking developer to design and build a board with a minimum of 6 stepper driver slots instead of the old only 5 sorry. I know externals can be added but thats extra cost, wiring and stuffing around.
regards - bruce

bruce356 on 25 Nov 2016

👍1

Let's take a look at the existing 32-bit forks of Marlin and compare. Some are quite old, but the first question is, what is the best approach for a hardware abstraction layer?

Of these, the fork by @MagoKimbra is the most well-maintained and thoughtful.

thinkyhead on 25 Nov 2016

From the outside, it looks like the project has a few dedicated developers, but no real leader.

That is accurate, @JohnOCFII. We are all just volunteers with no hierarchy. But, I do my best to vet everything before merging it.

RC7 was released in July. RC8 has been "just about ready" it seems for at least a month.

Well, I got a real job, so I can't devote the 8 hours per day that I had been. On the other hand, I have food and shelter now, so that's a plus.

The last stable release was nearly two years ago.

True. And it is still a viable release. The Prusa MK2 firmware is based on that, and is widely regarded as a very good fork.

Folks coming from outside the project might suspect it is now just a playground for a few hobbyists, and not something that is tracking to have regular releases usable by non-developers.

They might. But I do try to regularly post progress reports to public groups, help users with their questions, and write up decent release notes. And I take bug reports seriously and try to address them in a timely manner. So in general it's not so bad as open source projects go. Of course, we are all volunteers with outside lives, and are only able to do this in our copious spare time. Prior to my own involvement the project was at a standstill (some host developers might wish it still was) and it was hard to get any response. Since that time it has progressed markedly. Compare the sources of 1.0.2-2 to RCBugFix, and it's clear that more custodial care is being taken.

Recent notes seem to focus on tweaking new features, not necessarily getting ready for a release (not just a release candidate, but a release).

Currently there are some Dual X carriage issues needing fixing. And the graphical display is getting some needed optimization to prevent a starved planner buffer when printing small segments (especially a problem with deltas and SCARAs). I believe those will be worked out very shortly, at which time RC8 will be released.

thinkyhead on 25 Nov 2016

👍1

@thinkyhead I just wanted to say thank you for all your hard work and devotion to Marlin. Its really impressive that you can find so much time to invest. We all owe you and @Roxy-3D and the other developers our sincerest gratitude. and hopefully a few bucks :) to keep this going and growing.

adamfilip on 25 Nov 2016

🎉3 ❤1 👍1

@thinkyhead Thanks for your thoughtful reply. I look forward to helping with testing. Your GoFundMe account is now at a nice, round number. :) I also spread the word in the Original Prusa i3 MK2 group on FaceBook.

JohnOCFII on 25 Nov 2016

❤1

@thinkyhead

Of these, the fork by @MagoKimbra is the most well-maintained and thoughtful.

Yes, I think that is clearly the best structure out of the four. There is some work to do to improve the hardware abstraction, but it provides a good base to work from.

bobc on 25 Nov 2016

@bobc , The only experience I have in coding in Marlin is writing the Greek Language fonts, and support for Greek in Marlin.

I will need some help/guide how to setup the 32 bit development environment.
What software?
What OS? (I'm currently running windows)
Any special IDE?

psavva on 26 Nov 2016

@psavva Don't worry about that. There will be a number of 'Fast Followers' to what ever bobc is doing. I'll be setting up what ever he does and trying to understand it. I'll help you get setup.

Forget to mention, there is an Arduino package for LPC1768 from Explore-M3 which should make porting to that chip a lot easier. https://github.com/ExploreEmbedded/Explore-M3

But... I think there is a fair chance we just load the M3 Arduino board set and it might generate code for us.

Roxy-3D on 26 Nov 2016

🎵 everything i do… i do it fo-oh-oh-or you… 🎵

thinkyhead on 26 Nov 2016

@thinkyhead
Are you hoping for participate in the development of Marlin for Re-ARM,
and already pledged to the Kickstarter project?

esenapaj on 27 Nov 2016

@esenapaj I am available to help. I haven't pledged, but I need to settle all my affairs in Portland, Oregon and get settled in Austin, Texas —obtaining a mailing address— first. I should be in a more conducive situation come January 1.

thinkyhead on 28 Nov 2016

I see...
So, I offer a Re-ARM to you.
I've a pledge of "Re-ARM+Ethernet December 2016 delivery" at this time, thus I transfer it to you.
Items of the Kickstarter are often not selling continuously, so it's necessary to secure now.

But, It looks like that you seem to be moving from December to January.
Then, in order to avoid "destination unknown" at the time of delivery, "January 2017 delivery" may be better than "December 2016 delivery" in some cases.
I can change it.
Which do you prefer of "December 2016 delivery" or "January 2017 delivery"?

esenapaj on 28 Nov 2016

add at least 6+ months to any Kickstarter timing :) in my experience

adamfilip on 28 Nov 2016

👍1

add at least 6+ months to any Kickstarter timing :) in my experience

Although... the dates are close enough, if they were going to start slipping, I would hope we would see the schedule changes on the web site!

Roxy-3D on 28 Nov 2016

⁣Hello.
I don't know if this was ever mentioned here but I thought I would bring another option to this thread.

This board seem like a good option for a 32 bits processor and might just match the ramps 1.4 board pinout.

https://www.rs-online.com/designspark/bringing-multicore-to-the-arduino-world-with-shieldbuddy-tc275?cm_mmc=CA-EM-_-DSN_20161128-_-DM9879-_-BOX2_URL1&cid=DM9879&bid=150843051

I will see if I can find more info about it.

Sent from TypeApp

On Nov 28, 2016, 7:53 AM, at 7:53 AM, esenapaj notifications@github.com wrote:

I see...
So, I offer a Re-ARM to you.
I've a pledge of "Re-ARM+Ethernet December 2016 delivery" at this time,
thus I transfer it to you.
Items of the Kickstarter are often not selling continuously, so it's
necessary to secure now.

But, It looks like that you seem to be moving from December to January.
Then, in order to avoid "destination unknown" at the time of delivery,
"January 2017 delivery" may be better than "December 2016 delivery" in
some cases.
I can change it.
Which do you prefer of "December 2016 delivery" or "January 2017
delivery"?

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-263252505

TheCoolDude on 29 Nov 2016

That is a seriously cool board!!!! And they give a lot of technical detail about it. However... there must be some internal cache memory on each processor in order for them to not swamp the memory bus and end up waiting for each other. There is no discussion about whether there is an internal cache nor how big it might be.

This is a very cool board! But we don't need 3 200 MHz processors!!!!

Roxy-3D on 29 Nov 2016

@TheCoolDude Could it be that the Aurix Processor they use is not an ARM processor?

By the way I mentioned that board in this thread on August 13,..

JustAnother1 on 29 Nov 2016

@JustAnother1 So you did, I missed that one!

This board is interesting for a few reasons ::

It appears to run at 5V, so may well work directly with RAMPS 1.4
There is an Arduino IDE plug in.

It is not any sort of ARM core, I think Aurix is a proprietary 32 bit core of Infineon, but that should not really matter. I think it could provide a really nice high end upgrade for RAMPS users, though probably only Delta or other exotic geometries would benefit.

I will order one anyway to play with, it could be an easy port.

bobc on 29 Nov 2016

The way they extended Arduino to use the 3 cores is interesting. You still have setup() and loop() for the first processor. But then you have setup2() and loop2() for the second processor. And setup3() and loop3() for the third processor.

Roxy-3D on 29 Nov 2016

❤1

@bobc I have some code for STM32 HAL. I would like to help getting Marlin to 32bit. When do you think that we will see the first commits on the 32-Bit-RcBugFix branch?

Once the HAL Interface/Hal for AVR gets started I and hopefully others could join committing HALs for other architectures.

JustAnother1 on 29 Nov 2016

Imagine being able to use one core for temperature management, second one for kinematics, and the third one for graphics display... Heaven!

Regards,

Ernesto

On 30 Nov. 2016, at 01:14, Roxy-3D notifications@github.com wrote:

The way they extended Arduino to use the 3 cores is interesting. You still have setup() and loop() for the first processor. But then you have setup2() and loop2() for the second processor. And setup3() and loop3() for the third processor.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

emartinez167 on 29 Nov 2016

@JustAnother1 I've been setting up build environments for Mega, Due and LPC1769, and playing with the bootloader for LPC1769.
I've started first phase of HAL implementation with AVR and Due as targets, based on previous work. Hopefully I will be able to create a pull request later this week.

bobc on 29 Nov 2016

@bobc Bob, I've sent you an invitation to join the MarlinFirmware organization. When you accept that, I can give privileges so you can do what ever you need to on that branch.

Roxy-3D on 29 Nov 2016

Re-ARM pinout map(draft) has been prepared.
http://panucattdevices.freshdesk.com/support/solutions/articles/1000242059-support-files

And, it looks like that they plan to sell the Re-ARM continuously.
http://www.panucatt.com/Re_ARM_for_RAMPS_p/ra1768.htm

esenapaj on 30 Nov 2016

@esenapaj I graciously accept your offer. I will know my new Austin, Texas mailing address in a few days. I'm moving in on 3 December. I will be visiting Portland from 7 December to around 20 December, and then taking a brief trip to Erlangen, Germany on 22 December. I expect to be back to my new Austin, Texas address before 29 December.

Whew!

So, if they can guarantee delivery before 20 December, then the best place to ship is my Portland address (c/o Castiron Carousel, as before). Otherwise, the Austin address will be better.

thinkyhead on 30 Nov 2016

It seems that you're going to be very busy next month...
Have a nice trip.

And I understand it.
So I've changed a pledge from "December 2016 delivery" to "January 2017 delivery" for avoiding a risk of "destination unknown".
Because the project deadline is 24:00 on December 3,
From there we go through various procedures and it will be delivered to Portland somewhere in the world by December 20th,
It seems that the schedule is too tight and probably impossible.

About Austin address, I'll contact you by e-mail at a later date.

esenapaj on 30 Nov 2016

Hey, what happened to branch 32-Bit-RcBugFix?? It seems to have disappeared.

bobc on 1 Dec 2016

Hey, what happened to branch 32-Bit-RcBugFix?? It seems to have disappeared.

I asked for help last night to get the privileges set right. The problem is you don't get full control of all the settings on individual branches. And Jaoa asked "Is it ok for me to mess with the 32-Bit-RCBugFix branch?" I said "Yes! There is no new code in it yet... It is just a copy of RCBugFix."

And the next thing I know... The branch is gone. I can put it back. I'll do that in the next few minutes.

Also... In hindsight... It probably makes sense to put a devel_ in front of the name so nobody thinks it is ready to use until it really is!

It is there again!

Roxy-3D on 1 Dec 2016

What the hell? This is stupid. If you tell people to use a branch, don't go and mess with it!

Please change it to "32-Bit-RcBugFix". I have been making changes off this branch, I am not starting again.

bobc on 1 Dec 2016

OK. I made it exactly as you specified. But my guess is it was actually called 32-Bit-RCBugFix. I put that in place also. I'll delete which ever one you are not using later.

Roxy-3D on 1 Dec 2016

Need a separate fork methinks.
Decisions about a maintained branch or fork, will occur after RC8 becomes the gold master.

Grogyan on 1 Dec 2016

I agree that everyone working in their own separate forks is the best idea. But keeping a branch in the main Marlin project is also needed so we can collaborate on it. We should follow the usual review procedures and use PRs to apply changes to that branch and not modify it directly. We'd like to enforce style and promote discussion.

thinkyhead on 1 Dec 2016

I think we do too much discussion with too little progress.
I like the Idea of giving bobc the branch so that he could publicly start developing there. This would give us a chance to discuss on what we see there. And give tips on how to do it better. I assume that bobc is open to arguments and probably happy to get support and help. I'm pretty sure that we will need some experimenting to find the best way to implement the HAL. Once this ground work is done the normal way of pull request and the whole formal process should be reestablished.

Discussing the basic design of a HAL on Pull requests is IMHO very hard. Having a solution would allow us to discuss ups and downs. And have others improve the solution bit by bit.

And in worst case the implementation gets off track and we can simple delete the branch, so what !

The solution of everyone on his own thread already happened:

https://github.com/Wurstnase/Marlin4Due
https://github.com/JRodrigoTech/Marlin-DUE
https://github.com/esenapaj/Marlin/tree/Duo
https://github.com/MagoKimbra/MK4duo

If thats the way you wnt to go then just merge one of these attempt into the current version.

JustAnother1 on 1 Dec 2016

I think we do too much discussion with too little progress.

You're right on the tipping point of irony with that statement.

I like the Idea of giving bobc the branch so that he could publicly start developing there.

I like the idea of bobc working on it in his own fork, and when it's ready to test, then posting a PR to the branch in the main repository, so it pops up in the notification queue and can be commented upon and reviewed using the awesome tools provided by Github. There is some methodology and standardization going on here, and I want to keep it on track.

I'm pretty sure that we will need some experimenting to find the best way to implement the HAL.

Truly. Which 32-bit boards will you be able to test on, and what kind of structural approach do you think would be best for the HAL as a starting-point?

And in worst case the implementation gets off track

Let's cross that bridge when we come to it.

The solution of everyone on his own thread already happened

No need to reiterate the list I posted last week. We're already on that page.

If thats the way you want to go then just merge one of these attempt into the current version.

Merge old branches into the current code? Not so simple, even for a git guru. I suggest you try it.

thinkyhead on 2 Dec 2016

Let me jump in... The only reason I created that branch was to let @bobc know we are dead serious about getting a 32-bit version of RCBugFix up and running. He was skeptical because several people (including himself) had already ventured in front of what the Official Support team could address 18 months ago.

We now have the code base much cleaner (THANKS TO @thinkyhead !!!!!!!) and now both the conversion and support will be much easier. Also, the 32-Bit development environment is much better than it was 18 months ago. It is still very limited, but it is at the point where we can cobble something together that the entire Marlin user base can use and deploy.

I'm still waiting for @bobc to accept the invitation to the MarlinFirmware organization. It is OK if he doesn't want that association! But I need that to give him administrator rights to the branch that I'm hoping is going to get us to a 32-bit version of RC-8. If he wants to work in his own branch and do normal PR's and not merge the PR's himself, I'm OK with that... We will be timely and merge his work as fast as he produces it. Mostly, I didn't want any road blocks in front of him. I wanted him to KNOW that we will absorb his 32-bit port of RC-8.

Seriously... Everybody is on-board that we need a 32-Bit version of Marlin. I'm of the opinion it would be best to put a HAL underneath it so as much as possible we have one code base sitting on two interchangeable HAL's. I don't feel comfortable speaking for other people but my guess is @thinkyhead almost certainly feels the same way. We can all argue about this and that . And probably we should do that. Let's do it in a constructive manner where we take a thoughtful look at what bobc does, and see if with lots of work and careful thought we can improve on what he puts in place. Let's do all that in a separate thread. And let's do it very respectfully because bobc is doing us a huge favor!!!!

Roxy-3D on 2 Dec 2016

❤1

As I've been off a bit.. can someone explain me why we're still discussing 32bit when I see a branch created by @thinkyhead for an ARM board ? What I mean is, are we discussing the evolution of that branch or something new ?

Note: I tried to find sources for ZeroPi but I was unable to find them.. nevertheless that little 25$ board seems the holly grail for Marlin32.

jbrazio on 2 Dec 2016

This info may be of use for Re-Arm

http://panucattdevices.freshdesk.com/support/solutions/articles/1000242059-support-files

New info was added since the last post.

psavva on 2 Dec 2016

I only comment here because I feel personally attacked by the comment made by @thinkyhead.

.

I think we do too much discussion with too little progress.

You're right on the tipping point of irony with that statement.

That does not help to get new developers on board. Especially in this situation having the right discussions can save a lot of coding.

I like the Idea of giving bobc the branch so that he could publicly start developing there.

I like the idea of bobc working on it in his own fork, and when it's ready to test, then posting a PR to >the branch in the main repository, so it pops up in the notification queue and can be commented >upon and reviewed using the awesome tools provided by Github. There is some methodology and >standardization going on here, and I want to keep it on track.

I think that a HAL is too big to be put into one pull request. For big changes like this git(hub) provides branches. The great tools of github allow us to have more than one discussion thread(issue) on a branch. And as with a pull request at the end you can decide if you merge the branch or not.

I'm pretty sure that we will need some experimenting to find the best way to implement the HAL.

Truly. Which 32-bit boards will you be able to test on, and what kind of structural approach do you >think would be best for the HAL as a starting-point?

I have the pipy board http://forums.reprap.org/read.php?13,524276 and an Arduino duo. I have other boards and printers too. That should be enough for me to test my code.

I implemented the HAL like this: https://github.com/JustAnother1/pmc/tree/master/hal/include

It is open source code, so copy and paste as much as you need. But keep in mind this HAL is designed to accommodate more than one ARM Cortex-M chip. It was not designed to be used on AVR!

If thats the way you want to go then just merge one of these attempt into the current version.

Merge old branches into the current code? Not so simple, even for a git guru. I suggest you try it.

Been there, done that. Easier merging is one of the big benefits of git. Try merging in subversion and you will see what I mean. You also don't need to be a git expert to do that. Checkout both branches in different folders and use the diff-tool of your choice then commit the result. That is the hardest version to do a merge. Git can help you lift the burden a lot.

Even the hard version of merging is less effort than doing the coding in the first place. So dismissing the 4 branches that already starting doing work for marlin that marlin needs is disrespectful of those developers!

I think Marlin owns @bobc a big thank you if he is still willing to put in some effort, after all that has happened.

JustAnother1 on 2 Dec 2016

@bobc, Thank You.

psavva on 2 Dec 2016

@thinkyhead

I like the idea of bobc working on it in his own fork, and when it's ready to test, then posting a PR to the branch in the main repository, so it pops up in the notification queue and can be commented upon and reviewed using the awesome tools provided by Github. There is some methodology and standardization going on here, and I want to keep it on track.

I agree that is a preferred approach and I am quite happy to work with that.

I haven't got to a complete AVR/Due HAL yet, so I will create a PR for what I have so far. There is perhaps a lot more AVR centric stuff than I remember, but @esenapaj https://github.com/esenapaj/Marlin has most of what is needed and is close to the current RCBug-fix I think.

bobc on 2 Dec 2016

@jbrazio

What I mean is, are we discussing the evolution of that branch or something new ?

Something new :) ~~#5346~~ #5357

ZeroPi was a one-off project. There are no layout files available, so someone would need to "clone" it, and then sell it... But it is a nice little board, Cortex-M0 are not very powerful, but the SAMD is supported by Arduino IDE.

bobc on 2 Dec 2016

So.. to which board are we building marlin32 to ? Due ?

jbrazio on 2 Dec 2016

I think what we all agreed is that we couldn't agree on a single board!

Really, any board that is on sale now and a complete printing solution could be considered. My dream is MarlinAnywhere...

Due is there in the PR because it is already well known and what I have to test with, even if the available shields are not ideal.

Next up is LPC1768, which gives us Re-ARM and potentially any Smoothie compatible board. Re-ARM is cool because it is cheap, uses RAMPS, and is the sort of cheap upgrade current Marlin/RAMPS users are likely to take.

Duet and DuetWifi are also in play, for people who want a more high-end single board solution.

STM32F4 gives us STEVAL-3DP support (I still can't buy one yet!), and maybe others.

Those CPUs cover most of the boards we know about which users can buy today.

I updated https://docs.google.com/spreadsheets/d/1YHvs5xxan2gO7NOX-_D04EB-NCUBVvKPKLbIFVuyzEI/edit with a column to indicate Marlin32 status.

bobc on 2 Dec 2016

@JustAnother1 …

Offtopic discussion that you all can ignore…

.

I feel personally attacked

Well, I was replying to you directly on the point that there are a lot of people here doing good work as time allows, and it's no good to give criticism on the basis of "too much discussion" and "too little code" when most in this thread have contributed quite a lot of good things. I'd rather not hear criticism of what amounts to caution and thoughtfulness. In fact, I'd like it if you could keep your "color commentary" to an absolute minimum.

That does not help to get new developers on board.

It helps to get the kind of collaborators I would prefer to work with on board. Those who can be constructive and who don't annoy the other volunteers with elitism.

I think that a HAL is too big to be put into one pull request.

No one suggested a _single_ pull request. Sorry if that was ambiguous.

For big changes like this git(hub) provides branches.

We created a branch, and I suggested that pull requests be made to that branch, rather than merely committing to it directly. Sorry if that was ambiguous.

keep in mind this HAL is designed to accommodate more than one ARM Cortex-M chip. It was not designed to be used on AVR!

We'll be designing the HAL in such a way that the code will be as close to universal as we can get, with AVR support included. Thus, many low-level functions, types, values, etc. will be replaced by macros. Macros will be the order of the day. We will learn to love macros.

So dismissing the 4 branches that already starting doing work for marlin that marlin needs is disrespectful

This is what I mean. You are reading more into it than was said or intended. I'm not bloody _dismissing_ anything.

What I'm saying is that it is a lot more work than a simple git merge to incorporate changes from a stale branch. And most of those branches are either very stale or highly customized. Thus it requires a huge amount of complex conflict resolution, which is not easy for most of the people who volunteer on this project, and believe me there will be huge gobs of conflicts.

In fact, even as "skilled" as I am with Git at this point, I would not undertake to just type git merge and try to bring in changes from those stale branches. Rather, it requires a more meticulous approach, examining the changes (vis-à-vis their own roots) and understanding them, then tailoring the best ideas to the new code-base, adhering to the established code style.

I don't know how much you have delved into the current code-base and compared it to the code-base upon which those other forks were built. I _respectfully_ suggest that you try git merge and see what happens.

thinkyhead on 3 Dec 2016

I will create a PR for what I have so far.

Great. That's the idea. Whenever you have any changes that will be worth checking out, just post it and we'll go over it with a fine-toothed comb.

Due is there in the PR because it is already well known and what I have to test with, even if the available shields are not ideal.

I think Due is the best start. It seems to require the least amount of hassle and gives us a good template to start building from.

Overall, it looks like @bobc has it well in hand. I look forward to seeing it come together.

thinkyhead on 3 Dec 2016

can someone explain me why we're still discussing 32bit when I see a branch created by @thinkyhead for an ARM board?

Are you referring to the old arch_samd_support branch? I think we might be able to say farewell to that branch now. It never got very far.

At some point I also started playing with the ZeroPi code, but then it became apparent it was just a one-off. So now the focus is on the boards we know will be around for a while, or which follow standards that will be common to most boards in the future.

thinkyhead on 3 Dec 2016

Re-ARM campaign has ended with a pretty good result. I am not really expecting to get anything before Winterval, USPS delivery to me from US usually takes 2-3 weeks.

If any devs want a "fun" task, we will need a USB mass storage driver for Re-ARM. Otherwise uploading firmware will be a real chore. Another possibility is to use DFU with the Smoothie bootloader - on Windows that will need a signed driver creating, if any one has skills in that area.

So far I have compiled the Smoothie bootloader in LPCXpresso, and created a blinky app which can be loaded by the Smoothie bootloader. The SD card must be written via PC though.

bobc on 3 Dec 2016

Hi Guys, how long would it be before I can trial Marlin32, I have Due/RADDS with dual X Carriage, can Not get the printer to function properly with either Repetier Dev or MK4duo (they are both so buggy in this dual function it is unbeleivable), they may work well for single X Carriage but they are both a total waste of time for dual X. So I am in no mans land at the moment.
Thanks and regards - Bruce

bruce356 on 14 Dec 2016

how long would it be before I can trial Marlin32

That is an impossible question to answer, although something many people might ask, so I will try answering a different question "what tasks are remaining?"

Roughly, there is
1 finish up abstraction of code
2 test on RAMPS, RADDS, RAMPS-FD
3 find and tidy loose ends
4 get general approval from team
5 tag a "32 Bit beta" release
6 get feedback from beta testers

I'm hoping to get to step 2 during the Winterlude. 4 and later depend on what sort of feedback is received.
But even after completing the above tasks I don't know if dual X Carriage would work, it might work or might not.

bobc on 14 Dec 2016

@bruce356
If you can't wait for the test start of the official 32bit branch, would you like to try my 32 bit fork if you're interested in it.
https://github.com/esenapaj/Marlin/tree/Duo

This is a unofficial, but usage is almost the same as the official RCBugFix from the user's point of view.
And about dual X Carriage, It has stabilized fairly well with recent updates.

esenapaj on 15 Dec 2016

If you guys are interested I've got a fork that runs on Teensy3.5 (32bit 120MHz ARM with FPU) and I've got steppers running, temperatures are reading correctly and it would run the heaters too if my MOSFETs were 3.3V compatible. Uploading and everything is through the Arduino IDE (with Teensyduino add-on) and I've used no additional libraries outside of the core itself.

teemuatlut on 16 Dec 2016

Noice
I was looking using my new Teensy for the same purpose, but never got
around to it

On Fri, Dec 16, 2016 at 12:42 PM, teemuatlut notifications@github.com
wrote:

If you guys are interested I've got a fork that runs on Teensy3.5 (32bit
120MHz ARM with FPU) and I've got steppers running, temperatures are
reading correctly and it would run the heaters too if my MOSFETs were 3.3V
compatible. Uploading and everything is through the Arduino IDE (with
Teensyduino add-on) and I've used no additional libraries outside of the
core itself.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-267477571,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGULGo-0TEGFrHewkyGm5uILg4vyUgXtks5rIdB4gaJpZM4Imb5C
.

Grogyan on 16 Dec 2016

Hi, thanks for the suggestion, I have configured and find it does not work with my DRV8825 drivers.

I found this post “dp90pusika commented on Aug 16 - And I'm testing https://github.com/esenapaj/Marlin for DRV8825 drivers because its broken right now, but everything else is working, if you have different stepper drivers it could be working for you”

https://github.com/MagoKimbra/MarlinKimbra/issues/116

Regards - bruce

bruce356 on 16 Dec 2016

@bruce356
About problem of DRV8825 on my fork, it was already solved.
If you set the MINIMUM_STEPPER_PULSE in Configuration_adv.h to 2, maybe your DRV8825 works.

reference: problem with drv8825 stepper

esenapaj on 16 Dec 2016

The HAL should make it a lot easier to support new CPUs. Although the HAL is not finalised yet, a port is more likely to get integrated if it follows the HAL pattern. It is useful to have other CPUs in the mix to find out how well the HAL accommodates new CPUs.

For me, I have the following priority list:

AVR, Due and compatibles
LPC17868 (Re-ARM, maybe others)
STM32F4 (STEVAL-3DP, Nucleo boards)
Atmel SAM4E (Duet Wifi)
Others - maybe Aurix? (ShieldBuddy)

bobc on 16 Dec 2016

Hi esenapaj, thanks for the information it worked a treat. Sorry to have to bother you hope you do not mind.

I have the RADDS LCD display also have a “RepRapDiscount FULL GRAPHIC Smart Controller” that works with Radds / Repetier Dev http://www.thingiverse.com/thing:1740725/#comments

I have activated the “LCD support” with RADDS LCD display currently installed (I will worry about SD later).

I only get the home screen with no functionality no menus, the reset button works but that’s all. Settings are :-

define ULTRA_LCD // Character based

define INDIVIDUAL_AXIS_HOMING_MENU

define RADDS_DISPLAY

Hoping you can assist Photo Attached

Regards - Bruce

bruce356 on 17 Dec 2016

@bruce356
About LCD support of RADDS on my fork, it's still underdeveloped.
I will confirm that afterward.

And, please post a defect report on my fork to my github page.
https://github.com/esenapaj/Marlin/issues/176 (RADDS LCD does not work)
This thread (Recommendations for a good 32 bit microprocessor to run Marlin) and this domain (https://github.com/MarlinFirmware) aren't forum of my fork and domain of my page.

esenapaj on 17 Dec 2016

@teemuatlut I have a Teensy 3.6 that I grabbed for this purpose after getting impatient with folks here coming up with an official hardware platform. I can give your code a shot on the Teensy 3.6 and with any luck it will run and I can address issues that remain. I'm working on putting a shield together so it can work with a 3.3V-modified RAMPS board, though I may need to change my layout depending upon how you have assigned the pins.

zenmetsu on 22 Dec 2016

@zenmetsu I too got the T3.5 because I was curious if I could get Marlin running on it. But I specifically chose the slower 3.5 because it was 5V tolerant. Currently all the compiler conditions check for the T3.5 chip and you'll need to address those (look for "__MK64FX512__"). You'd also need new speedlookuptables since (iirc) the F_BUS is higher. I can do it too if you can wait until next week.

I may need to change my layout depending upon how you have assigned the pins.

Please do it the other way around. I haven't done any pin plans and for now I've just used some free pins to drive a single stepper in a test setup. But there is no stepper or axis specific code so it could very well work with all. The code is in my Marlin fork under teensy35 branch and if you have anything, we should probably continue in another thread. I'd like to hear how it works out.

teemuatlut on 22 Dec 2016

@teemuatlut
You could considerer a simple division instead of using a look up table - like the other 32bit forks do. The hardware supported 32bit division is much more effective than the lookup table. The lookup table is a workaround for the 8 bit AVRs who don't have a hardware division, even not for 8 bit.

An other idea to bring Marlin forward, is to use the attempts to make a HAL (HAL development #5357), for the 32bit Teensys.

Blue-Marlin on 23 Dec 2016

@Blue-Marlin
Thanks. I'll definitely take a look at it.
I'll also try to make it into the format required by the HAL once that gets further along and once I have the Teensy fork running actual prints.

teemuatlut on 26 Dec 2016

I'll also try to make it into the format required by the HAL once that gets further along and once I have the Teensy fork running actual prints.

@bobc Bob, do you have everything you need? You should have Write access to 32-bit-RcBugFix but nothing has been updated recently.

Roxy-3D on 26 Dec 2016

I've mainly been watching football and drinking beer - holidays :)
I've also been working on an Arduino core for Re-ARM.

bobc on 27 Dec 2016

Happy Holidays @bobc
We'll hopefully have the RE-ARM boards early in January.

Let me know to help test

psavva on 27 Dec 2016

@zenmetsu
I've added the Teensy3.6 definition checks and it compiles just fine, but I have no way of knowing if it works beyond that.

teemuatlut on 29 Dec 2016

@bobc Bob, I've sent you a private message over at www.3DPrintBoard.com

Roxy-3D on 1 Jan 2017

I'm working on an STM32-based board, and I'm interested in trying to port Marlin.

I started a rough port by going through and removing AVR-specific code, but if there's a framework for a HAL in place I'd rather work in a way that keeps that compatibility.

I see @bobc has been implementing a HAL in his fork, is that a good place to start?

chrissbarr on 5 Jan 2017

My opinion would be a "Yes!" Hopefully you are doing the work on RC-8 or RC-8's RCBugFix.

But if you are not too far along, may I suggest you pull down BobC's code base and see if you can make your contributions there?

Roxy-3D on 5 Jan 2017

My opinion would be a "Yes!" Hopefully you are doing the work on RC-8 or RC-8's RCBugFix.

Awesome, cheers! The work I've done so far is fairly minimal, but yes it's on RC-8.

There's not an Arduino core for the STM32 IC I'm using (STM32F446), and it's beyond my understanding/experience to port an implementation for another core across right now. For the time being I'll just be working in eclipse with Marlin imported into a larger project, where the larger project hosts the setup / loop functions and implements macros for some of the more Arduino-specific stuff.

But if you are not too far along, may I suggest you pull down BobC's code base and see if you can make your contributions there?

I've started duplicating BobC's Due HAL for the STM32, and so far I think it's going well - he's done a great job exposing the MCU-specific functionality. The short-term goal will be to get things to the point where enabling the HAL and dropping Marlin into the eclipse project works. Long term hopefully someone can figure out an Arduino core for the '446, and remove the need for a separate IDE / build process.

chrissbarr on 6 Jan 2017

@chrissbarr are you talking about this code: https://github.com/MarlinFirmware/Marlin/pull/5357

(Also see @bobc comment on December 2.

With support for (c)make (planned) there is only one build process for all situations. (I don't like the Arduino IDE)

I also work on a STM32F4xx HAL code is here: https://github.com/JustAnother1/pmc

Inventing the wheel over and over again will not make it rounder,..

JustAnother1 on 6 Jan 2017

@JustAnother1 yeah, that's the code I'm working from now. Would you suggest something different?

I think I'm missing something, which comment in particular are you referring to?

Your Pacemaker client is interesting, I don't think I've seen it before. Is the goal there to build a new printer firmware from the ground-up around a HAL system, or am I not getting it? (in my defence, it's late here)

Definitely eager not to reinvent the wheel, hence the interest in porting Marlin to begin with. Open to any suggestions you have!

chrissbarr on 6 Jan 2017

@chrissbarr just wanted to make sure that you start from the current code, not one of the earlier experiments. (Bobc's comment in this thread just said that the pull request is the most up to date code)

I started Pacemaker after an Marlin issue where it became clear that the CPU power of the AVR is too limited to support all the features that some people want. The solution at that time was to split Marlin up into time critical stuff, and not time critical stuff. And to then move the not time critical stuff to a host (RasPi or something like it).

My host is here:
https://github.com/JustAnother1/Pacemaker

There is also a client (by Robert) t for AVR:
https://github.com/minnow-pmc/Minnow

Others also had that Idea. Bas did this:
https://github.com/mtu-most/franklin

And Kevin this:
https://github.com/KevinOConnor/klipper

All this was long before Marlin started addressing the need for more performance.

JustAnother1 on 6 Jan 2017

@Roxy-3D I send you a message on 3D Print Forum

psavva on 7 Jan 2017

@JustAnother1, hi, can "https://github.com/KevinOConnor/klipper" be configured for dual x carriage cartisian printer with due/radds/glcd/pi3/raspi. At the moment there is nothing it seems that works properly with 32 bit due/radds for dualX. How or can I contact Kevin O'Connor.
Thanks - Bruce

bruce356 on 8 Jan 2017

@bruce356 - you can open an issue in the Klipper github repo, or you can email me ([email protected]). Klipper doesn't currently support dual x carriage nor lcds attached directly to the micro-controller. However, neither would be difficult to add. If you're willing to run tests I'm sure we can get it working.

KevinOConnor on 8 Jan 2017

@thinkyhead
About Re-ARM, I sent a e-mail three days ago that it inquire about your shipping address.
And now, I got a "FINAL REMINDER" e-mail from Kickstarter.
They said "Last chance! we don’t want you to miss out on a great reward!".
I'm currently appealing for creator to extend the address entry deadline, but I don't know if it will work.
If your response doesn't make it in time, I'm planning to send the package to my house (Japan) tentatively, and resend it from me to your address (USA) at a later date.

esenapaj on 11 Jan 2017

@esenapaj It would be more cost effective to just send it to somebody in the USA and have them forward it to ThinkyHead when he has a stable mailing address. I'll handle it if necessary. And in fact, I have a brother in Austin TX where I believe ThinkyHead is moving. If so, I'll just twist my brother's arm until he agrees to drive it over to Thinky's house. (He comes home often enough, I think I could have it waiting at my brothers place in Austin when Thinky moves to Austin. Or maybe... It would make sense to just ship it to him at his address if we can't find somebody else that lives in Austin.)

Roxy-3D on 13 Jan 2017

general question about 32bit support.
It would now seem a lot of users have got their hands on a Re-ARM, but are surprised at some limitations that Smoothie has, like Z safe homing.
I can't seem to find BobC's repo to follow it's development, as i'm waiting for my Re-Arm to arrive sometime later this month.
I would personally want to use Marlin, as I am comfortable with the nuances of Marlin, and Smoothie has it's own nuances that will take time to learn.

Grogyan on 19 Jan 2017

@Grogyan BobC's development is here https://github.com/MarlinFirmware/Marlin/pull/5357

JustAnother1 on 19 Jan 2017

Cheers

Grogyan on 19 Jan 2017

Hi,

I am currently trying to port the Marlin RC6 to the ShieldBuddy. I have managed to get most of it to compile and I have converted a lot of the AVR assembler to C (the TC275 is so fast that assembler code is not needed!)
What I am having difficulty with is the interrupts. I can see that there is an interrupt for the serial receive and there is a timer0 interrupt for the stepper driver. Are there any others? Also, what frequency does the timer0 interrupt run at?
I am doing the work in Eclipse but using the Arduino/ShieldBuddy HAL.
I would welcome any help anyone can give. I know the Aurix pretty well but the Marlin is a complete mystery to me!!!!!

hitexuk on 25 Jan 2017

@hitexuk
RC6? Really? Why that?

At least there is the 'temperature'-interrupt - @1 kHz.

Blue-Marlin on 25 Jan 2017

@hitexuk Agreed on the RC6 question. That really does not make sense. You should be working off of RC8 or RC8's RCBugFix.

Roxy-3D on 26 Jan 2017

Ok. When I atarted RC6 seemed to be the latest version.

Are there any official guidelines anywhere on how to port to a new CPU?

Cheers

hitexuk on 26 Jan 2017

@hitexuk You can merge "RCBugFix" into your branch. You then need to resolve all the merge issues. But that then allows the Marlin team to easily merge your changes back into "RCBugFix"

Marlin right now is officially an AVR only Firmware. There have been several tries to port it to other CPUs. Many of those probably work. But there is not yet an official supported branch for anything other than AVR. @bobc is currently working on something that hopefully becomes the official Marlin HAL to get Marlin onto 32bit ARM Cortex-M. Maybe you can help bob and provide the Aurix implementation of the HAL.

I don't know of any porting guidelines other than coordinate with bobc.

JustAnother1 on 26 Jan 2017

@Roxy-3D
Sorry for late reply, and thank you for your kindness.
I could get in touch with him at Jan 13.
So, there is no problem at the moment.

esenapaj on 27 Jan 2017

@esenapaj I think you are saying you have his mailing address. If not, please let me know. He now knows where he will be in Austin.

Roxy-3D on 27 Jan 2017

you are saying you have his mailing address.

Yes, it is.
And Re-ARM for him was shipped at today's moning by seller.

esenapaj on 27 Jan 2017

Sorry I have been very busy with other stuff, I only have time to dip in
occasionally. I just recently got my Re-ARM board, so that might prompt me
to get moving again :)

Next on my agenda was:
1) resynch 32-Bit-RCBugFix-32bit with RCBugFix, resolve the conflicts
2) look at bugs raised on 32-bit branch
3) test with Due/RADDS, RAMPS-FD
4) Create the Re-ARM port based on Explore-M3 core.

The Explore-M3 Arduino core for LPC1769 is not as mature as I had hoped, so
I have spent quite a while fixing things. I have also got the Smoothieware
bootloader support into Explore-M3.

At some point it would be useful to document the HAL API, and create some
porting notes but not really ready for that yet. Supporting Aurix is low
priority for me, due to the non-Open nature of Aurix.

On 27 January 2017 at 13:54, Roxy-3D notifications@github.com wrote:

@esenapaj https://github.com/esenapaj I think you are saying you have
his mailing address. If not, please let me know. He now knows where he will
be in Austin.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-275670045,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR3oFX0IXNgb9BJF1B5u1RFny-CHKks5rWfcrgaJpZM4Imb5C
.

bobc on 27 Jan 2017

I have found it reasonably straightforward porting to the Aurix so far. My biggest problem is that I do not know the structure of Marlin or exactly what IO and interrupts it uses! I have left notes in the code where I have substituted AVR features with Aurix. Hopefully now I am moving to the RC8 it should make it easier to do the port again.

I am using the Mega2560 board plus Megatronics as the starting point. Can you recommend a Megatronics board for me to get for testing it all?

Cheers!

hitexuk on 27 Jan 2017

Is somebody interested in Marlin firmware version:

supporting HAL ( thank you bobc)
resynched with RC8 and RCBugFix
Tested with Arduino IDE 1.8.1
Tested on Due + RADDS + RADDS DIsplay
Tested on MEGA 2560 + RAMPS 1.4 + Reprap discount Full Graphic Smart Controller. I still have an issue with this controller: origin of the display is moving. but it seems to be known (issue #5756)

GDV0 on 29 Jan 2017

@GDV0 Everybody involved in this monstrous thread is interested in seeing Marlin firmware running on a 32-Bit platform. But I'm having a little bit of difficulty understanding your message. Are you saying you have a 32-Bit version of Marlin using bobc's HAL running on Due with RADDS ? And also tested on a Mega-2560 with RAMPS?

Can you clarify things a little bit?

Thanks!

Roxy-3D on 29 Jan 2017

Hi,

I am 80% of the way through porting RC6 to the Aurix processor on the ShieldBuddy, based on the Megatronics printer board. However it looks like at the least I should be using the RC8. Bobc's HAL based version would be the best starting point but I am not sure this is available yet.

hitexuk on 30 Jan 2017

I am 80% of the way through porting RC6 to the Aurix processor on the ShieldBuddy,

Really... You should be using BobC's work with RC8's RCBugFix.

But with that said, RC8 is VERY similar to RC6 from a porting perspective. It really should not be too difficult to do a 3-Way merge of what you have with RC8's RCBugFix and BobC's HAL !

Roxy-3D on 30 Jan 2017

@bobc I'm very interested in helping move the 32 bit development of Marlin forward, and I can send you a Cohesion3D ReMix (has LPC1769, currently runs Smoothie) to help with this. Currently no JTAG header (although we are looking to add this in the future) so the usual wiring will need to apply. I've already sent @Roxy-3D 2 boards for herself and ThinkyHead), you are the remaining person we need to get taken care of. Let me know what you think.

Best regards,
Ray

raykholo on 31 Jan 2017

@bobc Also... Can you look at: http://www2.keil.com/coresight/coresight-connectors?
Ray was interested in knowing your opinion on which of the 3 debug connectors is the 'Right' one to put on the next turn of the board. Is the 10-Pin connector sufficient?

Roxy-3D on 31 Jan 2017

@Roxy-3D The difference in the connectors are the supported Interfaces (SWD, JTAG, ETM) and the pin pitch.

I think we need at least SWD. JTAG might be a plus depending on the processor and pinout. ETM can provide more informations, but the debuggers that can use ETM are extremely expensive and are therefore hardly used.

SWD and JTAG offer the same options. In SWD the information is multiplexed so that only 2 pins are needed. This decreases the speed, but frees pins in the CPU. ETM provides Trace data. So you can see how the program moved through the code, not only the state it has at the breakpoint as with JTAG.

For pin pitch I prefer the bigger 0.1" headers. They are more robust and easier to handle.

I would therefore recommend the 10 pin header. with the pitch matching the cheapest debugger for the LPC1769.

JustAnother1 on 31 Jan 2017

For pin pitch I prefer the bigger 0.1" headers. They are more robust and easier to handle.
I would therefore recommend the 10 pin header. with the pitch matching the cheapest debugger for the LPC1769.

Looking on eBay, this might be the cheapest debugging hardware. But it appears to have a 20 pin connector: http://www.ebay.com/itm/Logifind-ULINK2-Debug-Adapter-Cortex-M4-Ulink-II-can-be-upgraded-in-mdk5-0-/281738796181?hash=item4198f0dc95:g:3PsAAOSwDNdVlPGv

In the 'Supported List' for processors, it does say the LPC1769 is on the list.

Roxy-3D on 31 Jan 2017

@Roxy-3D Thats the "old" ARM standard connector. It has the same pins as the 10 pin connected and some additional GND pins. So with this:
http://www.ebay.com/itm/40-pc-20cm-Male-to-Female-Pin-Header-Dupont-Wire-Color-Jumper-Cable-For-Arduino-/182390396354?hash=item2a775095c2:g:OyQAAOSw-0xYUO3N

and a 10 pin connector on the board with 0.1" header you could connect them and you don't waste too much space on the board. But these cables do not fit the smaller pitched plugs,...

JustAnother1 on 31 Jan 2017

Looking at the 2nd picture of:

http://www.ebay.com/itm/Logifind-ULINK2-Debug-Adapter-Cortex-M4-Ulink-II-can-be-upgraded-in-mdk5-0-/281738796181?hash=item4198f0dc95:g:3PsAAOSwDNdVlPGv

they show a picture of the circuit board. There are a bunch of unpopulated connectors. On the right side of the picture there are two 10 pin connector patterns. I wonder if we could just solder a 10-Pin connector into the 'correct' one of those and run a 10 wire ribbon cable to the board? If so, like you said earlier, we would want the bigger .1" pitch on the header.

Roxy-3D on 31 Jan 2017

The smaller 10 pin connector labeled ARM seems to be the 0.05" ARM Cortex header. So populating that and a 0.05" 10 pin ribbon cable with a 0.05" pitch cable on the LPC board would probably work.

The device seems to be a Chinese clone of the ARM ULINK2. On the ARM page it said that the ULINK2 does not have the 20pin connector though,...

My question here is who should buy that? The hard core Hacker will make it work, even without connector on the board. The Marlin user that wants to start development (and should therefore have debugging!) would get problems to solder the header into the debugger. And then the next problem is Arduino,...

I really hope that @bobc manages to get make support working in his HAL pull request. That would make thinks much easier. By the way the ST Nucleo board come with integrated debugger and cost less than what that debugger costs, just saying.

JustAnother1 on 31 Jan 2017

My question here is who should buy that? The hard core Hacker will make it work, even without connector on the board. The Marlin user that wants to start development (and should therefore have debugging!) would get problems to solder the header into the debugger. And then the next problem is Arduino,...

Well... Each of us has different expertise. Remember, there are hard core hardware types and there are hard core software types. I'm not opposed to soldering wires and cobbling a cable together if that is what it takes. But my preference would be that I can just buy a $15 debugger off of eBay and plug an already made ribbon cable into it and the 32-Bit board and everything works.

If somebody knowledgeable about the ARM debugging capability can give us directions for a very cost effective and debugging setup, that would be preferable. It would be nice to have everybody using the exact same debugging setup just because one person might find a problem and need help from somebody else to understand and analyze it. If everybody had the same debug setup, they could say "Set a break point here, and when it triggers look at how this got corrupted."

So... It might be good to hear recommendations for different debug setups. I for one would benefit from that discussion!

Roxy-3D on 31 Jan 2017

So... It might be good to hear recommendations for different debug setups. I for one would benefit from that discussion!

if you really need to know,...

Some Background:

To compile a PC program in C you minimally need a compiler. To debug it you would use a „debugger“. With GCC this would be gcc to compile and gdb to debug. Both are command line tools. Compiling very simple projects on command line is doable, but gets more painful once the project gets more complicated. That is why make and much later all the IDEs have been invented.
For debugging it is much the same situation. gdb has an interactive command line interface, but what you really want is something graphically that sits on top of gdb.

Before we get into that there is a complication with embedded. For compiling it is that we do need to cross compile (we compile on a machine(PC) code for a different machine(AVR)). You need a different compiler, provide a command line switch and that is it.
For Debugging it is more complicated. The debugger must “talk” to the running code. That is where the hardware JTAG thingies come into play. Instead of gdb talking directly to the operating system and the program that runs it now has to talk to the chip using JTAG. The solution is to use a feature of gdb: remote debugging. GDB can be used in a 2 machine setup. With the code running on one machine and another machine is used to debug. In this setup there is a gdb-server, that runs where the program that needs to be debugged runs. And a gdb as client that is the debug interface for the hacker. both gdb's talk to each other. Usually using a TCP connection. In embedded we use a software that implements the gdb-server interface and also implements the JTAG interface. So the setup is

gdb → gdbserver and JTAG app → JTAG box → target board.

There is a small problem with this solution and that is that JTAG only defines the way of communicating, but not the what. The result is that JTAG with an AVR (Yes they can do JTAG) is different to JTAG to the Atmel SAM Cortex-M3. And the really bad thing is that The LPC1769 is also different and the STM32 is yet again slightly different. And to make everybody happy we have different JTAG boxes for each one of them.

If we figure all this out then we still have a command line debug interface that needs an exert to use. This brings us back to IDEs. IDES can use gdb to display memory areas (FLASH, RAM) they can interpret that data (show variables and their current values, show the line of code that is currently executing,..) But to do that they need to know about the hardware. In proprietary IDEs that is not a problem. In ATMEL Studio you can just click Debug and everything works. No problem as the IDE knows about AVRs and the project configuration knows which AVR is in use. If you want to work on more than one platform (AVR, Atmel ARM, NXP ARM, TI ARM, ST ARM,..) you either need one IDE for each platform, or one IDE that can work with different platforms. But that universal IDE needs to be configured.

That was the high level overview of the problems we face.

My Debug setup (as you asked):
I use Eclipse with arm-gcc and make to compile.
I use Eclipse, arm-gdb, st-link and the ST discovery board(the included USB-JTAG thingi).

My recommendation would be:
We have people that want to work on Mac, on Windows and on Linux. To fulfill the “everybody has the same debug setup” requirement we need something that runs on all three. We will also need something that can be configured to run with different chips and probably also different JTAG boxes. For these reasons I would recommend Eclipse. But I’m open to other IDEs that fulfill these requirements and are free open source.
Also gdb should be part of the default debug environment.
As all the gdbserver-Jtag software parts implement the same interface we probably can get away with people using what suits them best. I would only recommend something like openocd. But basically with a default IDE we could just provide configuration setting that works with what people are actually using.
The same for the hardware boxes. Provide documentation and settings for what the developers are using and recommend to not introduce new things.

As always that is just my opinion, others will disagree. I just provide this as input with the hope that it can help others.

JustAnother1 on 31 Jan 2017

Thank You very much for that information. It is probably too optimistic to think we can get one universal debug setup. If we have to make compermises, the first thing to give up would be trying to support multiple platforms with the same setup.

But for sure, GDB is part of the equation. And the ST-Link hardware interface is available on eBay for just a few dollars!

I can hardly wait to have a real debugger available where I can set break points and dump memory!

I have a question: Can we use ST-Link and GDB with the AVR's ? In particular with the AtMega-2560 ? If we can, I'll start trying to get that setup right now on a printer!

Roxy-3D on 1 Feb 2017

If we have to make compermises, the first thing to give up would be trying to support multiple platforms with the same setup.

Probably everybody agrees on this as long as they think the platform you are giving up is not theirs. If you give up on my platform then you give up on me!

I have a question: Can we use ST-Link and GDB with the AVR's ? In particular with the AtMega-2560 ? If we can, I'll start trying to get that setup right now on a printer!

That was the part of JTAG not standardize on what is send, only how it is send. The ST only works on ST, the Atmels only work on atmels,.. In the ARM class there are some (like Segger J-Link) that work on all ARMs.

For the older AVRs the cheapest solution are the JTAG ICE mk1 clones. At that time Atmel released the schematic for that debugger. Atmel Studio updates the firmware so clones became very popular. Atmel then raised the price of the new JTAG ICE mk2 debugger and made newer chips only supported on the mk2. The did nor release the schematics for that. They then even had an mk3 that I think was even more expensive. But they now have the "Atmel-ICE" so no mk and no number anymore. The good thing is you can get the PCBA only (PCBA = assembled PCB). The box is rather expensive, and I think you might have a 3d printer handy, right? I would recommend to buy the cable kit too. It is expensive but soldering wires to the tiny connectors they use on that is really not funny. The additional benefit is that it also supports the Atmel ARMs. Big downside is that, if I remember correctly, only Windows is supported. Also if I remember correctly for the mega2560 you will need at least the mk2, so the best choice right now would be the Atmel-ICE.

Then if you or somebody else wants to get their hands dirty: OpenOCD supports the Bus Pirate (extremely cheap hardware than can also do other cool things) and other open hardware boards. So getting the AVRs supported is probably just a matter of (a hell lot of) coding.

As Atmel is now part of Microchip things might change,... If someone knows a Microchip Representative closely, maybe ask if the Microchip Mega2560 is supported by PICkit3? Or maybe we want to get this board supported(sorry only German web site:
https://www.conrad.de/de/entwicklungsboard-digilent-410-202-1526972.html

JustAnother1 on 1 Feb 2017

I have the Re-Arm in my hot little hands. It's really a nice looking board. I'll start working with it this coming weekend and see how everything performs.

I feel like the re-organized file structure and breaking up the source code more (for Marlin 1.2.x) is going to help a lot with having a unified code-base for AVR and 32-bit. Then we can have an AVR version and 32bit version of some class where we make use of its extra I/O and other goodies.

thinkyhead on 15 Feb 2017

👍1

Does anyone know if the Re-Arm, or rather the LPC1768, has an FPU? I tried looking from the datasheet but couldn't find anything.

teemuatlut on 15 Feb 2017

It's a Cortex-M3 so it has no FPU.

thinkyhead on 15 Feb 2017

👍1

The ShieldBuddy TC275 has three floating point units!

hitexuk on 15 Feb 2017

Hi Guys, been looking for a 32 bit version of Marlin and came across this https://github.com/MarlinFirmware/Marlin/tree/32-Bit-RCBugFix-new
but does not compile for Due/radds without error :- (using Arduino v1.6.12)

In file included from sketch\MarlinConfig.h:26:0,
from E:\3D printer info\~MTW Create\Marlin-32-Bit-RCBugFix-new\Marlin-32-Bit-RCBugFix-new\Marlin\Marlin.ino:31:
sketch\fastio.h:31:20: fatal error: avr/io.h: No such file or directory
#include <avr/io.h>
                    ^
compilation terminated.
exit status 1
Error compiling for board Arduino Due (Programming Port).

Is there another version for Due? and does this firmware function properly with Dual X axis Cartesian printer.

Thanks and regards - Bruce

bruce356 on 4 Mar 2017

@bruce356 is part of avr-libc. Have you installed that and does the compiler know where to find it? (I don't know if Arduino takes care of this,..)

JustAnother1 on 5 Mar 2017

JustAnother1, thanks for the reply, the file is where I think it should be :-

C:\3D Printing\Arduino v1.6.12\hardware\tools\avr\avr\include\avr\io.h

The Due uses Atmel SAM3X8E ARM Cortex-M3 CPU so why would arduino compiling look for AVR?
Is the Marlin firmware I downloaded for the 32 bit chip or not.
Regards - Bruce

bruce356 on 5 Mar 2017

Is the Marlin firmware I downloaded for the 32 bit chip or not.

Yes. But it is not fully cooked. There is broad based support from the community to get Marlin running on a 32-bit processor. This is an attempt to get RC-8's RCBugFix up and running on a 32-bit processor. Right now, only serious developer types can benefit from what is in place.

Roxy-3D on 5 Mar 2017

@bruce356 Sorry. I should have read your post more closely.

Congratulations: You have found a bug! ;-)

avr/io.h defines all the special function registers for the Pins on the AVR. The Due must have something similar. So the include has to be adopted to that. For AVR Targets this include is needed for other targets a different include might be needed. A first approach could be to have this include only in the AVR part. That should get the Due compilation going further. If the due requires another import then the compiling will fail at a later time. If you can fix it please send the code back to this project.

JustAnother1 on 5 Mar 2017

Hi JustAnother1, I am glad you were able to determine that its a bug but unfortunately I am not able to rectify this, I am a user not a programmer.
Thanks and regards - bruce

bruce356 on 7 Mar 2017

Hi, what do you think about Arduino Star Otto? can marlin run on this platform? sorry for my english

fonst3r on 25 Mar 2017

The Star Otto could be a superb board, but looks to me like a dead child.
It's still not available.
The testbranch for the IDE at Arduino.org disappeared during the reunion with Arduino.cc.
So likely we have to wait for an other year, or maybe for ever.

AnHardt on 25 Mar 2017

I have seen (and even touched) a prototype. The (ST) guys say that there was a problem with one of the connectors. Therefore they had to switch to another connector. That should have been the reason for the delay. First 200 Prototypes are done now and mass production has started. Availability is planed for end of April.

Then you will have the same problems with it as with the Arduino Due (it is 3.3V). You can not just stick every old RAMPS on it. It is also a different processor to the Due. Marlin has a lot of AVR specific stuff that it is doing besides the Arduino Libs. So even with 100% support for all Ardunio Libs with the Star OTTO marlin will not run without some adoptions.

The marlin that will run on Star Otto will be the 32-Bit-RCBugFix* Branch. And thats not really making much progress at it seems. We will see what happens first: a working Marlin 32bit or the Star Otto Hardware,...

JustAnother1 on 25 Mar 2017

@bobc , any chance you'll come back on board with the 32Bit support for Marlin?
I was looking at the work you've done with bootem.
https://github.com/bobc/bootem

If i understood correctly, we should be able to load this on an Arm or LPC17xx chip to read the firmware on an SD card and automatically flash it?

Let me know if i can do anything to help test it out, or even attempt at developing.
Unfortunately, C++ development and developing for microcontrollers have never been my strong points, however, I'm learning from everyone in this community.

psavva on 2 Apr 2017

Do you check this Marlin fork for 32bit? I think it was continued from last 32bit Marlin. It has a web configurator and also you can import your old config file to Port it easy to the last version. It seems to have all the last Marlin features and support due board. Check it !

moracabanas on 25 May 2017

https://github.com/MagoKimbra/MK4duo

moracabanas on 25 May 2017

Hi,

I have ported the MK4duo_30-05-2017_122250 to the ShieldBuddy board (Aurix processor) for RAMPS1.4. I am not really able to test this properly but there are comms on the serial port and the stepper and temperature interrupts are running. Are there any willing volunteers out there who would be able to test it for real?

Cheers

hitexuk on 19 Jun 2017

👍1

The ShieldBuddy board is very interesting. In a couple weeks we expect to have a 32-bit processors hooked into the main code base: https://github.com/MarlinFirmware/Marlin/issues/7076#issuecomment-309332564 That doesn't mean they work and do everything. But it will give people working on 32-bit issues the ability to always be making progress against the main code base.

High Level Information on the ShieldBuddy board can be found here: https://shop.hitex.co.uk/collections/boards-and-modules/products/aurduino-the-worlds-most-powerful-arduino

In a couple of weeks... We will be in a position for you to do a Pull Request that adds a folder for a ShieldBuddy HAL.

Roxy-3D on 19 Jun 2017

👍1

@hitexuk meanwhile if you can do a pull on mk4duo github I try it .. Thanks!

MagoKimbra on 19 Jun 2017

@hitexuk Agreed... Can we take a look at your work? Making a Pull Request against MagoKimbra's branch would be very valuable. (MagoKimbra's file organization did provide a big inspiration to us. )

Roxy-3D on 19 Jun 2017

@Roxy-3d do you see last version MK4duo?
I have created class for mechanism (cartesian, core, delta, NO SCARA for now), bedlevel, probe...
Look https://github.com/MagoKimbra/MK4duo/tree/master/MK4duo/src

MagoKimbra on 20 Jun 2017

👍1

No, I just looked at it now. That type of class structure will be valuable for further clean up of the code. I wasn't kidding when I said:

MagoKimbra's file organization did provide a big inspiration to us.

Soon, when we catch up... You can spend your time here helping us further refine things! :)

Roxy-3D on 20 Jun 2017

👍1

Hi,

I have put the Aurix port at:

http://www.hitex.co.uk/fileadmin/uk-files/downloads/ShieldBuddy/MarlinMk4DuoAurix.zip

PortingNotes.txt

This gets the serial comms working and the stepper and temperature interrupts. I know very little about the Marlin SW so my main contribution is the embryonic HAL_Aurix! Unlike the original SW, the ShieldBuddy version uses a lot more of the Arduino environment but on the ShieldBuddy this is generally a lot faster than any other Arduino so there should be no performance penalty.

It would be great if one of you experts could check what I have done. It is likely that the interrupts are running at the wrong speed but this is easy to fix.

Cheers

hitexuk on 20 Jun 2017

Just thought I would chime in here.
I have been thinking about building 32-Bit based 3d printer for the last few months so I am quite excited there is movement on this here. (didn't see this thread till now)

STM32 now has official support in the arduino ide. (ST supported)
http://www.stm32duino.com/
https://community.st.com/community/stm32-community/blog/2017/06/02/stm32-cores-enabled-in-arduino-ide
So this should make it a bit easier to have an stm32 based solution that a normal user can configure the firmware for, build and program without much issue.
I believe this arduino port is built on top of the stm cube hal files. This should make it relatively easy (i think) to take the Marlin4ST firmware and directly compile it with the arduino environment..? (i think)

For development, using a gcc based make environment with either CLI or eclipse or similar would probably result in the quickest development.
When debugging on stm32 processors I find that SWD is all that I need. This is only 2 pins (SWD/SWCLK), however we often also add the SWO line so that we can do tracing, with the likes of stm-studio.
ST-Link clones around at super cheap prices, plus the nucleo/dev board coming with ones that you can also use to program other boards.
However the debuggers from segger are a much better experience, even if they are a bit more expensive.

I personally use the STM32 processors at work every day, using the stmcube as the HAL library and then and eclipse gcc combo. The standard ST hal makes it super easy to go between different processors in the same family (eg f429 to f469) and also minimal changes required to go between families (eg F0 to F3)

Let me know if there is any more information I can help with, or any questions you guys have which you think I can answer, let me know.

lucazader on 21 Jun 2017

Everybody in this thread cares about 32-Bit processors and how they can help Marlin. Please read: https://github.com/MarlinFirmware/Marlin/pull/7028#issuecomment-310880218

Roxy-3D on 25 Jun 2017

Such good news Iv been looking for this in so long time but does anyone knows on which boards right now can 32 bit marlin code can be run ? Cheers
Edit: can 32bit marlin run on this

vido89 on 20 Sep 2017

Edit: can 32bit marlin run on this? (Due)

@vido89 Yes it can! It requires a RAMPS4DUE for full functionality. It should work great with the latest Marlin 2.0.x at https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x

thinkyhead on 4 Oct 2017

👍1

@vido89 Right now, in the #7076 thread we are mostly using Re-ARM with a RAMPS v1.4 board. Some of the people are printing. Others of us still have some issues that are being worked through. But the code is starting to work in 32-bit mode.

Roxy-3D on 4 Oct 2017

@thinkyhead Thank you for update awesome news Im looking forward on getting started on this.
@Roxy-3D Whats is Re-ARM is it a board for RAMPS v1.4 or is it project for running Marlin on non-arduino based boards ? Tnx guys :)

vido89 on 4 Oct 2017

Yes... It is a 32-bit LPC1768 processor running at 100 MHz (I believe... didn't look it up.) It pretty much allows a RAMPSv1.4 board to plug in and drive a printer. That is what most of the people in the #7076 thread are using but people are starting to spread out to STM processors and LPC1769 processors.

There are a few hiccups with the Re-ARM boards because not all of the pins are brought through to the RAMPS pins. And the LCD Displays need a +5 volt power signal they can't get from the RAMPS board when it is powered by a Re-ARM. But pretty much, you can unplug your Atmega-2560 board and plug in the Re-ARM board on a printer equipped that way. (That is what did with my Folger-Tech i3 2020)

You can get a Re-ARM board here: http://www.ebay.com/itm/Panucatt-Devices-Re-ARM-Controller-for-RAMPS-ReArm-/322420041760?var=&hash=item4b11bb6820:m:mb275lkSYJQsqPP1TNKoyWQ or here: http://www.panucatt.com/Re_ARM_for_RAMPS_p/ra1768.htm

The biggest reason to use Re-ARM is it is probably the most 'supported' 32-bit platform for Marlin right now. Not everything is working perfectly right now. But issues are being put to bed and more and more of the configuration.h options are starting to work correctly on the Re-ARM board.

Roxy-3D on 4 Oct 2017

Awesome awesome @Roxy-3D thank you for all info I hope that other people find it useful
Edit: Which display they using I was assuming RRD GLCD but appears its different ?
Edit2: It cant be PanelDUE right ?

vido89 on 4 Oct 2017

Which display they using I was assuming RRD GLCD but appears its different ?

The Re-ARM board works easiest with the Rep Rap Discount Graphical LCD. In that case, there is a single wire that is cut out of the ribbon cable and sent to +5 volts. But I'm doing my work with a Re-ARM board that has a 20x4 Character LCD display. And besides needing 5 volts, I have some signal wires that are stealing signals from the unused Ethernet port on the Re-ARM board. Somebody else (Bob-the-Kahn or p3p did the actual work to get that display going. But it works on the Re-ARM just fine after routing the signals to the right place.)

Roxy-3D on 19 Oct 2017

👍1

Does your LCD cardreader work?

karabas on 3 Nov 2017

I haven't checked that out yet. My guess is that it will work better than the Graphical LCD SD Card just because the 20x4 character displays don't have the same hardware bug with shared SPI signals. And also, the 20x4 LCD's are grabbing their signals from a different place anyway.

Next time I build the firmware, I'll try to remember to turn the SD Cards on and I'll see what happens.

Roxy-3D on 3 Nov 2017

@Roxy-3D @thinkyhead regarding the "Cohesion3D ReMix" board
31 jan 2017 by Ray Kholodovsky @bobc:- I've already sent @Roxy-3D (2) boards for herself and ThinkyHead),
Is there any chance that this board might be included in Marlin2, very soon.
Any idea how long before v2.0 will be ready for release.
Thanks and regards - bruce

bruce356 on 3 Dec 2017

Cohesion3D Remix - nice card - LPC1769 based with 6 drivers and lots of features. A bit pricey for my tastes.

It'll be a while before things like the WIFI and Ethernet modules are supported by Marlin.

I just ran across the LPC1778. More I/O pins and lower cost than the LPC1769/17678 along with EEPROM.

Bob-the-Kuhn on 3 Dec 2017

There are people trying to get the LPC-1768 work modified for the LPC-1769 right now. It is all volunteer effort and it takes time to get things accomplished.

Roxy-3D on 3 Dec 2017

@Roxy-3D , thanks
@Bob-the-Kuhn and others, I am not worried about Ethernet (most people probably would not require it, I do not) as WiFi is easier and more flexible (no Cables), I use Raspberry Pi3 Octopi with wifi on all my printers so those features would not worry me, but if the main important basic printing functions can be made to work that would be enough.
Thanks to all working hard to make this a reality.
Regards - bruce

bruce356 on 3 Dec 2017

I am looking into doing a port so just reading through, you mention in a different thread that there is no eeprom on the due but what about a board like the old davinci's where the eeprom is stored on the sd card? The repetier port works great in storing the eeprom there, but just seems like marlin is surpassing so just curious.

S1CAR1US on 31 Dec 2017

@S1CAR1US I know that the Re-Arm board has no EEPROM, it was therefore emulated on the internal SD Card of the board. It works quite well.

psavva on 31 Dec 2017

I purchased three Re-Arm boards from KickStarter and I'm willing to donate two of them to developers to further the cause.

Re-Arm for RAMPS - https://www.kickstarter.com/projects/1245051645/re-arm-for-ramps-simple-32-bit-upgrade?ref=user_menu
also can be purchased through Panucatt at http://www.panucatt.com/Re_ARM_for_RAMPS_p/ra1768.htm

If interested PM me and I will mail them to you. Eager to see Marlin move into the 32-bit world.

r,
Doug W

dcwalmsley on 11 Jan 2018

@dcwalmsley - https://github.com/MarlinFirmware/Marlin/pull/5357

fiveangle on 11 Jan 2018

What about smoothieboard?

G-Pereira on 18 Jan 2018

Has anybody considered ESP32 ? Sure it has less usable pins but enough for a single extruder, i think. ESp32 is almost 10 or more times powerful than Due, even without FPU. It is also possible multiple Esp32 can synchronize.

alfredanil on 18 Jan 2018

@alfredanil The ESP32 Is a very powerful micro for sure. Dual core 240MHz with an FPU.
However it just does not have the number of GPIO required for a basic configuration.

Sure an I2C or SPI I/O expander would help with this.
But at that stage it is probably easier to just use a Due, or an STM32 or similar.

lucazader on 18 Jan 2018

Well, Esp32 can compliment a Due or STM by adding Wi-Fi and Bluetooth capabilities. It can run the more computation intensive part of firmware like velocity ramp generation especially the more complex S-shaped velocity ramp with fifth order polynomial. It can also run a webserver for host and configuration setup. Possibilities with Esp32 are endless.

alfredanil on 18 Jan 2018

I promised @Roxy-3D to not to comment on marlin anymore. Therefore just this link(regarding esp32): http://forums.reprap.org/read.php?2,769032

JustAnother1 on 18 Jan 2018

I'm not happy with the LPC1768/69 boards because they're pin limited. I'm hoping to see LPC1778 based boards come out. More I/O pins and lower cost than the LPC1769/17678 along with EEPROM.

I see lots of activity in the STM32 area. So far I haven't seen any low/moderate cost boards based on the higher end chips.

I'd also like to see more than 5 stepper sockets. 5 isn't enough for the higher end printers.

Bob-the-Kuhn on 19 Jan 2018

I'm not happy with the LPC1768/69 boards because they're pin limited. I'm hoping to see LPC1778 based boards come out. More I/O pins and lower cost than the LPC1769/17678 along with EEPROM.

Yeah... I wish the Re-ARM board had enough GPIO pins so all of the RAMPS connections had signals going to them.

I'd also like to see more than 5 stepper sockets. 5 isn't enough for the higher end printers.

Agreed. I'm looking for one with 7 or 8 stepper sockets. I want to get a 3 or 4 filament mixing extruder. And that isn't happening with 5 stepper sockets.

Roxy-3D on 19 Jan 2018

@Roxy-3D Ultratronics Pro? 7 stepper sockets and a 32bit MCU.

teemuatlut on 20 Jan 2018

On Cohesion3D ReMix I can rig 8 total stepper drivers by using the pins
from the ethernet module expansion header. There are 6 drivers on the board
by default, the 6th shares signal lines with the status LED pins, and then
there are 8-9 more gpio pins via the ethernet exp header that I can use for
2 sets of drivers, hotends, and thermistors (some mix and match required to
get other analog pins for the thermistors).

In short, it's possible, but I find the 6 driver to already be a limited
market, so I only see it happening as the ReMix with potentially a 2 driver
expansion board.

On Fri, Jan 19, 2018 at 11:37 AM, Roxy-3D notifications@github.com wrote:

I'm not happy with the LPC1768/69 boards because they're pin limited. I'm
hoping to see LPC1778 based boards come out. More I/O pins and lower cost
than the LPC1769/17678 along with EEPROM.

Yeah... I wish the Re-ARM board had enough GPIO pins so all of the RAMPS
connections had signals going to them.

I'd also like to see more than 5 stepper sockets. 5 isn't enough for the
higher end printers.

Agreed. I'm looking for one with 7 or 8 stepper sockets. I want to get a 3
or 4 filament mixing extruder. And that isn't happening with 5 stepper
sockets.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3851#issuecomment-359020053,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG_bGLaW-Q64Fq89ZmQCvN0gmFqILDQKks5tMMS7gaJpZM4Imb5C
.

--
Ray

raykholo on 21 Jan 2018

I am eyeing up the follow cheap STM32F7 dev boards as a target - paired with RADDS; they are now sub $30 USD range and seem like a good target.
https://www.aliexpress.com/item/FREE-SHIPPING-NUCLEO-F767ZI-STM32F767ZI-Development-board/32855944181.html

ESP32 is also worth looking at I see a HAL was contributed the other day. Unfortunately the esp32's I have lying around don't have all the pins broken out so are not a good candidate.

aenertia on 15 Jun 2018

here is a 3d printer that use the latest marlin on stm32f103. and has developped a tool just for compile and upload. it is easy and so simple.

https://hackaday.io/project/160709-the-first-3d-printer-with-marlin-on-stm32-board

hackaday3D on 21 Sep 2018

@hackaday3D
Sadly he copied Marlin, instead of forking it. So will outdate soon because maintaining is too time consuming.

AnHardt on 21 Sep 2018

…also used the 1.1.x branch instead of the 2.0.x branch. It's a unicorn.

thinkyhead on 28 Sep 2018

@hackaday3D Right now... It would not be difficult to fork the code, and do a diff to find all the changes you made to get this to work. But if that is not done, there won't be a way to track changes and keep your code current.

Roxy-3D on 28 Sep 2018

I found that the 1.1.x branch is great and very stable, so when port 1.1.x code to stm32 I changed the code as little as I can, just copy :)

hackaday3D on 29 Sep 2018

I'm going to steal all your good ideas for STM32 that we might have missed, but we'll have to adapt them to our HAL system and make them play nice with the other HALs.

thinkyhead on 29 Sep 2018

I am eyeing up the follow cheap STM32F7 dev boards as a target - paired with RADDS; they are now sub $30 USD range and seem like a good target.
https://www.aliexpress.com/item/FREE-SHIPPING-NUCLEO-F767ZI-STM32F767ZI-Development-board/32855944181.html

ESP32 is also worth looking at I see a HAL was contributed the other day. Unfortunately the esp32's I have lying around don't have all the pins broken out so are not a good candidate.

https://www.mouser.com/ProductDetail/STMicroelectronics/NUCLEO-F767ZI?qs=sGAEpiMZZMv0WPLDnYsI79VyEGU7o4m%2f3QnSSCyRl88nt%2fLYMmnI2g%3d%3d

SuperMarcus on 8 Oct 2018

I am eyeing up the follow cheap STM32F7 dev boards as a target - paired with RADDS; they are now sub $30 USD range and seem like a good target.

Yeah! I need 6 stepper motors. This would be the ticket in the 32-bit world.

Roxy-3D on 16 Oct 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

github-actions[bot] on 6 Aug 2020

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

github-actions[bot] on 5 Oct 2020

Marlin: Recommendations for a good 32 bit microprocessor to run Marlin

Most helpful comment

All 475 comments

Availability

Toolchain/IDE

Price

Existing 3D Controllers

Conclusion

define ULTRA_LCD // Character based

define INDIVIDUAL_AXIS_HOMING_MENU

define RADDS_DISPLAY

Related issues