Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 17, 2020 09:36AM
No problem.
I will transplant the SKR into a spare machine I have and start testing


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 17, 2020 12:00PM
OK I think I've managed to merge my changes into the V3.01 version (which was remarkably painless - git is not my strongest skill!) and it seems to be working (WiFi, TMC config, simple motor moves). I was fooled for a little while by firmware.bin now being in a different place!

So a quick question I'm currently using WiFi firmware v1.23 and the standard (not sdavi's version) V2.04 of DWC is this the best combination to use (I think there may be a later DWC now)?

My 3.01 changes are at:
[github.com]
Build system changes:
[github.com]
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 17, 2020 01:09PM
I believe sdavi's version of DWC would recognise when a new firmware.bin file had been uploaded and ask the user to install, thats it.
1.23 is the latest wifi firmware as far as I know and DWC is now at 2.0.6. Definitely worth the upgrade as there was a number of bugs fixed.


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 18, 2020 06:09AM
@gloomyandy Did you by any chance happen to give this a go for the software UART: [github.com]

I think that is a nice solution utilising the GPDMA on the LPC17xx.

Edited 2 time(s). Last edit at 01/18/2020 06:42AM by sdavi.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 18, 2020 08:31AM
It is a nice solution (and I had a good look at it when adding software serial to Marlin) but it uses a lot of resources (3 256 byte memory buffers, plus one of the general purpose timers and the gpdma channel). I'm not that familiar with the reprap LPC implementation so I'm not sure if those resources are available for use or not. I was particularly conscious of how tight memory is. It also makes use of FIOMASK (to restrict the dma writes to a single output bit on the port), but I'm not sure what impact using that might have on other I/O operations on the same port while the dma transfer is active (it certainly seems to impact some of them). It would be interesting to see if it could be made to work though as the dma usage would avoid the errors I see due to other parts of the system either disabling interrupts or higher priority interrupts running.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 19, 2020 03:05AM
Quote
gloomyandy
It is a nice solution (and I had a good look at it when adding software serial to Marlin) but it uses a lot of resources (3 256 byte memory buffers, plus one of the general purpose timers and the gpdma channel). I'm not that familiar with the reprap LPC implementation so I'm not sure if those resources are available for use or not. I was particularly conscious of how tight memory is. It also makes use of FIOMASK (to restrict the dma writes to a single output bit on the port), but I'm not sure what impact using that might have on other I/O operations on the same port while the dma transfer is active (it certainly seems to impact some of them). It would be interesting to see if it could be made to work though as the dma usage would avoid the errors I see due to other parts of the system either disabling interrupts or higher priority interrupts running.

I was thinking more along the lines of just using the DMA approach with bitbanding in the current code.

In RRF3 LPC, timer1 is free, and only 4 DMA channels have been allocated (for SSP 0 and 1).

I checked the addresses for registers of the reading/writing the GPIO and it's within the BB region, as is setting pin directions. The manual also states that the bit-banding provides atomic operations to the bit data. I've just implemented this now in the core code for functions that set the direction, and write to a port (more on that later). So if using the BB alias address of the bit in FIOPIN and FIODIR in the DMA transfer for the pin writes and direction changes instead of FIOPIN and FIODIR, then I think that should avoid the need of using FIOMASK (as long as we are careful/doing that every where else too). *(also assuming i've followed all this correctly of course).

Only boards that have all steppers on port2 have a parallel write and that relies on FIOMASK not being changed as its using the SET and CLR. We don't set fiomask but assume it hasn't been changed)

All this did bring up an interesting point, writing ports bits or setting pin directions that get interrupted (after the read but before the write) and inside that interrupt sets/clears a pin on the same port, I guess is a real possibility. So I've edited the core to use the BB (instead of just stopping ints all the time) in GPIO_PinFunction, GPIO_PinDirection and GPIO_PinWrite which are called from pinmode and digitalWrite. There is no special bits on those registers so I think using the BB won't cause any issues. This should hopefully also prevent similar problems if going ahead with the DMA soft uart too.

If your keen to try DMA instead of the RIT+int, i've added an extra channel to be assigned in InitialiseDMA (in core) which sets up the DMA and assigns some channels and also the callback handler for finish int (if desired) which I added for SSP DMA not long ago.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 19, 2020 03:41AM
That sounds very interesting! I'd certainly like to give it a try. But I think I need to spend some time reading up on bitbanding! Are there examples of using bitbanding already in the code?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 19, 2020 03:53AM
Quote
gloomyandy
That sounds very interesting! I'd certainly like to give it a try. But I think I need to spend some time reading up on bitbanding! Are there examples of using bitbanding already in the code?

Yeah it is interesting, I only discovered it last night - what a great feature I never knew existed winking smiley I added a new headerfile and edited gpio.c here: [github.com] and there is a section about bitbanding in the lpc user guide 34.3.2.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 19, 2020 04:03AM
The networking version doesn't build due to missing files.
The RTOSPlusTCPEthernet folder is missing from the 3.01 branch. It is a case of just copying it from the 3.0 branch?

Edit: adding those files back in allow it to be built so it looks at though it's just the folder of files missing from 3.01

Edited 1 time(s). Last edit at 01/19/2020 04:13AM by jay_s.


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 19, 2020 04:17AM
Quote
jay_s
The networking version doesn't build due to missing files.
The RTOSPlusTCPEthernet folder is missing from the 3.01 branch. It is a case of just copying it from the 3.0 branch?

Update lpc core from git, I fixed the makefile a couple of days ago for that. I moved all the LPC files that are additional to RRF into the LPC dir now so its all together.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 20, 2020 08:38AM
That builds ok.
I have it running on an MKS SBase I had lying around.


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 21, 2020 01:25AM
@gloomyandy I was having a play with the DMA and bitbanding today and looks like it's a no go. If I put a BB address into src or dst for DMA it doesn't seem to like it.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 21, 2020 03:22AM
I've merged in the TMC22xx from gloomyandy repository onto v3.01-dev-lpc-tmc22xx branch here: [github.com] can someone check this to make sure its still working before I merge into the main 3.01 branch ?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 21, 2020 03:35AM
@sdavi that's a real pity, I'd started hacking some code together to do this, but have not tried running it yet. There is surprisingly little information around on the subject. I did dig this up... [community.nxp.com] which would seem to indicate that the bit-banded "memory" only exists within the arm core and so the gpdma does not see these addresses as memory.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 22, 2020 06:02PM
Hi,
so I think I may have figured out a way to use DMA for the TMC22xx UART. I'm still experimenting a little, but I think it will work. I've just noticed though that you are now using TIMER1 for the ADC smoothing code, are there any other free timers available?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 22, 2020 08:33PM
Quote
gloomyandy
Hi,
so I think I may have figured out a way to use DMA for the TMC22xx UART. I'm still experimenting a little, but I think it will work. I've just noticed though that you are now using TIMER1 for the ADC smoothing code, are there any other free timers available?
  • Timer 0 - Step Generation
  • Timer 1 - (currently optional ADC filter as of yesterday - could be disabled in TMC builds)
  • Timer 2 - Software Servo PWM - This is only a backup for pins for servo that are not on a HW PWM pin. However this probably isn't needed anymore and was just a left over from previous version and kept just cause the timer was free. Software PWM timer could probably just be used for that, so this could be freed up. Hopefully most boards are using HWPWM pins for servos - should check that.
  • Timer 3 - Software PWM - Used for heater and fan PWM.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 24, 2020 04:17PM
Quick update. I now how a working DMA based UART that seems to work pretty well. This code has a much lower interrupt overhead than that from the previous pure timer based version. It generates a single interrupt per byte being transmitted and just a single interrupt at the end of the receive, this compares with 3 interrupts per byte for both transmit and receive with the timer solution. I'm still working on improving some aspects of the code (reducing memory if possible, it currently requires around 500bytes). One problem I have seen is the occasionally the TMC2208 does not send a response. Hooking up a logic analyser revealed that this was because occasionally there was a glitch in the data being written to the driver, which resulted in the TMC2208 not recognising the command. This was being caused by the dma write occurring between the read modify write operation used in digitalWrite, I'm pleased to say that updating to the latest version from sdavi (and so picking up the bit banding implementation of digitalWrite has fixed that problem).

My version of the DMA UART is based on the original code by Artem-B that was linked above. However that had some problems during write operations that made it unsuitable for use with RRF. The main issue was the use of FIOMASK to enable writes via DMA to only a single bit. My version avoids this issue by creating a chain of linked DMA control blocks one per bit of the UART write data. Each control block writes to either FIOSET or FIOCLR (which allows writing to a single bit of the port). The read side of things follows the same basic scheme used in the original code (though switching from output to input is handled differently to avoid issues with the read modify write nature of the original). I'm still experimenting with the best possible configuration of this code, but it is looking promising.

A quick question for anyone with a duet that uses TMC22XX devices (@dc42 perhaps), do you ever get any read/write or timeout errors on the TMC I/O (shown by M122)? I'm still seeing some errors, but I'm curious if this is completely down to the use of a software UART or if there are still errors when using the hardware implementation?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 24, 2020 06:20PM
Quote
gloomyandy
Quick update. I now how a working DMA based UART that seems to work pretty well. This code has a much lower interrupt overhead than that from the previous pure timer based version. It generates a single interrupt per byte being transmitted and just a single interrupt at the end of the receive, this compares with 3 interrupts per byte for both transmit and receive with the timer solution. I'm still working on improving some aspects of the code (reducing memory if possible, it currently requires around 500bytes). One problem I have seen is the occasionally the TMC2208 does not send a response. Hooking up a logic analyser revealed that this was because occasionally there was a glitch in the data being written to the driver, which resulted in the TMC2208 not recognising the command. This was being caused by the dma write occurring between the read modify write operation used in digitalWrite, I'm pleased to say that updating to the latest version from sdavi (and so picking up the bit banding implementation of digitalWrite has fixed that problem).

My version of the DMA UART is based on the original code by Artem-B that was linked above. However that had some problems during write operations that made it unsuitable for use with RRF. The main issue was the use of FIOMASK to enable writes via DMA to only a single bit. My version avoids this issue by creating a chain of linked DMA control blocks one per bit of the UART write data. Each control block writes to either FIOSET or FIOCLR (which allows writing to a single bit of the port). The read side of things follows the same basic scheme used in the original code (though switching from output to input is handled differently to avoid issues with the read modify write nature of the original). I'm still experimenting with the best possible configuration of this code, but it is looking promising.

A quick question for anyone with a duet that uses TMC22XX devices (@dc42 perhaps), do you ever get any read/write or timeout errors on the TMC I/O (shown by M122)? I'm still seeing some errors, but I'm curious if this is completely down to the use of a software UART or if there are still errors when using the hardware implementation?

Did you also increase the DMA int priority? At the moment its only at SPI priority level and will most likely need to be higher than step int.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 25, 2020 02:05AM
I haven't yet but it is one of the things on my list to try as I'm investigating the errors I'm still getting. I may also change the priority order for the DMA channels to give the "UART" a higher priority to see if that helps. One "problem" I now have is that I've reduced the number of errors a lot so it takes a fair bit of time to get them to occur, so testing can be slow.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 25, 2020 10:06AM
Hmm that's interesting (and puzzling), if I set the priority used by the GPDMA to anything below 5 then my board hangs (or at least it never appears as a USB device on my PC). It does the same both with and without my DMA UART code enabled. Any idea what may be going on? Not sure if it matters but I have the esp wifi code enabled and have a WiFi module attached but not enabled (I usually issue the M552 S1 command to enable it via a USB terminal connection). The USB interrupt is at priority 5, I wonder if there is any sort of interaction?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 25, 2020 06:20PM
Quote
gloomyandy
Hmm that's interesting (and puzzling), if I set the priority used by the GPDMA to anything below 5 then my board hangs (or at least it never appears as a USB device on my PC). It does the same both with and without my DMA UART code enabled. Any idea what may be going on? Not sure if it matters but I have the esp wifi code enabled and have a WiFi module attached but not enabled (I usually issue the M552 S1 command to enable it via a USB terminal connection). The USB interrupt is at priority 5, I wonder if there is any sort of interaction?

That is cause the SSP DMA handlers make use of GiveFromISR functions from FreeRTOS, and in the FreeRTOS config has configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY set to priority 5, which is the highest interrupt priority isr that you can make calls to interrupt safe FreeRTOS calls.

Hopefully 5 will be ok for the softuart - after the software PWM but before the step int which is at 6. Fans and Heaters are using the soft PWM so may be best not to use high frequencies for the PWM when configuring those.

Edited 2 time(s). Last edit at 01/25/2020 06:45PM by sdavi.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 25, 2020 06:42PM
Also the LPC Manual says it has "32 programmable interrupt priority levels" so we could even shuffle around the int levels above 5 to get the priority order that we need.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 31, 2020 04:24AM
Hi,
a quick update on my progress and findings with the TMC22XX support...

I now have two versions of the code working both seem to work pretty well and operate most of the time with no errors. The first is based on my original code and uses timer interrupts to drive the I/O the other uses DMA to carry out all of the operations. The DMA solution requires about 360 extra bytes of RAM (for the sample buffer), but has a much lower interrupt overhead (approx 480/s verses 29000/s with both operating at 9600 baud), but it does have a higher non-interrupt overhead due to the need to process the received sample buffer, but I think overall the DMA solution is the better one. I now have RRF running on my actual printer (with WiFi and TMC22XX support), and everything seems to be working fine (heaters, fans, drivers, probe etc.) so I'm testing things for real now.

A few things about the current version of the code...
1. Although I had thought that the bit banding GPIO read/write code fixed the problems I had been seeing with corruption of the UART output, this was not the case. It was much better than the old code that basically did a read/modify/write on the GPIO PIN register, but I think that somewhere in the depths of the bit band implementation there was still a read/modify/write that can end up being interleaved with DMA write operations. However switching the code to use the GPIO SET/CLR registers seems to fix this problem and I can now operate the UART code with no errors over many hours. I suspect that the current bit banding code may create the occasional error if a pin is written to from an interrupt handler, so I think it would be worth changing the base code to user the SET/CLR mechanism.

2. At the moment my DMA code uses timer 1 which means it is not possible to have this and the ADC smoothing operating at the same time (though I've not seen any problems with the ADC readings on my setup so far). I had a look at the code and it seems to me that it might be possible to replace the current use of Timer 3 with the RIT timer and that would allow the use of Timer 3 for this UART code. Does that make sense to you? If so I'll have a look at actually making it work.

3. I'm a little unsure about how to configure the pins for the UART connections (I need one pin per device). Up until now I'd been using a board.txt and simply adding the extra configuration in there as an extra named array of pins. This worked fine when I did not have a the board type set (so it was using the generic board type I guess). However when I switched to using the SKR 1.3 or SKR 1.4 boards I hit a problem. At the moment you can only use pins in a board.txt file that have definitions in the base board definition (so in generic or SKR 1.3 etc). But the SKR board definitions do not by default have any of the pins used for the drivers defined in them. At the moment I've fixed this by simply adding the pins I need to the SKR definitions and then continuing to use an extra entry in the boards.txt file, but this seems a little messy. Any thoughts on the best way to fix this? I could add an extra predefined array of UART pins in the same way that we already have ones for the driver step/dir/enable pins to all of the board definitions, any thoughts?

I'd just like to say how impressed I am with both the base RRF code and the LPC port. Thanks to @dc42 and @sdavi for all of the hard work.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
January 31, 2020 06:42AM
@gloomyandy

1. That sounds fine.
2. Yep also sounds fine.
3. All those pins should be added to the PinTable for the SKRs, assuming they are accessible as headers on the board if users want to do other things with them. I don't have any of those boards so I wasn't sure what was written on the silk so I just left them as comments.

I just noticed there was a bug after updating board.txt to handle the silk names that if the pin is not in the table then it was rejected so I'll fix that.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 02, 2020 05:37PM
Hi,
So I've just pushed my fork of the LPC code (up to date with sdavi 3.01 as of today!), containing the latest changes I've made to support a UART interface for TMC22XX devices this version has both the timer based code and the DMA code (setup to use the DMA version by default). I've added the pins needed to the PinTable for the SKRs but I have not yet got around to trying to free up timer3 (next on my list). I've been running this code on my 3D printer and so far everything seems to be working fine during my tests. My git branches are:
[github.com]
[github.com]
the libraries are identical to those from from
[github.com]

A quick question, what pwm frequency makes sense for fans/heaters on the LPC? At the moment I'm just using the default values which I think is 250 (I assume Hz?) and comes from DefaultFanPwmFreq, is this a sensible value for things like the heatbed?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 03, 2020 09:45PM
Quote
gloomyandy
A quick question, what pwm frequency makes sense for fans/heaters on the LPC? At the moment I'm just using the default values which I think is 250 (I assume Hz?) and comes from DefaultFanPwmFreq, is this a sensible value for things like the heatbed?

The defaults seem to work well. In RRF2 LPC we only had the 2 default heater frequencies available - 250Hz for hotends (and fans) and 10Hz for heated beds. In RRF3 LPC you can choose what frequency you want (it is generated by interrupts so probably best not to use very high frequencies). The official configtool lists 500Hz as the default fan speed.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 04, 2020 09:20AM
@sdavi
Does your wifi password use any numbers?
I've had issues getting my board to connect to a wifi network when there are numbers in the password.
The board reports that the password is incorrect, but if I change the password to all letters, it connects without issue.
Just trying to marrow down if this is something with just me or whether its a more widespread issue.


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 04, 2020 09:15PM
Quote
jay_s
@sdavi
Does your wifi password use any numbers?
I've had issues getting my board to connect to a wifi network when there are numbers in the password.
The board reports that the password is incorrect, but if I change the password to all letters, it connects without issue.
Just trying to marrow down if this is something with just me or whether its a more widespread issue.

I just tested this and is working properly for me when I added numbers to the password.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 05, 2020 02:21AM
Quote
sdavi

I just tested this and is working properly for me when I added numbers to the password.

Must just be me.
Thanks for checking.


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 05, 2020 04:13PM
I don't know if its me, but I'm really struggling with basic endstop setup.
I'm using lpc.board=biquskr_1.4.
I have an endstop fitted between ground and 1.29. That board setup calls that pin "xstop"

I've tried the following in the config
M574 X1 S1 P"xstop"
and
M574 X1 S1 P"1.29"
Neither of these show as triggering in M119 or DWC.

Anyone got any ideas? I've already tested the switch using a multimeter so I know that's not an issue.


Based in Darlington, North East
Sorry, only registered users may post in this forum.

Click here to login