smoothieware/smoothie2-old

(Deprecated attempt at) A Smoothie firmware port to the Smoothieboard v2 boards.

Overview

Smoothie is a free, opensource, high performance G-code interpreter and CNC controller written in Object-Oriented C++ for the LPC17xx micro-controller ( ARM Cortex M3 architecture ). It will run on a mBed, a LPCXpresso, a SmoothieBoard, R2C2 or any other LPC17xx-based board. The motion control part is a port of the awesome grbl.

Documentation can be found here : http://smoothieware.org/

NOTE it is not necessary to build Smoothie yourself unless you want to. prebuilt binaries are available here: recent stable build

Quick Start

These are the quick steps to get Smoothie dependencies installed on your computer:

• Pull down a clone of the Smoothie github project to your local machine.
• In the root subdirectory of the cloned Smoothie project, there are install scripts for the supported platforms. Run the install script appropriate for your platform:
  • Windows: win_install.cmd
  • OS X: mac_install
  • Linux: linux_install
• You can then run the BuildShell script which will be created during the install to properly configure the PATH environment variable to point to the required version of GCC for ARM which was just installed on your machine. You may want to edit this script to further customize your development environment.

Building Smoothie

Follow this guide... http://smoothieware.org/compiling-smoothie

In short... From a shell, switch into the root Smoothie project directory and run:

make clean
make all

To upload you can do

make upload

if you have dfu-util installed.

Alternatively copy the file LPC1768/main.bin to the sdcard calling it firmware.bin and reset.

Filing issues (for bugs ONLY)

Please follow this guide https://github.com/Smoothieware/Smoothieware/blob/edge/ISSUE_TEMPLATE.md

Contributing

Please take a look at : 

• http://smoothieware.org/coding-standards
• http://smoothieware.org/developers-guide
• http://smoothieware.org/contribution-guidlines

Contributions very welcome !

Donate

The Smoothie firmware is free software developed by volunteers. If you find this software useful, want to say thanks and encourage development, please consider a Donation

License

Smoothieware is released under the GNU GPL v3, which you can find at http://www.gnu.org/licenses/gpl-3.0.en.html

smoothie2-old's Issues

Bambino Disconnecting Serial Communication

So I got the new source to compile and run, and I noticed that more often than not the Bambino will connect to my computer and show up under /dev/ and then after anywhere from 10-25 seconds, it will disappear from /dev/. When it does this, none of the serial communication applications can connect to it. I had added a few printfs() to the source, so I removed those thinking they might have been causing the issues somehow. Removing these did nothing, so I tried recloning the whole repo and starting from scratch, with no result. The board used to connect successfully and hold a serial communication line one out of every few tries, but now it fails on every try. I've tried switching USB cables, switching USB ports, flashing different file formats (Hex and bin), and don't know where to go from here. Also, when using a simple application(like blinking the lights on the board), the board stays connected to the computer, so I'm pretty sure it isn't an issue on my computer.

Trying to connect to serial port Bambino Bambino 200e

Hi,
I have a Bambino 200E and am able to compile the current Smoothie2. When I look in the Kernel I see that it starts this->serial = new SerialConsole(P3_4, P3_5, 9600) I'm trying to work out where P3_4 and P3_5 end up on the Bambino. Looking at the Bambino pin aliases XLS here http://wiki.micromint.com/index.php/Bambino_Documentation I don't see these pins. I tried hooking up to UART0_RX and UART0_TX at 9600 but Pronterface just says "Connecting....." forever. I've tried looking at the schematic http://www.micromint.com/updates/bambino/SCH-BAM200-B.pdf I see the pins labeled P3_4 and P3_5 but I can't work out how these map to the gadgeteer ports.
I'm updating the bambino using:
boot_lpcscrypt
lpcscrypt program ./LPC4330_M4/Smoothie2.hex SPIFI

Should that be the bin file I flash? I get no leds after flashing either file. I can flash the demo blink file using lpcscrypt so that part seems to be working.
What should I try next?

Endstops are not working

This is to document the issue and to cover off its resolution.

Issue: The endstops are not triggered during G28 Home.

Scenario: Using a FirePick Rotary Delta and the latest Smoothie2 code base, SilentStepStick at 256 microsteps and 400 step stepper motor.

Investigation:
(1) Using GDB and Segger's JLink I have determined that the loop in 'wait_for_homed' method gets executed only once despite having a endless loop that only exits when 'running' becomes false. It never gets back to the 'while' statement to go repeatedly until it detects the endstop(s) are triggered. Sometimes it only gets as far as the 'THEKERNEL->call_event(ON_IDLE);' statement and never returns to the 'wait_for_homed' code at all.
(2) I am wondering if Smoothie is not able to generate the step rate of some 102400 pulses per revolution for the configuration I have, and therefore does not have enough capacity to run all the other 'tasks' as the interrupt rate could be very rather high for the StepTicker.
(3) Options:
(a) Substantially reduce the resolution of the StepperMotor to (say) 16 microsteps to see if it now works; if this is the case the consider the following:
(i) Migrate the endstops code to use interrupts on the endstop pins rather than polling them, this would include the debounce feature; I have done this for other real-time motor control systems as I have found polling to be too problematic at high work loads. I Note that the MBED interrupt feature for PIN may be too heavy and I may need to write my own ISR to keep it as fast as possible.
(ii) Consider migrating the Step generation and enstops code to the M0 processor, but note that it does not appear to have a SysTick timer on that core.
(iii) Consider moving the endstop code into the StepTicker code so that each time a stepper motor is sent a pulse, the endstop is checked (either the pin itself polled, or a flag set by an interrupt from the pin)
(b) Implement Segger's SystemView code analyser to obtain actual metrics for time spent in interrupts and how often they are occurring (I am part of the way through this but I cannot get the SystemView application to connect to the Smoothie2 target, need too resolve this).

Thoughts?

Cheers
Douglas

Pin map does not reflect LPC4330

I have been trying to work out why my code would not support SPP0 and in particular SPP0_SCK pin which is on P3_0.

After a lot of code research I think that link 65 in libs\Pin.cpp is the issue:

map<int, PinName> pins = {{(0x00<<8)+0,P0_0},{(0x00<<8)+1,P0_1},{(0x01<<8)+0,P1_0},{(0x01<<8)+1,P1_1},{(0x01<<8)+2,P1_2},{(0x01<<8)+3,P1_3},{(0x01<<8)+4,P1_4},{(0x01<<8)+5,P1_5},{(0x01<<8)+6,P1_6},{(0x01<<8)+7,P1_7},{(0x01<<8)+8,P1_8},{(0x01<<8)+9,P1_9},{(0x01<<8)+10,P1_10},{(0x01<<8)+11,P1_11},{(0x01<<8)+12,P1_12},{(0x01<<8)+13,P1_13},{(0x01<<8)+14,P1_14},{(0x01<<8)+15,P1_15},{(0x01<<8)+16,P1_16},{(0x01<<8)+17,P1_17},{(0x01<<8)+18,P1_18},{(0x01<<8)+20,P1_20},{(0x02<<8)+0,P2_0},{(0x02<<8)+1,P2_1},{(0x02<<8)+2,P2_2},{(0x02<<8)+3,P2_3},{(0x02<<8)+4,P2_4},{(0x02<<8)+5,P2_5},{(0x02<<8)+6,P2_6},{(0x02<<8)+7,P2_7},{(0x02<<8)+8,P2_8},{(0x02<<8)+9,P2_9},{(0x02<<8)+10,P2_10},{(0x02<<8)+11,P2_11},{(0x02<<8)+12,P2_12},{(0x02<<8)+13,P2_13},{(0x03<<8)+1,P3_1},{(0x03<<8)+2,P3_2},{(0x03<<8)+4,P3_4},{(0x03<<8)+5,P3_5},{(0x03<<8)+6,P3_6},{(0x03<<8)+7,P3_7},{(0x03<<8)+8,P3_8},{(0x04<<8)+0,P4_0},{(0x04<<8)+1,P4_1},{(0x04<<8)+2,P4_2},{(0x04<<8)+3,P4_3},{(0x04<<8)+4,P4_4},{(0x04<<8)+5,P4_5},{(0x04<<8)+6,P4_6},{(0x04<<8)+8,P4_8},{(0x04<<8)+9,P4_9},{(0x04<<8)+10,P4_10},{(0x05<<8)+0,P5_0},{(0x05<<8)+1,P5_1},{(0x05<<8)+2,P5_2},{(0x05<<8)+3,P5_3},{(0x05<<8)+4,P5_4},{(0x05<<8)+5,P5_5},{(0x05<<8)+6,P5_6},{(0x05<<8)+7,P5_7},{(0x06<<8)+1,P6_1},{(0x06<<8)+2,P6_2},{(0x06<<8)+3,P6_3},{(0x06<<8)+4,P6_4},{(0x06<<8)+5,P6_5},{(0x06<<8)+6,P6_6},{(0x06<<8)+7,P6_7},{(0x06<<8)+8,P6_8},{(0x06<<8)+9,P6_9},{(0x06<<8)+10,P6_10},{(0x06<<8)+11,P6_11},{(0x06<<8)+12,P6_12},{(0x07<<8)+0,P7_0},{(0x07<<8)+1,P7_1},{(0x07<<8)+2,P7_2},{(0x07<<8)+3,P7_3},{(0x07<<8)+4,P7_4},{(0x07<<8)+5,P7_5},{(0x07<<8)+6,P7_6},{(0x07<<8)+7,P7_7},{(0x08<<8)+8,P8_0},{(0x09<<8)+0,P8_1},{(0x09<<8)+1,P8_2},{(0x09<<8)+2,P8_3},{(0x08<<8)+4,P8_4},{(0x08<<8)+5,P8_5},{(0x08<<8)+6,P8_6},{(0x08<<8)+7,P8_7},{(0x09<<8)+0,P9_0},{(0x09<<8)+1,P9_1},{(0x09<<8)+2,P9_2},{(0x09<<8)+3,P9_3},{(0x09<<8)+4,P9_4},{(0x09<<8)+5,P9_5},{(0x09<<8)+6,P9_6},{(0x0A<<8)+1,PA_1},{(0x0A<<8)+2,PA_2},{(0x0A<<8)+3,PA_3},{(0x0A<<8)+4,PA_4},{(0x0B<<8)+0,PB_0},{(0x0B<<8)+1,PB_1},{(0x0B<<8)+2,PB_2},{(0x0B<<8)+3,PB_3},{(0x0B<<8)+4,PB_4},{(0x0B<<8)+5,PB_5},{(0x0B<<8)+6,PB_6},{(0x0C<<8)+1,PC_1},{(0x0C<<8)+2,PC_2},{(0x0C<<8)+3,PC_3},{(0x0C<<8)+4,PC_4},{(0x0C<<8)+5,PC_5},{(0x0C<<8)+6,PC_6},{(0x0C<<8)+7,PC_7},{(0x0C<<8)+8,PC_8},{(0x0C<<8)+9,PC_9},{(0x0C<<8)+10,PC_10},{(0x0C<<8)+11,PC_11},{(0x0C<<8)+12,PC_12},{(0x0C<<8)+13,PC_13},{(0x0C<<8)+14,PC_14},{(0x0D<<8)+0,PD_0},{(0x0D<<8)+1,PD_1},{(0x0D<<8)+2,PD_2},{(0x0D<<8)+3,PD_3},{(0x0D<<8)+4,PD_4},{(0x0D<<8)+5,PD_5},{(0x0D<<8)+6,PD_6},{(0x0D<<8)+7,PD_7},{(0x0D<<8)+8,PD_8},{(0x0D<<8)+9,PD_9},{(0x0D<<8)+10,PD_10},{(0x0D<<8)+11,PD_11},{(0x0D<<8)+12,PD_12},{(0x0D<<8)+13,PD_13},{(0x0D<<8)+14,PD_14},{(0x0D<<8)+15,PD_15},{(0x0D<<8)+16,PD_16},{(0x0E<<8)+0,PE_0},{(0x0E<<8)+1,PE_1},{(0x0E<<8)+2,PE_2},{(0x0E<<8)+3,PE_3},{(0x0E<<8)+4,PE_4},{(0x0E<<8)+5,PE_5},{(0x0E<<8)+6,PE_6},{(0x0E<<8)+7,PE_7},{(0x0E<<8)+8,PE_8},{(0x0E<<8)+9,PE_9},{(0x0E<<8)+10,PE_10},{(0x0E<<8)+11,PE_11},{(0x0E<<8)+12,PE_12},{(0x0E<<8)+13,PE_13},{(0x0E<<8)+14,PE_14},{(0x0E<<8)+15,PE_15},{(0x0F<<8)+1,PF_1},{(0x0F<<8)+2,PF_2},{(0x0F<<8)+3,PF_3},{(0x0F<<8)+5,PF_5},{(0x0F<<8)+6,PF_6},{(0x0F<<8)+7,PF_7},{(0x0F<<8)+8,PF_8},{(0x0F<<8)+9,PF_9},{(0x0F<<8)+10,PF_10},{(0x0F<<8)+11,PF_11}};

I have not systematically compared this with the LPC4330 chip itself, before I embark on this exercise, am I correct in this assumption?

Note: I realise that I should change to a 'channel' approach as used in max31855.cpp, which for the LPC4330 is:

SPI1_SSEL   P1_5
SPI1_MOSI   P1_4
SPI1_MISO   P1_3
SPI1_SCK    PF_4
SPI0_SSEL   P1_0
SPI0_MOSI   P1_2
SPI0_MISO   P1_1
SPI0_SCK    P3_0

And I think I need a method of changing from 16bit mode to 8 bit mode to support different devices and I probably need to introduce mutexes to ensure they are thread safe for a proper RTOS implementation too.

I am wondering if I should create a wrapper for an SPI object that deals with all these issues so future processor ports will be simpler, not to mention different usage for the same peripheral?

Cheers
Douglas

Merging Douglas' repo with the main Smoothie repo

I have now made a lot of updates, and will be looking to issue a pull request on or before Monday.

Note my code has already been merged with #34 and is current with Smoothie v2 and includes most of the non USB/Ethernet/SD-card functionality.

I need to confirm why the recent changes still do not enable homing, some weird Rotary Delta behaviour and to then test the Z-Probing and I am good to go.

Possible Issues with Compiling for Bambino 210e

I've been trying to get the Smoothie2 source to run on the bambino 210e for about the past 2-3 weeks with no luck. The first sign of an issue is when making gcc4mbed, the compilation of the sample programs fail with the error
No rule to make target "../../external/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0/s110_nrf51822_8.0.0_softdevice.hex".
However, I can still use BuildShell after the failed compilation.
I'm not sure how much this has to do with gcc4mbed but when following the instructions in Smoothie2Notes on how to flash over USB bootloader, the only available memory is SPIFI, so there is no bank A or B available to flash. After flashing the code to SPIFI through lpcscrypt, there is no communication between my computer and the board. This made me think that something in either gcc4mbed or Smoothie2 might not be right for executing from SPIFI. I do know, however, that the board is functioning and able to run code properly from SPIFI, because I have loaded sample programs from dfusec onto the board, and they have run. I also know that my usb ports are not malfunctioning because I've hooked up my old Azteeg x5 mini and it communicates fine.
The only reason I can think of that this is happening is that the gcc4mbed support for the lpc4330(bambino processor) is possibly only good for the lpc4337(smoothie2 board).

Many thanks in advance for any help.

P.S. I forgot to mention I'm running all of this on my mac air running OSX 10.11. I have also tried the ISP loading technique from your notes, but it failed to load code onto the bambino.

Is this project still alive?

There is no updates on blog nor this repo December 2016.
I'm very scared that Smoothieboard 2 never gonna see the sunlight.

Motor control not working

I hooked up some drivers to my bambino 210E board to start testing the firmware step generation.

When I send a G0/1 command the firmwares stops responding and the motors are blocked but do not move.

The G28 command replies "OK" and brakes the motor, but no movement.

I am currently using a Bambino with the virtual com port firmware, and I'm using a JTAG probe to flash and debug.

Has anyone had this problem?