The Marlin 2.0 32-bit thread #7076
Comments
thinkyhead
added
T: Development
@Tannoo and I have some clean up work going for the LCD header files. As it turns out... The .h files can only be included by one .cpp file because the .h files generate code. While this is not a 'bug fix' it is an important item from a 'code cleanliness' perspective. We have the Graphical LCD Display code clean up done. The 20x4 LCD Display clean up should progress quickly. https://github.com/Tannoo/Marlin/tree/ultralcd_impl_DOGM.cpp |
Go with v2.0. |
Both the Graphical LCD Panel and the 20x4 LCD Panel .h files are cleaned up in this branch... Tannoo is going to get the indentation and white space cleaned up.... |
That is correct. The LCD-oriented header files may only be included once, and only in We could make them into proper |
|
Is the new file structure going to allow Marlin to use a single file for Configuration? Much like Smoothieware? Is that one of the immediate benefits of doing this, apart from 32 bit and HAL |
|
@ImplementOfWar That has not been discussed yet. Smoothieware is able to do certain things by limiting itself to 32-bit boards which have far greater resources. When and if someone implements a configuration system in emulation of Smoothieware, it will have to be for 32-bit boards only. |
|
@thinkyhead What are you thinking for a time table to lock down the code? I thought I could get the So, we could just go with what we have... Or... You can take a look at where we are at: https://github.com/Tannoo/Marlin/tree/ultralcd_impl_DOGM.cpp and see if you can figure out the issues? |
https://github.com/Tannoo/Marlin/tree/LCD_Interactive_Mesh_Edit_Refinements |
|
I should delete the |
|
We should probably ping the whole @MarlinFirmware/language-team to complete translations. |
|
Do I understand correctly that the new features will not be added before the release of version 2.0 (1.2)? |
In general... The Pull Requests generate for the current organization that do not make it into the new file layout should not be that difficult to regenerate. The bulk of the files are not going to change. What may change are things like paths to header files or stuff like that. If your Pull Request doesn't make it to the new layout automatically... It will be very straight forward to regenerate it. |
The |
Halt means halt. If a larger number of contributors would like to help get the existing PRs merged, that would be an excellent change of pace. There's a lot of backlog to take care of.
As soon as I can get it together.
There's nothing to be done about it. There will never be some point in time where every PR will be merged, so it's best to stop the flow of new PRs and work on the PRs that we already have in front of us. I have been trying to get as many merged as possible, but more keep coming in. And so, we just have to go for it and it's just unfortunate timing for any PRs that will need to be reworked. As it is, it will be me who has to re-work all the existing PRs into the new layout, because I have the mojo to make that happen as quickly as possible, and I will have all contingencies freshly in mind. |
Let's keep fixing bugs all the live long day. Simply don't merge new stuff, and put off new features. If any new features come in while we're working on the transition, we'll simply put them off. Most contributions will be straightforward enough that it will be easy to re-make them for the new layout. Some we may have to work on within the old layout first, then when ready also bring them to the new layout. We should continue to fix bugs in the 1.1.x branch and I will make sure they are brought into the new layout as well. As for a timetable, I think we need to go in two stages. First, since we have so much work being done to make the 32-bit code ready, perhaps we should get that into minimal working shape first. Then I can include a genuine HAL as part of the initial 2.0.x branch. The layout conversion itself isn't hard. The first conversion will take me less than a day to complete, and then we can go over it and see where it needs tweaking. I'd like to focus on going over the open issues for the next day or two, patch up as many obvious bugs as possible, and merge as many of the lingering PRs as possible. One of PRs contains the 32-bit HAL rebased on the latest Once the HAL is working and we're happy with it, then I'll rebase it onto the latest code and use that as the starting-point for Marlin 2.0 with the new file layout. I think it's a good idea to take the next few days and close as many issues as we can so we have a fresh start. Yes, it's possible that we could have a 2.0 layout and initial release by the end of the week… but let's loosen up the schedule so we can clear as many issues as possible and just aim to have it ready by July 1. How does that sound? |
July 1st sounds fine... Especially if there is a sample 32-Bit HAL limping along and able to move the nozzle around!!! |
|
@Roxy-3D I'm pretty sure all the platforms currently in the HAL can do that, if the board supports the Arduino framework it's fairly trivial to implement basic features, the main stumbling block for non Arduino framework devices is the extra features needing Arduino libraries or Classes. I should be able to print tonight on my Re-ARM but the HAL needs further extended to strip all Arduino based features out of the main code and behind an API this will need to be done incrementally once we get the HAL merged. |
What classes and functions are you missing? Would it be possible to just pull in the Arduino libraries so we don't have duplicated code complicating things? |
|
Things like Print and Wire (as two random examples), just generally anything that is from the Arduino framework will need to be abstracted, this won't lead to code duplication and should lead to much cleaner and more understandable code, anything that can use the Arduino framework still can, although sometimes it may turn out it wasn't even necessary just convenient when it was implemented. In some cases it may be difficult without introducing some indirection overhead, but anything performance critical already avoids the Arduino framework. It may be a good idea to have folders in the HAL (arduino_framework, mbed_framework) devoted to anything that can be reused among platforms that use that framework, but that's probably discussion for another day. |
@thinkyhead @p3p Well... Right now is a good time to express opinions and recommendations. It may not be too hard to get the HAL folders setup logically from the very start. But any subsequent, improved layout and organization for the HAL's will be welcomed also. |
In the case of Wire all Arduino based platforms could still use it, but the calls would be through a standard API such as i2c_begin(channel, address), i2c_send_byte(channel, data), that other platforms would implement themselves or through another framework. |
|
What can I do to help with this effort? I've got a bit of free time in the evenings this week, so I'm happy to help out if I can. |
|
I think it is a little too early to do anything. We need the new organization to happen and be in place. But as soon as that happens... Several important items are on the list:
I believe there is a lot of pent up demand for an official 32-Bit version of Marlin. If we can just get one board up and working with the new release, and clear instructions so anybody can duplicate the success... We should see a lot of activity. And my guess is a number of different 32-Bit boards will start to have people using them. |
|
All threads other than this one are mainly 8-bit. |
|
I cant for the life of me get my sbase to load marlin. Im using the example configfiles and change platformio.ini to LPC1768. Nothing more is changed. Compiling says success and the board flash the bin (changes to .cur). |
|
The fact that the firmware is renamed to .cur means that it's successfully flashed... It means you have some other issue in your config files... Maybe wrong ports/buadrate etc ... It helps if you have an LCD to see what's going on |
|
More importantly the Status LED flashing indicates Marlin is running properly, waiting for commands. This thread is for 32bit platform development discussion not user support, As issues are also generally for bug report submissions not user support I would suggest asking for assistance on Discord or one of the other channels.
After seeking help from the community, if the consensus points to to a bug in Marlin, then you should post a bug report. |
What is #define SERIAL_PORT set to? My LPC1768 uses "-1", the USB emulated port. Also, make sure SERIAL_PORT_2 is commented out for now, I had a weird issue on Re-arm LPC1768 when I had both ports enabled. I couldn't communicate with either, and the MicroSD did not load as a USB drive, even though the LEDs on the board showed it was fully booted. |
|
can we add a bigger note in the first entry of this issue and in the readme like
? i have read (on facebook) serveral times now that users think its 32bit only.
|
Yes. I edited the first line to be a little bit more clear. Backward compatibility was always a primary requirement. There will come a time when the 32-bit and 8-bit code bases fork. But we are going to resist that event as long as we can and not sacrifice 32-bit functionality. |
I did receive an E3D Toolchanger (beta30) unit last month and have been painstakingly setting it up under RepRap Firmware. It's a meticulous process to align 4 different toolheads (all with slop), coordinate and design movements to grab and drop tools, get standby temperatures tuned well, build and test the priming, purging bucket, and cleaning brush setup, and on and on… We do have tool-changing support in Marlin, but it is very spare compared to the available options in RepRapFirmware, due especially to its use of onboard g-code scripts and macros. As I work with this unit, I am taking it all in, and the things I'm learning will be used to extend the existing tool-changing support, including —for 32-bit boards, at least— adding a folder with scripts that can be edited and will be used for these actions. The G-codes that we lack (e.g., |
I didn't address the readme file. But as soon as a Pull Request shows up... It will get merged ASAP. |
I only have the mks tft but that shows nothing other than the normal when it gets power. Baudrates that i have tried is 115200 and 250000
Serial_port set to -1 and serial_port_2 is commented out. |
Uncomment serial_port_2 and set it to 0. I'm assuming your MKS TFT has a serial connection to the board. With your current configuration of serial_port_1 set to -1, Marlin will only communicate over the USB port. |
|
hey so I've got myself one o' these fancy new Grand Central boards sitting here. Don't have a shield for it, can't find the RAMPS_FD v2 for sale anywhere. Does the RADDS fit the Mega form factor? Also, how can I help with dev/testing here? not sure where y'all are focusing dev efforts on new 32-bit boards. |
|
Arduino due ramps_fd v2.1 expansion board ramps1.4 upgrade https://item.taobao.com/item.htm?spm=a1z09.2.0.0.3eab2e8dJxxBxR&id=544866465374&_u=p3qea196e529 |
|
Not "why", mate, "where". I just want to know how best to help. |
|
Hello, I wanted to explore the territory or manufacturer dev boards as a base for a sort of RAMPS stack. Another advantage is that these sort of boards are neither from cloners (with their safety and compatibility issues). So I pieced together a list of available boards and their characteristics: I share that list with you if it can help someone. For my part, I am actually a bit deceived by it :(. In brief, pretty much all boards with nice screens and ports/peripherials (microSD, ethernet, wifi in some case, CAN) have very few IOs (~30). I highlighted some I find more suitable than others though. But they don't tick all my boxes. However, the list shows an interesting take away. There is a wide prevalence of the Uno R3 port. I also note some new boards with ARM Cortext A7+M4, which is an interesting direction. PS.: Sorry for the large bias toward ST (and a bit NXP) in the list :D. It's just I found both have the nicest policy and availability of affordable dev-boards. Cheers, |
|
What is the philosophy for defining pins in for optional stuff? I'm looking at Does it make sense to change the PINS fine to only define the If not, I'll try to make up a PR to fix this up for at least the |
|
Hmmm... to simplify this it might make sense to move the |
|
I have Marlin 2.x working again on the Malyan M200 v1 and v2 (STM32F103 and STM32F070) building using the Arduino IDE, but there's a few loose ends. Malyan implemented some GCODE commands that were specific to their LCD. Operations like setting the Wifi SSID/Password via a command sequence to the ESP8266 using M550 and M551. What's the normal policy on what would effectively be one-off gcode commands? Non Malyan LCDs don't need these command sequences sent, so there wouldn't be a great deal of value to other printers to adding this. |
|
FYI; both the FYSETC Cheetah board and BIQU BIGTREETECH SKR MINI-E3 boards are now on Aliexpress https://www.reddit.com/r/3Dprinting/comments/c1lttc/fysetc_cheetah_board_chinaclone_of_th3d_ezboard/ Both these boards feature integrated TMC2209 drivers and STM32F103 32-bit based MCU https://www.reddit.com/r/BIGTREETECH/comments/c0hdht/bigtreetech_skr_mini_e3_done/ Looking forward to community support for those and TH3D EZBoard Lite (unknown 32-bit ARM chip) https://www.reddit.com/r/3Dprinting/comments/bvsd1q/ezboard_lite_formerly_tough_controller_for/ |
|
Superseded by #14345 |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
and others
RAMPS_FDshield should work)EMERGENCY_PARSER,NEOPIXEL_LED, etc.EMERGENCY_PARSER,NEOPIXEL_LED, etc.EMERGENCY_PARSER,NEOPIXEL_LED, LCD, SDCard, MAX6675, etc.This thread is for discussion of 32-bit issues needing work and coordination of the 2.0 release.
The text was updated successfully, but these errors were encountered: