Jump to content

Is there a need for a 100mhz 32bit ARM Controller


jhinkle

Recommended Posts

Posted · Is there a need for a 100mhz 32bit ARM Controller

I just purchased my UM1 in kit form - just shipped today to the States.

I noticed that the controller is 8/16bit Arduino based.

Is there a need/want for a 32bit controller?

I don't mean a RasPI or BeagleBone - but real embedded controller.

Would added speed and resolution improve this machine or is there still a lot of performance headway in the Arduino?

I already have a base design that I use in other projects - it has built in Ethernet and a TCP/IP stack. If there is a real need, I can look into a daughter board to provide the motor and display interface.

Any and all comments are welcome.

Thanks.

Joe

 

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    I think this sounds interesting, though it's probably rather overkill than necessity (the UM1 runs pretty well, even at high speeds...)

    Do you have an estimate in BOM cost? How complex is your main PCB? 4 layers, 6 layers?

    The one huge advantage of an Arduino mainboard is, that it costs some ridiculous 35$ (or something). I've been playing with the thought of making a custom electronics for myself, expecially regarding shortcomins on power supply design, ESD protection, dedicated watchdog IC and expandability.

    Imho it makes sense only if the new electronics are a complete replacement for the UM original electronics including the Ulticontroller. These cost 275 Euros combined, which is a price range that could be matched IF you don't charge anything for the development costs AND you produce them in small series quantity (like 100 or 200 pcs).

    But the most important thing would be that it should be completely open source, just like the original. I'd love to see such a project come to life and would like to participate, and I'd definetly buy some.

    I must admit though that I'm not very experienced on the firmware side of things - I don't think it's trivial to recreate Marlin for a 32bit ARM CPU. It's probably written in C (is it?) so there should be some level of portability, but that's just not (yet) my strong side...

    I know that the Marlin firmware is constantly being improved and debugged, which means that "you" (meaning the guy who makes the firmware in the end) will also have to track that progress and, if necessary, adapt the ARM firmware as well.

    This could become a very time consuming process - time I would probably not have.

    /edit:

    I'm planning on buying a second UM1 kit for my prototyping lab soon, throwing in "a few" upgrades. Improved electronics are definetly on my wishlist...

     

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    There are a few options already out there for ARM based RepRap controllers. Designing the board is only part of the work. Testing, firmware, feature-completeness. That's where the difficulty lays.

    I currently have an ARM prototype laying on my desk at Ultimaker. Developed by Erik vd Zalm. Pretty cool board, lots of cool features. But the firmware is a bit far from finished, and we are looking on how to go forward with this. That's all I can share right now.

     

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    My current direction, for beta, is to have the board connector level equivalent with the Arduino so I can interface with the existing controller board.

    It will provide a much faster cpu (120 mhz), 32bit hardware floating point, USB, ethernet, SD card.

    I'm developing the firmware now so the system control and user interface will be all brand new -- nothing like the current UM1 implementation.

    I've got the X/Y stepper subsystem pretty much done - now working on integrating the extruder control.

    Once done -- I'll test print quality by simple driving the UM with the Arduino or my board and make comparisons.

    Joe

     

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    My current direction, for beta, is to have the board connector level equivalent with the Arduino so I can interface with the existing controller board.

    It will provide a much faster cpu (120 mhz), 32bit hardware floating point, USB, ethernet, SD card.

    I'm developing the firmware now so the system control and user interface will be all brand new -- nothing like the current UM1 implementation.

    I've got the X/Y stepper subsystem pretty much done - now working on integrating the extruder control.

    Once done -- I'll test print quality by simple driving the UM with the Arduino or my board and make comparisons.

    Joe

     

    We have 168Mhz, Ethernet, USB (host and device), MicroSD, TouchScreen LCD, Audio (because we can), TMC260 stepper drivers (which are awesome, as they allow for 256 microstepping)

    All the drivers for the hardware are working, a quick port of Marlin motion planner is working on it. We can read files from the USB with USB drives. We're setting up the firmware so it will be portable across different 32bit platforms. And we're totally re-designing and making the planner modular. We actually had a design session yesterday evening.

    Maybe we can work together instead of side-by-side? We have 3 people working on it right now (me from UM, 2 hobbists)

     

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    Should the network processor and the stepper processor be separated? I'd hate for my print to go slow because I was pressing 'refresh' on the web interface :wink:

     

    Separating the processors increases the BoM, and means you have to think about how to get gcode from one processor to the other - 250K baud serial isn't enough, unless maybe you binary encode your gcode (eg. http://wiki.ultimaker.com/Ultimate_Binary_Protocol).%20However,%20it%20means%20you%20can%20keep%20most%20of%20your%20existing%20firmware%20and%20have%20the%20ARM%20doing%20all%20the%20networking%20and%20display%20updates.

     

    If there's one thing you can be certain of - putting an ethernet interface on anything means you'll need to do lots of security work on the code that works with it (think: IPv6, SSL, etc). I for one would prefer something that has plenty of spare cycles to do that rather than an embedded controller-gone-wild.

     

    Just a thought :wink:

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    This is indeed music to my ears Daid! Sounds really promising :)

    Ethernet is an extremely computation-heavy protocol. But you can just use an Ethernet-controller IC that interfaces to the MCU, sorting out all the overhead and security stuff and just providing a clean UART datastream to the MCU. Or so, that was the plan :)

    We're planning just that with a Cortex M3 MCU, but the priority on that dropped so atm I'm doing something else..

     

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    Hello all !

    I'm new here. Tell me how to contact the administrator of this forum.

    Thanks in advance.

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    Just post anything. I am one of about 5 moderators.

     

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    Should the network processor and the stepper processor be separated? I'd hate for my print to go slow because I was pressing 'refresh' on the web interface :wink:

     

    Separating the processors increases the BoM, and means you have to think about how to get gcode from one processor to the other - 250K baud serial isn't enough, unless maybe you binary encode your gcode (eg. http://wiki.ultimaker.com/Ultimate_Binary_Protocol). However, it means you can keep most of your existing firmware and have the ARM doing all the networking and display updates.

     

    If there's one thing you can be certain of - putting an ethernet interface on anything means you'll need to do lots of security work on the code that works with it (think: IPv6, SSL, etc). I for one would prefer something that has plenty of spare cycles to do that rather than an embedded controller-gone-wild.

     

    Just a thought :wink:

     

    The processing (not stopping printing because of network load) is what a realtime-OS is for. Security is something I'm quite used to programming by now.

    I did a study in embedded realtime systems. I worked for 5 years on the networking and safety parts of high end traffic lights.

    With proper design and coding this can be done.

     

  • Link to post
    Share on other sites

    Posted · Is there a need for a 100mhz 32bit ARM Controller

    What kind of chips/dev boards are you guys using?

    I have a couple http://www.ti.com/tool/ek-tm4c123gxl and was wondering if they would be capable of running Ultimaker 2.

    In terms of processing and memory I think it's much faster, but I think at the cost of some peripherals. They may not be built in, but could they be added externally? I know for sure it has less GPIOs but atm I don't know if Ultimaker is utilizing all 54 of the Mega's or if you really need to sample some of those I/Os all the time (maybe mux some sensors together?).

     

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • Introducing Universal Cura Projects in the UltiMaker Cura 5.7 beta
        Strap in for the first Cura release of 2024! This 5.7 beta release brings new material profiles as well as cloud printing for Method series printers, and introduces a powerful new way of sharing print settings using printer-agnostic project files! Also, if you want to download the cute dinosaur card holder featured below, it was specially designed for this release and can be found on Thingiverse! 
          • Like
        • 10 replies
      • S-Line Firmware 8.3.0 was released Nov. 20th on the "Latest" firmware branch.
        (Sorry, was out of office when this released)

        This update is for...
        All UltiMaker S series  
        New features
         
        Temperature status. During print preparation, the temperatures of the print cores and build plate will be shown on the display. This gives a better indication of the progress and remaining wait time. Save log files in paused state. It is now possible to save the printer's log files to USB if the currently active print job is paused. Previously, the Dump logs to USB option was only enabled if the printer was in idle state. Confirm print removal via Digital Factory. If the printer is connected to the Digital Factory, it is now possible to confirm the removal of a previous print job via the Digital Factory interface. This is useful in situations where the build plate is clear, but the operator forgot to select Confirm removal on the printer’s display. Visit this page for more information about this feature.
          • Like
        • 0 replies
    ×
    ×
    • Create New...