Show all posts by user
Quotegloomyandy
@sdavi That sounds pretty good! I'm looking forward to giving it a go with the Pi I have already got attached to my printer. How easy was it to create a cable to hook the two boards together? Is the connection similar to the WiFi board (SPI plus some handshake lines)? I've not really looked at how things get split between the two boards, so I'm not 100% sure what the advantages ar
by
sdavi
-
Firmware - experimental, borrowed, and future
It should be possible to still keep board.txt (on the internal SDCard), just update the board config loader to use FatFS to load the file rather than through the RRF MassStorage class.
I was playing around with the SBC version again today, and disabling MassStorage saves a nice chunk of memory (around 6K of RAM). Currently, I have it running with MassStorage disabled, 4K SPI buffers, max code l
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
@sdavi, that's interesting, but a little worrying that we need to go so much lower on the buffer sizes, to get things to fit. I wonder if it will even run with buffers that are so much smaller? I had a quick look at the DSF code and changing the buffer size looked reasonably simple (as DC42 already changes it from the default 4K). In your build do you have code that actually handl
by
sdavi
-
Firmware - experimental, borrowed, and future
I did a bit of testing yesterday, and the 3.01-RC3 LPC NoNetworking standard build leaves (on my setup) 15,960 bytes of never used RAM. Nowhere near enough for the default config of SBC build, but after slashing some buffers (i.e. only 2K SPI buffers instead of 8K, 1/2 code buffer etc etc) a cut-down version of the SBC code can squash into ~9.5K leaving 6,304 bytes of free RAM. I did still have t
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
@sdavi That's interesting I've not really paid much attention to the SBC/DSF side of RRF 3.0 (I assuming it was simply not possible with the LPC version). Having now had a quick glance at it I wonder if it may be possible. My understanding is that certain functions get migrated to the rPi from the RRF control board. Does this migration free up any RAM on the LPC I wonder (things l
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotejay_s
Maybe we would be able to leverage a connection to an SBC if and when that's implemented on the Duet 2?
In an early version of RRF3.0 I had this compiling (but not tested with a SBC) on the LPC back when the default RX and TX buffer size was I think were only about 4K each. I didn't continue with it when the default buffer size was increased to 8K each for RX and TX which did not fit
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteMKSA
How comes this function requires to print from the SD card (I assume it is the one on the controller board, containing the config and firmware)
My guess would be cause when streaming GCodes from a host over USB/serial (i.e. PC, TFT32 etc) the printer doesn't know when its actually running a print, paused or if the user is just doing some manual moves etc as the host is in control, wher
by
sdavi
-
Firmware - mainstream and related support
Just a quick update for those who may not be following the V3 thread that I am no longer maintaining the LPC port.
Fortunately @gloomyandy and @jay_s will be keeping this project going, see here:
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteMKSA
Does this RRF version support this function and/or has someone used/tested it with a pulse generating sensor (https://duet3d.dozuki.com/Wiki/Duet3dFilamentMonitor_RotatingMagnetVersion#Section_Technical_details).
I am using a digital Hall sensor 3144 and a magnet mounted on my extruder idler giving 6 pulses per turn (about one pulse per 7mm of filament.) and plan to connect it to one o
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
Hi @sdavi, I've just noticed that some of your RRF repos are currently marked as archived. I hope that doesn't mean you no longer plan to update them as that would be a great pity.
They have been archived as I don't plan to do any further updates at this time. I've left everything there on GitHub so others can fork it and can merge in changes from the official RRF repository to
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
@jay_s firstly things may have changed since I last tried this, but last time I looked none of the pins for the stepper drivers are in the pin table (because they are specified in a "special" array of pins), similarly I don't think the pins used for the external SPI or the UART pins are in pin map (because normally they will be referenced as a UART or SPI device implicitly), but i
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotejay_s
Could I also suggest that every pin that's named has its pin number as well? What should the convention be as both "1.27" and "P1.27" is used across the boards files. Which would people prefer?
This is already supported using the first convention and has been since LPC RRF3.0. It will first search through the PinTable names, if its not in there then as a backup will search using the p
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
As someone that has both SKR V1.3 and SKR V1.4 boards, I agree it can be a bit of a pain, but I'm not sure I could come up with a good alternative!
I realise that many people have multiple LPC boards and would like to have a common config.g that they might update and just copy to all boards, so how about using the new conditional gcodes?
I've just added the board name that is se
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotejay_s
@sdavi
Could we look at coming up with a standardised way of naming the pins on each of the different boards?
I think it's easier for most people to use what is written on the board silk-screen in the GCode (makes debugging a lot easier that way). The only exception is boards like the ReArm etc that uses i.e. X+/X- for endstops which wasn't compatible with the way naming is handled i
by
sdavi
-
Firmware - experimental, borrowed, and future
Binary for 3.01RC1 is now available:
I have also updated the LPC config tool (I didn't spend much time on it so it might be a bit buggy, only has a few boards and it's now a bit behind the official version). This version will generate a board.txt. If the board has plug-in drivers, then there will be an extra option to select the driver or add custom driving timings and those timings are also ad
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotejay_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
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
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) a
by
sdavi
-
Firmware - experimental, borrowed, and future
@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 handl
by
sdavi
-
Firmware - experimental, borrowed, and future
Most pins on the LPC are 5V tolerant (see Chapter 7 of the LPC datasheet) when configured as digital, but when configured as ADC they are no longer 5V tolerant.
The RRF web interface (DWC) relies on certain URLs ( see ) that are provided by the RepRapFirmware webserver. You'd have to use the web interface that is provided with the TFT-wifi webserver (unless you can modify it to implement those
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteLouger
Hello everybody,
I am currently working on an upgrade for the old Makerbot Replicator 2 and would like to use the following components:
SKR V1.3 (already bought, used before with Marlin2.0 in other printers) BigTreeTech TFT35 V3.0 WiFi-Module for TFT (Is the Web-Interface of RRF usable like this?) TMC2209 (Do I need a special Version of RRF?) Pinda-Probe (Should not be a Problem, wh
by
sdavi
-
Firmware - experimental, borrowed, and future
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.
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
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
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
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 so
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
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) T
by
sdavi
-
Firmware - experimental, borrowed, and future
I've merged in the TMC22xx from gloomyandy repository onto v3.01-dev-lpc-tmc22xx branch here: can someone check this to make sure its still working before I merge into the main 3.01 branch ?
by
sdavi
-
Firmware - experimental, borrowed, and future
@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.
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotejay_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.
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
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 I added a new headerfile and edited gpio.c here: and there is a section about bitbanding
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotegloomyandy
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
by
sdavi
-
Firmware - experimental, borrowed, and future