Great job @Samuel Pinches . Compared to my branch what changes did you make? I do not see the marlin information on my LCD and in the pull request you've opened I see only the removal of two comments.
Is it perhaps the different way to load the firmware? I am loading it via SD and you (I think) via stlink...
Doh...I have fixed the PR now. Just need to change the PF0 to PG0. I've created a video to show the solution for the lcd, I'll upload that in a sec and post that here.
Ok @jelot_it ... I got the on-screen touch buttons working, thanks to the clever work started by jmz52 here - I started by implementing all the changes in their branch related to TFT-touch on the MKS Robin. After that, I made the following additional changes:
in pins_JGAurora_A5_A1.h
#define TOUCH_CS PA4
#define BTN_ENC PA11 // not connected, real pin, stable value
in xpt2046.h
Changed SPI to SPI_CLOCK_DIV4
Changed touch calibration to:
/* JGAurora A1 */
#define XPT2046_X_CALIBRATION 20000
#define XPT2046_X_OFFSET 128
#define XPT2046_Y_CALIBRATION 15000
#define XPT2046_Y_OFFSET 128
in xpt2046.cpp
x = (uint16_t)(((((int32_t)x)-XPT2046_X_OFFSET) * (int32_t)XPT2046_X_CALIBRATION) >> 16 );
y = (uint16_t)(((((int32_t)y)-XPT2046_Y_OFFSET) * (int32_t)XPT2046_Y_CALIBRATION) >> 16 );
if (y < 0 || y > 220) return 0;
if (x > 0 & x < 200) encoderDiff = - ENCODER_STEPS_PER_MENU_ITEM * ENCODER_PULSES_PER_STEP;
if (x > 200 & x < 380) encoderDiff = ENCODER_STEPS_PER_MENU_ITEM * ENCODER_PULSES_PER_STEP;
if (x > 380 & x < 580) return EN_C;
You can download the zip here of my build env - which is based off your git repo build:
@Samuel Pinches I merged your pull request and I've placed a commit to fix the ram length for the linker.
this is what I get without making the changes shown in the video ... I probably do not have that problem or, being my LCD inside the case, it has some connected mass that you did not have (or something similar)
Thanks for pulling all that together. I’m going to put my printer together and have a go in the next few days. I wonder, if you get a chance could you take a photo of the motherboard version on your printer? Maybe it is a different revision.
I am attaching a picture of the silkprint of my "broken motherboard". If you need a complete picture of the board, I can take it apart and do it.
P.S. the new motherboard has been sent, but the goal is to print something with the broken motherboard before the new one arrives ... I just need to change the pin file to make the z axis move correctly
[edit] Actually I saw from your post above that you have a different version ... your V0.2 vs my V1.0 [/edit]
I think that for the LCD buttons it is more convenient to have a different branch, so that everything that does not concern the LCD monitor can be merged faster inside the upstream marlin.
it seems to me that jmz52 has made many changes that could make the integration process inside upstream marlin slower
if you want I can create a new branch board/jgaurora_a5s_a1_lcd_buttons (or something similar) in my repository or you can create it directly in yours... the important thing is that the changes concerning the operation of everything that is not "lcd" go in the original branch or in separate commits, in this way we can make cherry-picking
Good work, guys. You have done a lot of work while I was looking away. Odd that the display works normally. Perhaps it uses a slower data rate in the default firmware?
You can dump the firmware using an ST-link device quite easily on PC using the ST-Link utility. That's how I was able to get the bootloader, which is not included in the JGAurora provided updates.
Unfortunately, I've been stuck on trying to identify the cause of the unresponsive heating pins problem. It occurs as soon as the timers are setup in the
HAL_timer_start() call. I had a look in the HAL code, but I couldn't see anywhere where values are changed.
I also learned that the Serial (USART) 2 pins also overlap with those pins too, but I don't think that is the problem.
I also confirmed with a basic arduino sketch that the pins are not inverted or anything strange like that.
Ok, I'm stuck guys. I can't seem to solve the heating problem - as soon as the board boots it starts heating up straight away. Additionally, the mosfets do not turn off when a temperature is set.
From what I can see, this all happens in the temperature.cpp file, after the thermalManager.init() call is made, which is called during the startup process in marlin.cpp. The HAL_timer_start() call seems to lock the pins from being able to be changed even when manually inserting GPIO value change code right after it : e.g. <br>
int PIN_STATUS = 1;
<br> (PIN_MAP[HEATER_BED_PIN].gpio_device->regs->BSRR = (1U << PIN_MAP[HEATER_BED_PIN].gpio_bit) << (16 * (bool)PIN_STATUS));
Inside the HAL_timer_start() call, if I comment out the timer_attach_interrupt() then the code above is able to change the pin status, but I still cannot control the mosfet from marlin when setting temperatures.
I still think the firmware should be the same because same boards and similar hardware but I guess we will see.
I need to follow up on an issue where the extrude icons work opposite to how they are labelled (does this happen on yours?). Perhaps that would cause them to release newer firmware. Personally, I'm mostly using Octoprint now so it's a bit less critical.
@Richy_T - the motherboards should be the same, I think just that mine is an earlier version.
The firmware is also the same, but the A1 has the x-axis reversed, so they need to make a separate version with that change included. They probably just haven't bothered. I have verified you can run the A5S firmware on the A1, but the x-motor moves the wrong way.
I didn't notice that problem, but unfortunately my printer is in pieces at the moment while I'm doing heart surgery working on the firmware for the motherboard.
Ok, solution to problem 1: the min temp in config.h needs to be lower than the probe temp for temperature control to work... grrrr wasted so much time on this one...
happy to hear progress on this, but what is the temperature of the probe?
yesterday I received the new motherboard. I'm in the middle of my first print with this printer. As soon as the print ends, I go back to working on the firmware
P.S. if you can, avoid updating platformio and our dependencies... today I did it and now I have some problems of compilation (partly solved, but not completely)
OK! AWESOME NEWS TIME: WE HAVE WORKING (VERY VERY BETA) COMMUNITY FIRMWARE!!!!
If you want to risk your printer catching fire , and burning your house to the ground , and your cat spontaneously combusting , then you are welcome to try the beta 1 firmware here: BETA 1 DOWNLOAD
Turn off printer, and leave off for 30 seconds, for internal capacitor to discharge
Copy the correct firmware file for your printer onto SD card
Insert SD card into printer
Turn on printer
Wait for flashing to commence
To restore to factory firmware, do the same steps as above, but use the OEM factory firmware here.
I haven't even tried printing with this yet myself! But I'm going to bed.... 😴😴
I also saw the history of your PR on upstream... awesome
I restored the history of my branch that I had modified due to an upstream rebase... in this way we have again the same hashes.
I saw that some of your commits have parts for the buttons and for the configuration mixed together...
Tonight I would align the branch with upstream (through merge ) and I would like to extract from your commits what is needed to do a PR (for now without the part of the buttons). Is it good for you?
Go for it! I tried to PR the main core marlin & HAL changes, so I don't think you will need to make many, if any, changes to your build (except small changes in conf.h & conf_adv.h) if you apply the changes I submitted upstream.
I think if we can get EEPROM working, then most of the other functions should fall into place fairly easily. Unfortunately I'm short on time, so if you're able to have a go at that, that would be awesome.
Installation really easy +1 Bed mesh leaving done without problems, the only thing that I notice is that for the last 4 point the nozzle goes really on the limit maybe few mm less to the border will be appreciated +1 Now the printer is heating and preparing for the print cube
Howdy, Stranger! It looks like you've been lurking for a while.
If you register, we will remember what you have read and notify you about new comments. You will also be able to participate in discussions.
So if you'd like to get involved, register for an account, it'll only take you a minute!
Comments
Is it perhaps the different way to load the firmware? I am loading it via SD and you (I think) via stlink...
it should be correct, but check if it's true.
I hope to have some time today to work on it and see what has been introduced by you and by jmz52
[edit]
Actually I saw from your post above that you have a different version ... your V0.2 vs my V1.0
[/edit]
it seems to me that jmz52 has made many changes that could make the integration process inside upstream marlin slower
if you want I can create a new branch board/jgaurora_a5s_a1_lcd_buttons (or something similar) in my repository or you can create it directly in yours... the important thing is that the changes concerning the operation of everything that is not "lcd" go in the original branch or in separate commits, in this way we can make cherry-picking
From what I can see, this all happens in the temperature.cpp file, after the thermalManager.init() call is made, which is called during the startup process in marlin.cpp. The HAL_timer_start() call seems to lock the pins from being able to be changed even when manually inserting GPIO value change code right after it : e.g.
<br> int PIN_STATUS = 1; <br> (PIN_MAP[HEATER_BED_PIN].gpio_device->regs->BSRR = (1U << PIN_MAP[HEATER_BED_PIN].gpio_bit) << (16 * (bool)PIN_STATUS));Inside the HAL_timer_start() call, if I comment out the timer_attach_interrupt() then the code above is able to change the pin status, but I still cannot control the mosfet from marlin when setting temperatures.
Strangely, in the Marlin firmware, I think the pin values DO seem to be be inverted for some reason??
I need to follow up on an issue where the extrude icons work opposite to how they are labelled (does this happen on yours?). Perhaps that would cause them to release newer firmware. Personally, I'm mostly using Octoprint now so it's a bit less critical.
I didn't notice that problem, but unfortunately my printer is in pieces at the moment while I'm doing heart surgery working on the firmware for the motherboard.
yesterday I received the new motherboard. I'm in the middle of my first print with this printer. As soon as the print ends, I go back to working on the firmware
P.S. if you can, avoid updating platformio and our dependencies... today I did it and now I have some problems of compilation (partly solved, but not completely)
- EEPROM
- Testing
- Testing
- Tuning
- Testing
- Mesh Bed Levelling
- Power Outage Recovery
- Filament Run Out
- Filament Changing
- Testing
ANY HELP IS VERY WELCOME!!!I also saw the history of your PR on upstream... awesome
I restored the history of my branch that I had modified due to an upstream rebase... in this way we have again the same hashes.
I saw that some of your commits have parts for the buttons and for the configuration mixed together...
Tonight I would align the branch with upstream (through merge
I think if we can get EEPROM working, then most of the other functions should fall into place fairly easily. Unfortunately I'm short on time, so if you're able to have a go at that, that would be awesome.
Installation really easy +1
Bed mesh leaving done without problems, the only thing that I notice is that for the last 4 point the nozzle goes really on the limit maybe few mm less to the border will be appreciated +1
Now the printer is heating and preparing for the print cube
Howdy, Stranger!
RegisterIt looks like you've been lurking for a while.
If you register, we will remember what you have read and notify you about new comments. You will also be able to participate in discussions.
So if you'd like to get involved, register for an account, it'll only take you a minute!