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
seem to be no source code changes. only SCons and .gitignore related changes.
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.
my steps/mm @ 128x where
[[language]]
M92 X905.414787 Y905.414787 Z1280 ; set axis steps/mm
M92 E152 ; set extruder 0 steps/mm
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.
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.
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…
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).
Just another cartesian printer running on DuetWifi. Thanks for making DuetWifi such a great hardware software combo.
M307 H1 A500.0 C200.0 D5.0 B0 S0.8 ; ok but not perfect (needs some time but then very stable)
M305 P1 T4700000 B5253 R4700 H0 L0 ;
https://youtu.be/HhQwN9lb-04
https://youtu.be/Y4AnO_32X9g
nice thanks! when you're at it dcnewman defines the following in SConstruct build file:
[[python]]
if platform == 'radds':
env.Append( CCFLAGS = [
'-D__RADDS__=1',
'-DSD_MMC_SPI_MODE',
'-DSPI_PIN=77',
'-DSPI_CHAN=0',
'-DSD_SS=4',
'-DSD_DETECT_PIN=14',
'-DSD_DETECT_VAL=0',
'-DSD_DETECT_PIO_ID=ID_PIOD',
'-DUSE_SAM3X_DMAC=1',
'-DDMA_TIMEOUT_COMPUTE' ] )
if use_usb_combo:
env.Append( CCFLAGS = [
'-DUSE_USB_COMBO',
'-DUSB_DEVICE_VENDOR_ID=0x2341',
'-DUSB_DEVICE_PRODUCT_ID=0x003e',
'-DUSB_DEVICE_PRODUCT_NAME=\\"Arduino Due\\"',
'-DUSB_DEVICE_MANUFACTURE_NAME=\\"Arduino LLC\\"' ] )
you might want to add these flags as well to the RADDS build configuration. then i can keep a local copy of the .cproject and ignore it (hoping so).
i tried to make sense of eclipse project management and now i am wondering what the canonical way is to maintain the .cproject files. if noticed you added the RADDS build configuration to the firmware part. of course it is also needed in coreng. but unfortunately eclipse maintains paths to arduino gcc stuff in the same .cproject as it maintains build targets. unbelievable i now. thus i can't make clean git patches.
how can we colaborate without these stupid config conflicts? isn't there some kind of user profile overlay for cross toolchains?
thanks! re-indexing fixed the red.
i grepped through dcnewmans coreng and rrf forks. he provides pin configurations in the /RADDS subdirectory.
there are some changes to coreng as well. one is related to spi dual use or something. rest is more or less just jitter.
there is one #ifdef which defines DUET if SAM3X is defined. this logic needs to be revised as well, but this is of
course trivial.
actually he introduced SCons as build system so i guess he didn't bother using eclipse as build platform. this is
unnecessary.
best is i make a fork on github and send a pull request. i think i can start working on it as soon as my dyzend stuff
is working on the duetwifi (it is heating but auto-tune does not work so the pid is very slowly approaching temp,
but then rock solid). i hope i manage to finish the printer by the end of next week.
how is the esp connected to the duetwifi? would be awesome to bolt that onto radds as well.
i tried to contact a RADDS supplier but did not get a response so far. i've seen him posting about RRF on another forum so i thought he might be the right person to ask.
for now i can try to get it working on one of my spare boards. since i never used eclipse for anything serious i'm wondering how i can change the build configuration to set the RADDS preproc define. setting "SAM3x_CoreNG" as active build config doesn't seem to define RADDS. i could set it manually but that can't be the right way to do it 
.
another thing i'm facing. eclipse (mars) manages to build the firmware but the ui part is not able to resolve the headers and everything is underlined red 
this are the times i miss good'ol'makefiles and vi.
thanks, mind sharing your parameters for the default stuff? i got pid tuning to start after several tries but then complains about temperature overshooting / reaching to fast and aborts.
hi,
before starting to dig around github a lot i just wanted to know if someone can clarify the status of due&radds support. dcnewman's github states that he stopped his fork. in the source of dc42 i can see some #ifdef RADDS so far. the status of the port is however a bit unclear.
maybe someone has some insight or is even using RRF on this combo?
any progress on this? i have a dyzend too and have trouble getting it running on 1.17dev6