Recommendations for a good 32 bit microprocessor to run Marlin

[boelle]

From @Roxy-3DPrintBoard on March 30, 2016 19:59

The Atmel ATSAM3x8e on the Due board is definitely viable. It has the benefit it can plug into the RAMPS or RADDS base board and at that point it is easy to populate it with other needed items like Step Sticks to handle the stepper motors.

But my questions is "What other companies make viable platforms to run 3D-Printers?" Ideally, these microprocessors have good compiler support and can have similar items to the Step Sticks plugged into them.

The best case would be if these other microprocessor boards were compatible with the RAMPS and RADDS boards and could just plug into them.

Copied from original issue: MarlinFirmware/MarlinDev#398

[Roxy-3D]

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.

[ghost]

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

[alexxy]

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

[JustAnother1]

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.

[ManuLST]

@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.

[ghost]

@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).

[Roxy-3D]

@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.

[tcurdt]

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

[Roxy-3D]

...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!

[bobc]

@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.

[Roxy-3D]

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?

[JustAnother1]

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?

[Roxy-3D]

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!

[JustAnother1]

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.

[Roxy-3D]

@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.

[JustAnother1]

@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.

[Roxy-3D]

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!

[bobc]

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]

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.

[Roxy-3D]

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?

[JustAnother1]

@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.

[ManuLST]

@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.

[ghost]

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

[Roxy-3D]

@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!

[bobc]

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...

[Roxy-3D]

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.

[ghost]

@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.

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

[Roxy-3D]

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!

[JustAnother1]

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

[scalez]

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

[scalez]

@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

[Roxy-3D]

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?

[scalez]

@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.

[Roxy-3D]

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

[ManuLST]

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

@scalez A license file has been added.

[scalez]

@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.

[ManuLST]

@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"

[zenmetsu]

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.

[Roxy-3D]

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.

[zenmetsu]

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.

[Roxy-3D]

@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.

[zenmetsu]

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?

[Roxy-3D]

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!

[zenmetsu]

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]

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.

[JustAnother1]

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)

[zenmetsu]

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.

[Roxy-3D]

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

[zenmetsu]

@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/]

[Roxy-3D]

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 !