• EEPROM (I2C) Support

    J.C. Nelson6 days ago 0 comments

    Just a note that adding the I2C EEPROM definition to the Lerdge pins and enabling #EEPROM in the configuration was all it took to get settings to save correctly. Next up, I want to take a swing at emulating the 3 button interface on the touch screen, since unlike Mickey, I don't currently have an encoder (it's on a boat from China). 

    We're getting there. This weekend I'll be wiring the Lerdge-X into a printer.

  • Marlin 1.x running on Lerdge X

    Mickey6 days ago 0 comments

    With the help from Jason, Dzenik, and jmz52's help I was able to adapt my custom version of Marlin4MPMD to work with the LerdgeX hardware.  The majority of the work was spent adding in the STM32F4 HAL library instead of the STM32F0 HAL library, and then running through inconsistencies with the Lerdge hardware.  As a proof of concept I now have full functionality including motion, auto bed leveling, SD support, a janky looking version of the Marlin GUI, and Octoprint support.

    Because it is derived from Marlin4ST originally, the fork is based off of an older Marlin 1.x base and is only compilable through openstm32, which is a lot more complicated to generate and install binaries through.  Given the current development state of STM32 arduino support, it made more sense for me to continue bare metal development to make this proof of concept.  The right way to move forward however is to provide HAL support through Marlin 2.0, which is what future efforts will entail.

    One of the key difficulties developing for Lerdge was centered around the issue of the STM security bits.  By default, both the bootloader and the application binaries include a piece of code that will enable the security bits of the processor.  This is intended as a copy-protection feature that will erase the entire flash memory if the device is reprogrammed over SWD.  However, by side-loading our own custom binary that reads out the entire flash image we can extract the raw code for the bootloader and application binaries and modify them to disable this check.  I've added a patched version of the 1.0.2 bootloader.  This is import because it allows direct debugging and loading of application code on the processor without triggering a full erase.

    The LCD code was another challenge in that we had an unknown panel with an unknown pinout connected via ribbon cable.  Through some sleuthing we were able to determine that the communication was done over a 16-bit parallel data interface to the panel and the FSMC peripheral was used to send/receive commands.  After deducing that standard 0x2A(row select), 0x2A(column select), 0x2C(RAM write) sequence was able to change the colors on the panel, I deduced it was similar model to the ILI3941.  However, reading the device ID provides 0x7796, which indicates it is likely a generic ST7796 panel instead, which coincidentally shares the same command set as the ILI device.  With this and some code provided by jmz52 to scale up the Marlin output to a larger resolution, I was able to provide the Marlin GUI to cover most of the Lerdge screen.

    This was intended as a proof of concept more so something to be distributed, IMO the best course of action is to wait until full Marlin 2.0 support is provided.

  • LCD Support in Marlin

    J.C. Nelson01/09/2019 at 07:07 0 comments

    With some help from Dzenik, I managed to get a working LCD on Marlin 2.x, though some of it is hacked together. Initialization isn't working the way I'd expect, so I'm manually calling the LCD init code.

    After that, the LCD writes just work, though I don't currently have pixel tripling working.

    Now, Mickey had already gotten the LCD working on his Marlin build - his is based off of Marlin4ST, mine is from 2.x, but we're both working toward the same goal.  I'll get the scaling working soon, then hammer out the issues with LCD init so it works with U8G the way we'd expect.

  • SDIO Support

    J.C. Nelson01/03/2019 at 18:49 0 comments

    Sometimes, it's less about what you do and more about what other people are doing around you.  In this case, someone was already working on adding support for SDIO to Marlin.

    This gave a nice way to abstract away the details of block reading, and THAT gave me a simple way to plug in code. I started using the STM32SD library (and still am using code derived from it) but hit a problem where no matter what, the block reads failed.

    After a great deal of investigation, I found that the block read calls were passing in the block SIZE as the block number, meaning that in many cases, huge chunks of memory were getting trampled.  A few fixes later, we have the following output from the ESP8266:

    M20
    Begin file list
    echo:Cannot open subdir JOURNA~1.COR
    echo:Cannot open subdir JOURNA~1.LIV
    echo:Cannot open subdir JOURNA~1.COR
    echo:Cannot open subdir JOURNA~1.SCA
    echo:Cannot open subdir JOURNA~1.LIV
    echo:Cannot open subdir JOURNA~1.COR
    echo:Cannot open subdir JOURNA~3.LIV
    TEST.GCO 304884
    TES~1.GCO 304884
    End file list
    ok
    

    This code needs to be vastly cleaned up - I literally imported the bsp_sd h and c files directly, but they don't use DMA, there's the afore-mentioned "passing the wrong parameters" bug, and in general, a lot to do before I can proclaim it works. Also troubling is that if I re-init the SD card, it crashes, but that's a problem for another day. 

    Getting closer and closer to that first test print.

    Also, another member has successfully initialized and written to the LCD. I haven't done this yet, but they have. So, bit by bit, it's coming together.

  • Some Utilities Uploaded

    J.C. Nelson01/03/2019 at 16:14 0 comments

    I'm uploading the cfg and scripts I use to reset the lerdge board. THe paths on these are probably all wrong, but it should make your life a little easier if you're hacking.

  • Marlin! (Round 2)

    J.C. Nelson12/30/2018 at 01:02 0 comments

    First off, some clarifications from discoveries since the last log:

    1. The USB B /CH340 and ESP8266 share the same USART, Serial1. This is why plugging in USB kills the ESP - they didn't want conflicts.

    2. I've had no success getting USB working through the female connector, despite having a spare A->A cable. The serial that works is the output of the CH340, and it should be zero surprise it works since it's basically a dedicated FTDI clone.

    Secondly...never accidentally leave test code in.

    I removed a "blink forever" line from Marlin's main, re-enabled watchdog, and boom, I can issue commands to Marlin. After a few more adjustments it will be time to plug it into the printer.

    Did I mention you can do WIFI printing? Yeah. You connect to Marlin by telnetting to Port 23 on the ESP and using the Serial bridge. Soon Windows, Com0Com will give you a virtual com port for Marlin. Or ESP3D could be run.

    What does not work:

    SD. Marlin uses SPI. This board uses SDIO. I need to test if SDIO via Arduino libraries works.

    LCD. Nope, not even a little bit, yet. I'll need to figure out FSMC initialization before it will work.

    All changes are pushed to my github, so you can enjoy if broken builds of Marlin are your thing.

    start
    echo: External Reset
    Marlin bugfix-2.0.x
    
    echo: Last Updated: 2018-01-20 | Author: (xC0000005, Lerdge-X Config)
    echo:Compiled: Dec 29 2018
    echo: Free Memory: 51035  PlannerBufferBytes: 1344
    echo:Hardcoded Default Settings Loaded
    echo:  G21    ; Units in mm (mm)
    
    echo:Filament settings: Disabled
    echo:  M200 D3.00
    echo:  M200 D0
    echo:Steps per unit:
    echo:  M92 X80.00 Y80.00 Z4000.00 E500.00
    echo:Maximum feedrates (units/s):
    echo:  M203 X300.00 Y300.00 Z5.00 E25.00
    echo:Maximum Acceleration (units/s2):
    echo:  M201 X3000.00 Y3000.00 Z100.00 E10000.00
    echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    echo:  M204 P3000.00 R3000.00 T3000.00
    echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
    echo:  M205 B20000.00 S0.00 T0.00 X10.00 Y10.00 Z0.30 E5.00
    echo:Home offset:
    echo:  M206 X0.00 Y0.00 Z0.00
    echo:PID settings:
    echo:  M301 P22.20 I1.08 D114.00
    echo:SD init fail
    G1 X
    ok
    M503
    echo:  G21    ; Units in mm (mm)
    
    echo:Filament settings: Disabled
    echo:  M200 D3.00
    echo:  M200 D0
    echo:Steps per unit:
    echo:  M92 X80.00 Y80.00 Z4000.00 E500.00

  • USB!

    J.C. Nelson12/29/2018 at 06:35 2 comments

    After my last post, I went back and studied how code that actually can initialize the board correctly worked. With a little borrowed code from micropython sample, I was able to initialze the board successfully, and communicate outbound at much faster rates. Inbound data works in a test sketch, but not in Marlin yet. Now I can use USB instead of having to wire up to the serial1 via a FTDI clone. 

    Now I have an ESP8266 hooked to Serial1 and output via USB, so in general, this is very good. 

    Notes on the ESP module - For some reason, if I plug into USB, it cuts power to the ESP8266 module. These two do not share the same pins, so there's no logical reason I can find for this. Marlin supports two serial ports in 2.x, so it would be nice to enable both. Perhaps there's a cutoff circuit on the expansion module that can be disabled - I'm not sure yet.

    I'm just happy to be able to send and receive data via USB.

  • Lerdge Clock Issues Identified

    J.C. Nelson12/29/2018 at 01:55 2 comments

    I noted in the previous log that the failure to run at faster baud was probably clock related. Today I built a binary that dumps the oscillator and clock configs to see how the bootloader and reboot works, and here's what I found - "Letting the bootloader configure the clock" is bad. 


    Here's the clock config from both:

      OscillatorConfig:
      OscillatorType:15 (all of them)
      HSEState:0
      LSEState:0
      HSIState:1
      HSICalibrationValue:16
      LSIState:0
      PLLConfig:
      PLL.PLLState:1
      PLL.PLLSource:0
      PLL.PLLM:16
      PLL.PLLN:192
      PLL.PLLP:2
      PLL.PLLQ:4
      Obtaining Clock Config:
    
      Obtained Clock Config
    
      ClockType:15
      SYSCLKSource:0
      AHBCLKDivider:0
      APB1CLKDivider:0
      APB2CLKDivider:0
      Flash Latency:5
    

    So, that's what is wrong. If I attempt to initialize the oscillators, the board hangs, so I need to debug to this and figure it out.

  • Connecting an ESP8266-01 to a Lerdge Board

    J.C. Nelson12/28/2018 at 19:24 1 comment

    If you own the lerdge USB/Wifi printing module, you've probably looked at that 8 pin header and thought "It would be nice to do serial printing." And it probably would. However, in the lerdge store's description, they basically say other ESP8266-01 modules don't work.

    It's sort of a lie, sort of not. Lerdge does not release their firmware (though anyone with a module could dump it), and they don't document how the connection works. But that doesn't mean much to me, so I ordered a $2 ESP8266-01 from China, and when it arrived, I flashed ESP-LINk on it and plugged it into the lerdge. After adjusting for my hideously slow baud rate (again, probably a clock problem)

    I got the following output:

    So...can we enable standard Wifi Serial printing? Yes.

    Is it easy/Working? Not yet. But it's not far off. 

    There's no custom code other than my marlin build at work here, so it's almost certain we can use the ESP8266 wifi printing code directly on the board once we get it running. I'll be checking the oscillator config soon to see why we're having problems, and I'm hoping that's directly related to why USB and SDIO don't work yet.

  • Marlin...sort of.

    J.C. Nelson12/24/2018 at 02:08 1 comment

    Today, while taking a break, I sat down and studied why it was that something like simple serial communication didn't work. I could bit-bang serial, sure, but the USARTs are present and hooked up for a reason.

    I began studying how the firmware initialized the USART (which it does while upgrading the bootloader) and noticed that much of the time, the USB_OTG init was used.

    Which would not leave those pins free for Serial.

    So I made a few changes to the pins map and tried again, and this time, got a beautiful spew, so long as I keep the baud rate slow. That may be a side effect of my FTDI clone, or maybe it's some initialization issue with the serial port, but the very next thing I did was set Marlin's serial port to 1, baud rate to 9600, and compiled. After booting it attached to the adapter...

    --- Miniterm on /dev/cu.usbserial-A4012RZG  9600,8,N,1 ---
    --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
    start
    echo: External Reset
    Marlin bugfix-2.0.x
    
    echo: Last Updated: 2018-01-20 | Author: (xC0000005, Lerdge-X Config)
    echo:Compiled: Dec 23 2018
    echo: Free Memory: 51139  PlannerBufferBytes: 1344
    echo:Hardcoded Default Settings Loaded
    echo:  G21    ; Units in mm (mm)
    
    echo:Filament settings: Disabled
    echo:  M200 D3.00
    echo:  M200 D0
    echo:Steps per unit:
    echo:  M92 X80.00 Y80.00 Z4000.00 E500.00
    echo:Maximum feedrates (units/s):
    echo:  M203 X300.00 Y300.00 Z5.00 E25.00
    echo:Maximum Acceleration (units/s2):
    echo:  M201 X3000.00 Y3000.00 Z100.00 E10000.00
    echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    echo:  M204 P3000.00 R3000.00 T3000.00
    echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
    echo:  M205 B20000.00 S0.00 T0.00 X10.00 Y10.00 Z0.30 E5.00
    echo:Home offset:
    echo:  M206 X0.00 Y0.00 Z0.00
    echo:PID settings:
    echo:  M301 P22.20 I1.08 D114.00
    echo:SD init fail
    

    This is a thing of beauty. It's sitting on my table, blinking. It doesn't receive anything. I know or a fact the purple pin (lower left, if you're holding it so the USB adapter is facing upwards) is the TX. Nothing else works. Connecting to the right pin (the upper right, which is where a normal ESP2866 module would have RX) doesn't let me send anything. There's something missing - I'm just not sure what, yet.