Status of DUE&RADDS support

dc42

When Dan did the RADDS port, my fork didn't have code for accessing SD cards over SPI, but it does now. So it makes more sense to define those parameters (except for RADDS) in the Pins_RADDS file, just as they for the Duet and Duet WiFi. I already put most of them in Pins_RADDS,h except for the ones I didn't know the values for.

I think you should be able to use the CoreNG SAM3X build from my githib repo as-is for RADDS, except that you will need to change variant.cpp and variant.h to set up the pins appropriately.

dc42

PS - I've updated my copy of CoreNG with Dan's copy of variant.cpp and variant.h, ma de a few other changes, and now I can actually build a RADDS version of CoreNG. I'll commit it to GitHub tomorrow when I have tested that I haven't broken anything in the Duet builds.

mb0

thanks! i'll have a look at it when i'm back from very short vacation!

you are right after writing my post i realized that these defines should go into a header instead.

there are only a few other mentions of RADDS in coreng. One is in AnalogIn.cpp line 94:

[[c]]
#if SAM3XA
#ifdef __RADDS__
			if (ADC_TEMPERATURE_SENSOR != GetAdcChannel(channel))
#endif
				adc_enable_channel(ADC, GetAdcChannel(channel));
			if (GetAdcChannel(channel) == ADC_TEMPERATURE_SENSOR)
			{
				adc_enable_ts(ADC);
			}
#endif

1st i disklike nested #ifdef whatever, this makes everything unreadable. 2nd yoda style (ADC_TEMPERATURE_SENSOR != GetAdcChannel(channel) is a no no.
however i'm asking myself if this is actually needed because in any case it would call adc_enable_ts if needed. in the RADDS case not calling adc_enable_channel
before then. so either there is a bug when doing this when using the radds board or it is not neccessary and can be forgotten.

if your time permits you might want to look into SharedSpi.cpp as well. in dcnewmans fork are a 2 more #ifdef's for the RADDS case in lines 186 and 386

[[c]]
#if defined(USE_SAM3X_DMAC) && !defined(__RADDS__)

you know better than me if these are necessary or not facing the current implementation. Afaics, these were the only changes to the actual source which depend
on anything radds related. if so coreng would be radds safe after your changes.

i looked at the radds schematics and think that using a small adapter pcb the esp could also be connected to spi and the sdcard rewired to the hsmci port. thus
enabling high speed uploads there as well (preventing however the use of an lcd but not serial panel or whatever).

dc42

I've checked everything in. The RADDS version builds but I haven't tested it.

The change to AnalogIn shouldn't be needed, because the RADDS version of RRF shouldn't ask to use the temperature sensor channel.

The changes to SharedSpi are because he got it working under DMA, but my build doesn't use DMA for the shared SPI. I think I left the sspi_start_transmit and sspi_start_receive functions there so that he could use them, but he seems to be calling spi_start_transmit and spi_start_receive instead, and I don't know where he defines those. You may find that it works OK without using DMA anyway, although using DMA would be preferable because on the RADDS all SD card access goes over SPI.

mb0

managed to build the RADDS flavour as well. There were some minor quirks (arm-*-objcopy was unable to locate the .elf because the path to it is wrong objcopy -binary /RepRapFirmware.elf /RepRapFirmware.bin) i checked the eclipse settings but they seamed correct. Anyway, did it by hand. Ahh and i switched from external make
to internal build tool in eclipse. Maybe you can change this setting as well in the project file to reduce one more error one can have. I copied the gcc from my arduino install
to the directory you have in the eclipse config, so in the future i don't have to touch this settings (at least under windows).

to use bossa (under Tools/Windows) you need to set the corresponding COM port to 1200 baud. This is done using the command
[c]mode comN:1200[/c] where N is the port number of the due. under linux you do [c]stty -F /dev/ttyACM0 1200[/c].

The target binary of RRF for RADDS should be renamed to RepRapFirmware-RADDS.bin for clarity.

After uploading the firmware to the due i could connect to it using pronterface and issue some commands. It seems that only the external SDCard
is working, maybe some configuration issue. I couldn't test the full deal because i ran out of time. Will do tomorrow. Just wanted to drop a quick note…

dc42

@mb0:

…. It seems that only the external SDCard is working, maybe some configuration issue....

Does RADDS support 2 SD card sockets then? I only allowed for one in the Pins.h file.

StephenRC

The RADDS has a microsd card slot and a SD extern connector that's used by the lcd sold for it.

dc42

Ok so you need to change the SD cards section of thea RADDS pins.h file to define both cards. If the external card is working, then I suspect that the CS pin in the existing definition is for the external card however the CD pin may be for the internal card. You can use the M122 command to see the state of the CD pin, from that you can work out which one it is.

mb0

thanks, there are two chip selects (CS0 and CS1), the CD (card detect) is shared between both.

http://www.dr-henschke.de/LCD_Enc_SD_12.pdf

i think the default config for RADDS should use the onboard SDCARD slot because one can not expect the lcd (which is not supported) to be connected.

dc42

Do you know what the pin assignments are for CS0 and CS1?

bruce356

Hi, I am not a technical person, wondering if I could use the firmware that you are working on here for my dual x carriage Cartesian (Mendel) printer with Due/RADDS. I would probably require a bin file as I know nothing about compiling this type of firmware.
Thanks and regards - bruce

mb0

CS0 -> Arduino Pin 10 -> SAM3X PA28/PC29 -> Physical 102
CS1 -> Arduino Pin 4 -> PA29/PC26 -> Physical 137

btw. the printer is running now for >4h without any issues (related to the firmware).
the current setup is RADDS&RAPS128@1/128 0.9 stepper for x/y. z@1/32, extruder@1/16.
24V. It can't go full speed at this microstepping rate. i noticed some "pauses" when printing
large rounded corners. it seems that braking after travel movement is quite aggressive, i get
strange sounds as if the hotend would have bumped into the print.

edit: after setting the raps to 1/32 for all steppers the bumping is gone. is suspect planner
errors because out-of-time situations.

dc42

@bruce356:

Hi, I am not a technical person, wondering if I could use the firmware that you are working on here for my dual x carriage Cartesian (Mendel) printer with Due/RADDS. I would probably require a bin file as I know nothing about compiling this type of firmware.
Thanks and regards - bruce

RRF 1.16 and later support multiple X carriages in the standard binaries. See https://duet3d.com/wiki/Configuring_multiple_independent_X-carriages_on_a_Cartesian_printer. So if someone produces a stable RADDS build of 1.16 or 1.17, you should be able to use the binary.

dc42

@mb0:

CS0 -> Arduino Pin 10 -> SAM3X PA28/PC29 -> Physical 102
CS1 -> Arduino Pin 4 -> PA29/PC26 -> Physical 137

btw. the printer is running now for >4h without any issues (related to the firmware).
the current setup is RADDS&RAPS128@1/128 0.9 stepper for x/y. z@1/32, extruder@1/16.
24V. It can't go full speed at this microstepping rate. i noticed some "pauses" when printing
large rounded corners. it seems that braking after travel movement is quite aggressive, i get
strange sounds as if the hotend would have bumped into the print.

edit: after setting the raps to 1/32 for all steppers the bumping is gone. is suspect planner
errors because out-of-time situations.

What were your steps/mm @ 128x ?

I have provisionally changed the SD card section in Pins_radds.h to this:

// SD cards
const size_t NumSdCards = 2;
const Pin SdCardDetectPins[NumSdCards] = { 14, 14 };
const Pin SdWriteProtectPins[NumSdCards] = { NoPin, NoPin };
const Pin SdSpiCSPins[2] = { 87, 77 };

You will also need to change line 73 of asf/conf_sd_mmc ni CoreNG to:

#define SD_MMC_SPI_MEM_CNT			2			// Number of SPI card slots supported

i.e. change 1 to 2.

I think this should address the internal SD card as card 0 and the external one as card 1. Please can you test this. I have assumed that the CD pin of both sockets are wires in parallel, but if the external card has no CD pin then change the second 14 to No Pin, otherwise the external SD card won's work unless the internal SD card is present.

mb0

my steps/mm @ 128x where

[[language]]
M92 X905.414787 Y905.414787 Z1280   ; set axis steps/mm
M92 E152                            ; set extruder 0 steps/mm

mb0

internal sd card working after adding your suggested changes.

for updating i had to use bossac again. i'm afraid but the duetiap from dcnewman did not work. i think
to make the port complete it should be updated to radds as well.

big thanks for integrating radds into mainline! you should post about the progress at reprap forums
maybe more people get interested in the radds port then. (it seems that there are quite a few germans using
radds boards). unfortunately the guy i tried to contact (angelo/max3dprintshop) did not respond.

dc42

The duetiap will probably need rebuilding against the new CoreNG. Is there any difference between the dcnewman source to duetiap and the one in my GitHub repo?

Ideally the SharedSpi interface should be converted to use DMA again, to reduce the CPU load when reading the file being printed from the SD card.

mb0

seem to be no source code changes. only SCons and .gitignore related changes.

mb0

if i interpret the following right then DMA was explicitly disabled on RADDS in dcnewman's repo:

[[c]]
# if defined(USE_SAM3X_DMAC) && !defined(__RADDS__)
	pmc_enable_periph_clk(ID_DMAC);
	dmac_disable(DMAC);
	dmac_set_priority_mode(DMAC, DMAC_GCFG_ARB_CFG_FIXED);
	dmac_enable(DMAC);
# endif

dc42

I think the DMS nice that Dan was using was somewhere else,