Supporting ReprapWorld's LCD screen

[brupje]

I have made a commit in my development fork to get the graphical LCD screen working https://github.com/brupje/Repetier-Firmware/tree/development

Some things which are rather strange to me and need clarification, before I can make a pull request:

1. I had to remove line 2366 in ui.cpp, before I could compile. Is that a problem with my settings? If so, which?
2. I had to add settings in ui.h (#elif (MOTHERBOARD == 409) // Ultratronics) which strike me as odd. Should this not have been added to pins.h?
3. What is the correct place to do some init code specifically for Ultratronics? For example it's necessary to pull all CS pins high, as otherwise there is a problem communicating to SD, LCD and Ethernet for example.

[repetier]

1. 2366 is empty in your github. Do you mean the closing brace for u8glib? I could compile it, but have recently changed some code there so we may talk about different lines and error or I introduced it for your config, also I could compile for u8glib.
2. Currently display mappings are in ui.h that is correct. But to which display did you assign your special case as there is no ultratronics display.
3. In ui.cpp line 945
   void initializeLCD()
   {

add a #if condition for your combination and do what is needed. Here the basic lcd is initalized so that seems to be a good place.

[brupje]

1. Correct, had to remove the }

2, These are rather boards mappings instead of LCD mappings I think, as there is also a megatronics board for example. So maybe it's meant to be like a display-board mapping. But why not do that in pins.h? Anyway I added 409, Ultratronics in my commit at line 825

1. Well, thats rather LCD specific, but this more board specific. You always want ALL CS pins to be put high, whether you are using all SPI devices or not, whether you are using a LCD or not for example

[repetier]

Well main problem is that you can have 10 different displays working with a board and each display might use different pins. So have spi, some hardwrae spi, some 4 pin parallel and so on. So what we did is list the displays in ui.h and select pins for the display/board combination.

1. Yes, CS should be high if not used. Where do we not do it? I assume u8g init sets cs also high during initalization.

[brupje]

ok fair enough

1. Well on Ultratronics are 4 thermo ocuple chips communicating with SPI. But if you only define two extruders, two of them won't be set to output/high and therefore will be floating and causing errors in reading temperatures.

[Engineer3DPrototyping]

Just as FYI i have been unable to get both the SD card and the thermocouples to work together with any version of repetier firmware and I am using all 4 thermocouples. take a look at this post to see a logic analyzer data file. my best guess is that the sd library in not releasing the hw spi buss which as you know is the only buss available on the ultratronics. b3286c0#commitcomment-18253290

[repetier]

Uploaded a fix for 1. It was only when you have u8glib without UI_HEAD, then closing bracket count was wrong due to wrong #if conditions. Fixed in current version.

I remember the due cs problem now. Due sets CS high/low on it's own - but does this for the 4 pins that support cs. So while thermistor sets CS manually, due also sets the sd hardware pin of one of these 4 to low, which caused the incompatibility.

[brupje]

>Just as FYI i have been unable to get both the SD card and the thermocouples to work together with any version of repetier firmware and I am using all 4 thermocouples. take a look at this post to see a logic analyzer data file. my best guess is that the sd library in not releasing the hw spi buss which as you know is the only buss available on the ultratronics

I think that's due to a problem in HAL.h, when I comment out the SDSS pin, LOW and HIGH it will work for me. SD support doesn't work after that obviously, but I really don't see why SDSS should be touched in this file.

static inline uint8_t spiReceive()
{
//WRITE(SDSS, LOW);
uint8_t b = spiTransfer(0xff);
//WRITE(SDSS, HIGH);
return b;
}

T:21.25 /0 @:0 T0:21.25 /0 @0:0 T1:22.00 /0 @1:0

> I remember the due cs problem now. Due sets CS high/low on it's own - but does this for the 4 pins that support cs. So while thermistor sets CS manually, due also sets the sd hardware pin of one of these 4 to low, which caused the incompatibility.

Doesn't apply I think, as the code isn't using hardware SPI as far as I can see.

Anyway, I want to do init stuff somewhere. Would it be acceptable to do this in printer::setup() in case we have an Ultratronics? Something like:
void Printer::setup()
{

#if ultratonics
/* avoid floating pins */
SET_OUTPUT(ORIG_FAN_PIN);
WRITE(ORIG_FAN_PIN,LOW);
SET_OUTPUT(ORIG_FAN2_PIN);
WRITE(ORIG_FAN2_PIN,LOW);

SET_OUTPUT(HEATER_0_PIN);
WRITE(HEATER_0_PIN,LOW);
SET_OUTPUT(HEATER_1_PIN);
WRITE(HEATER_1_PIN,LOW);
SET_OUTPUT(HEATER_2_PIN);
WRITE(HEATER_2_PIN,LOW);
SET_OUTPUT(HEATER_3_PIN);
WRITE(HEATER_3_PIN,LOW);

/* setup CS pins */
SET_OUTPUT(THERMOCOUPLE_0_PIN);
WRITE(THERMOCOUPLE_0_PIN,HIGH);
SET_OUTPUT(THERMOCOUPLE_1_PIN);
WRITE(THERMOCOUPLE_1_PIN,HIGH);
SET_OUTPUT(THERMOCOUPLE_2_PIN);
WRITE(THERMOCOUPLE_2_PIN,HIGH);
SET_OUTPUT(THERMOCOUPLE_3_PIN);
WRITE(THERMOCOUPLE_3_PIN,HIGH);

SET_OUTPUT(ENC424_SS);
WRITE(ENC424_SS,HIGH);
SET_OUTPUT(SDSS);
WRITE(SDSS,HIGH);

#endif

[brupje]

Commit 4c0333e in my repository changes SDFat / HAL so that it moves the CS logic from HAL to SDFat. I now have the LCD, 2x 31855 thermo couples and SD working. I'll try to put the board in an actual printer, so I can test stability a bit.

[repetier]

Never thought about software spi. Always had hardware in mind here. I guess with the SDSS you are totally right, also I need to check all other codes using these functions. Then with software SPI we do not have the due automatic from hardware spi autochanging cs and the problem dissipates.

I'm not sure I like your init script also position would be ok. When the pins are used the pins get initialized anyway. If they get not used the state is not relevant and all are on input state I think, which has low risk of anything bad happening. If any board would activate all pins on startup we would have 2000 extra lines.

Maybe a better solution for special handling needed would be a macro that every board could create, like

#ifdef BOARD_INITALIZATION
BOARD_INITIALIZATION
#endif 

And then put such stuff inside pins.h in the board definition so we get not 1000 lines disturbing reading the real code.

[Engineer3DPrototyping]

I think I added most of your adjustments. This seems to get close to working and from what I can see there are only two functional problems that have cropped up. 1 the lcd has 2 horizontal lines running across it that cause the lcd a rep rap full graphic display ~~ similar to the rep rap worlds lcd( I also had this error from the earlier dev branch). and when I tried to print a file from sd in the temperature signals were getting confused with the data transfer. Somehow with the code I have still allows the buss to have 2 devices talking at the same time only now it was only some of the time opposed to all of the time.

[brupje]

I have commited the init sequence in my dev repository. I added some init code to pins.h and detect if it's enabled in Printer::setup.

The printer has been running with Repetier all day without problems so far, so my changes look stable enough.

Let me know when you are ready with the SDSS thing, I'll test it my my codebase and give you a pull request for my other changes

[robustini]

Hi @brupje, i've Ultratronics Pro V1.0, please can you explain how did you run ReprapWorld's LCD screen and how did you connected to the board?
You mean the SPI LCD? This one?
No way for others common LCD?

https://reprapworld.it/products/printers_printing/stampa_autonoma/graphical_lcd_screen_v1_0/

[robustini]

Ok, Ultratronics does support only the linked LCD, so now @repetier what do you think to merge in your development branch the code of @brupje?

[repetier]

I have to check when I'm back. Need to figure out what he added since his code also lags behind.

[brupje]

I have synced my development branch with repetier and fixed a few things. Please see pull request #646