• Pins are In

    J.C. Nelson09/17/2019 at 17:34 0 comments

    Marlin's bugfix-2.0.x now contains pin definitions for the Lerdge X and K. I don't own an S, so I have no idea what the pins are. Next steps are to figure out if we HAVE to have a specific board definition (my suspicion is "yes") or if we can build with a generic variant. The reason I think we'd need a specific variant is that the variant's pin config specifices which pins are used by an ADC, and on Lerdge I had issues with the bed pin not having a default ADC definition (I had to uncomment it).  

  • Signs of LIfe

    J.C. Nelson09/09/2019 at 00:27 0 comments

    Tomorrow I'm hoping to get the Lerdge-S pinouts from Lerdge. Tonight, I dusted off the repositories and got everything compiling enough to make pull requests for pins. That'll be the beginning of getting this into Marlin 2.9 proper. There's a number of problems with the boot screens and touch controller, but we'll get it running.

  • FSMC Progress

    J.C. Nelson07/08/2019 at 05:00 0 comments

    A week ago, my STM32F4xx mcudev black board arrived, with a fun STM32F4 processor on it and a TFT LCD interface. I also ordered the cheapest LCD I could find on AliExpress, an Orise clone that specifically mentioned supporting FSMC access. The pinout wasn't identical to what the STM32F4XX wanted, but with a nest of jumper wires, I hooked them up to the right ports.

    Why?

    I want to build a nice, generic FSMC library where I can tell it the configuration and let it do the rest, and FSMC code is very picky. I found a sample for Keil MDK (which is very expensive) and slowly began cutting it over from the Standard Peripheral Library to the ST HAL. Finally, I managed to get some code that successfully initialize the LCD, but the Orise is an oddity - it can be hard reset from software. The reset pin isn't even used during init. Most LCDs require a reset sequence (lerdge certainly does).

    The other advantage of this hardware is that it has an XPT2064 resistive touch, just like the lerdge, meaning that next I can hook the four wires (SPI + Interrupt) for the touch, and get that working. 

    Lastly, SDIO + DMA will be the end goal, with DMA from an aligned buffer. Touch work will come first.

  • Roadmap going forward

    J.C. Nelson06/26/2019 at 05:16 0 comments

    The next few stages are not going to be terribly entertaining. As noted, I need to get the pin mappings into Marlin 2.x, which will produce an absolutely *minimal* printer. I don't say that lightly, I mean it - no SD, no LCD, no...most of the pretty bits. But once that's working and in, I can switch modes. I ordered from China (and just received) a beautiful little blackpill board - that's an STM32F4 system with SDIO SD card and a FMSC LCD interface.

    Just like the lerdge boards.

    What this means is that I can develop SDIO support for HAL_STM32 on a system that's actually designed for debugging, then move the code over to support Lerdge.

    LCD? Same deal. The LCD in question uses a different command set, but that's irrelevant - I will wire it up identically and use it to debug FMSC LCD interaction, followed by U8G LCD interaction...followed by moving the code to Marlin. THe LCD supports the exact same XPT chip, so I can even debug touch interaction.

    But first, I am going to finish out the M200 work.

  • Getting Working Again

    J.C. Nelson04/27/2019 at 05:51 1 comment

    My other project, Marlin 2.x on the Monoprice Mini/Malyan M200, is slowly starting to function, and there's a few benefits from that for my lerdge project. First off, I have a much better grip on how USB support has to work. Secondly, I've identified a few problems with PWM that have to be resolved -and also we need a better way to handle timers in the ST HAL. The problem is that F_CPU is used to derive some of the prescalar values for a timer, but that will vary based on the board's clock config. For instance, I could underclock an STM32F103 to 48mhz and USB/timers will still work fine. The RCC_GetClockConfiguration function will get us the clock divisors, and with a helper function to get every timer's proper clock source and divide out by the proper scaler, it should work.

  • Knob and Pins Mapping

    J.C. Nelson04/02/2019 at 04:38 4 comments

    I've been fairly busy at work (as in the job that pays the bills) but I ordered a knob for my lerdge X and soldered it in. Lerdge X and K pin mappings seem to be right, though since I'm not remotely using all the functions I can't be certain everything works (led strips? No. Probe? No. Motor fan, etc? Hahahahahaahaha) My test printer is literally a Monoprice Mini I wired adapters up for (see my other project for hacking on that).  

    I'll start a PR to Marlin main to add X and K boards soon.

  • Minimum 2 Week Hiatus

    J.C. Nelson02/13/2019 at 22:14 0 comments

    I'll be away from my hardware and most of my software for the next few weeks, so good luck hacking, people. It's important to unplug every now and then. Have a good time, I'll see everyone next month.

  • Successful Print!

    J.C. Nelson01/23/2019 at 21:43 4 comments

    I was fairly close to getting everything running, and as I mentioned, this last stage is painful in that things *almost* work. I discovered a few new problems:

    1. There's a random SDIO error that causes printing to error out. I hooked up Octoprint and proceeded anyway.

    2. My travel settings are way, way too agressive for the little MPSM I wired this into. The printer doesn't move fast normally, and you can see it shakes and rattles quite badly during the video.

    3. Steppers STILL aren't adjusted right. X skipped a step at the bottom, causing a shift (and at the top, the person operating the printer failed to get their hand out of the way of the print head, causing another). 

    4. A partial clog midway through the print caused that ugly layer in the middle, a minor shift caused the bulge below it.

    Despite all these problems, the printer works. The pins are correct, almost everything works except one of the LCD buttons, which isn't defined right for some reason. I'll begin a PR to get the pins added to Marlin once I have that fixed.

  • Delays and Distractions

    J.C. Nelson01/22/2019 at 18:32 4 comments

    I was fairly close to being ready to declare this printer running at an alpha state and add it to the Marlin 2.0 compatibility table. All I had to do was get a few test prints done and I'd be happy.

    Easy, right?

    First, I found an issue with my variant in Arduino. In ST's core, every pin has to be mapped to an ADC if it's going to be used for analogRead(). And guess who didn't have an ADC for the hotend pin.

    Easy fix.

    I wire everything up...and still don't get a reading. This sent me down a rabbit hole checking and rechecking, but finally I hit an easier answer. We're at the part of the project where theory meets reality, and the bits and wires intersect.

    I had a broken thermistor. I don't know where it's broken, but it is. So I wired in a new one...and discovered my hotend was destroyed. How did this happen?

    One of the last fixes I did fixed the E0_AUTO_FAN, so the hotend is automatically cooled. But right before that, I'd done a temperature test, and (sigh) cooked the PFTE liner in my hotend. 

    Good news? Thermal runaway detection at both min-temp and max temp works 100%.

    Bad news? I'm wiring a new hotend into the printer.

    At that point, I'll print the lucky cat...and have a beer.]

  • Marlin 2.0 Status - Progressing

    J.C. Nelson01/18/2019 at 18:57 0 comments

    I've got a minimal marlin build up and running on both X and K, with the boards wired into a printer to test with. Doing so has revealed a few problems I would not have seen otherwise:

    1. My LCD isn't filling the background correctly. The Logo during boot appears clipped, and the boarders are not filled in black.

    2. Hotend temperatures read from PC1 are not working correctly. i can swap the pin definition to PC0, swap the connector, and the hotend behaves correct. This doesn't affect the MP MIni, so it's not clear to me what might be happening.

    The solution for #2 is to write some diagnostic code to narrow down if pure, plain "analog read" works for the pins. Once basic pins are verified, I'll begin PRs to add this to Marlin main.