All in one chunk because the infrastructure is already there.
This also implements the parallel 4-bit bus used by quite some
displays.
For now you have to add quite a number of #defines to your
config.h. First, there are all the pins required, pin names
changed to your actual board/display connection, of course:
#define DISPLAY_RS_PIN PC1
#define DISPLAY_RW_PIN PC0
#define DISPLAY_E_PIN PD2
#define DISPLAY_D4_PIN PD3
#define DISPLAY_D5_PIN PD4
#define DISPLAY_D6_PIN PD5
#define DISPLAY_D7_PIN PD6
And then the information about the display actually existing:
#define DISPLAY_BUS_4BIT
#define DISPLAY_TYPE_HD44780
Allowing to do all this in Configtool is forthcoming, of course.
CoreXY turns the X and Y motors to render a target position differently
than straight cartesian printer does. From the theory page on corexy.com,
where the motors are called A and B instead of X and Y:
dx = 1/2(dA + dB), dY = 1/2(dA - dB)
dA = dX + dY
dB = dX - dY
Accordingly, each step of a single motor results in half of a step in the
X or Y axis. To simplify this and not lose steps, make the pos[] array
hold 2*steps instead of single steps. Adjust back to single steps with
/2 where needed. Store 2*steps whenever writing to pos[] variables
which are not coreXY driven.
Since each step of X or Y (A or B) affects both X and Y position, send
updates to record_pin for all axes instead of only the "affected" axis.
The function record_pin will ignore reports for pins which did not change
from the previous call. This also helps us keep from reporting duplicate
positions for half-steps in coreXY mode, too.
Provide a simulated, simplified representation of the action of
mechanical endstop switches which turn on and off at slightly
different amounts of pressure. When any axis moves past -10,
simulate endstop "on" condition. When the axis moves to 0,
simulate the endstop "off" condition.
This support allows the simulation of G28 (home) commands.
The simulator code is compiled with different definitions than the
rest of the code even when compiling the simulator. This was done
originally to satisfy the compiler, but it was the wrong way to go.
The result is that the main Teacup code may decide to do things one
way (X_INVERT_DIR, for example) but the simulator code will do
things a different way (no X_INVERT_DIR).
Fix this by including the board and printer definitions also in the
simulator code, and use a simple enum trick to give consistent
definitions to the needed PIN definitions, safely ignoring the ones
the config does not use.
This requires that we include simulator.h after 'config.h' in all cases.
Manage that by moving simulator.h from its previous home in arduino.h
into config_wrapper.h.
After this change we will be able to reliably communicate the expected
state of the endstop pins from the simulator.
dda_clock() might be interrupted by dda_step(), and dda_step might
use or modify variables also being used in dda_clock(). It is
possible for dda to be modified when a new dda becomes live during
our dda_clock(). Check the dda->id to ensure it has not changed on
us before we actually write new calculated values into the dda.
Note by Traumflug: copied some of the explanation in the commit
message directly into the code.
dda_clock() might be interrupted by dda_step(), and dda_step might
use or modify variables also being used in dda_clock. In particular
dda->c is modified in both functions but it is done atomically in
dda_clock() to prevent dda_step() from interrupting during the
write. But dda->n is also modified in both places and it is not
protected in dda_clock().
Move updates to dda->n to the atomic section along with dda->c.
Note by Traumflug: good catch! It even makes the binary 14 bytes
smaller, so likely faster.
Yes, these strategies feel a lot like heading into uncharted
territory, because I can't find notable textbook examples on how
to select between various "classes" at compile time. Nevertheless,
it works fine, binaries are small and fast and as such it can't
be _that_ wrong.
Some target devices need extra avrdude command line switches to
get them to upload successfully. There are dozens of options which
may be useful to different people. Instead of breaking all the possible
options out into separate fields, provide a generic "Program Flags" text
field which the user can fill in similar to the CFLAGS and LDFLAGS
settings.
The Arduino Mega2560 bootloader was changed[1] to report an error when
asked to erase flash because it has never actually implemented erasing
flash. To program this bootloader with avrdude requires the -D switch
to avoid flash erase. But it seems that every arduino will work fine
with -D, as evidenced by the fact that the Arduino IDE always [2]
includes -D in the avrdude commandline. Presumably the flash is erased
during/before programming anyway and the separate erase step is unneeded.
Perhaps the -D should be always added to avrdude command line in
configtool and in Makefile-AVR. But I haven't tested any other boards
yet, and I'm being more cautious even though the Arduino IDE does
otherwise.
[1] arduino/Arduino#543
[2] d8e5997328/app/src/processing/app/debug/AvrdudeUploader.java (L168)
A few days before being done with this display hardware decided
say good bye. Accordingly I can't continue with writing related
code. Writing down what already works and what's still missing is
probably a good idea, to make sure the next fellow doesn't have
to investigate from scratch.
Currently not implemented because this costs additional binary
size and, well, with I2C being reliable now, it's difficult to
test it. And also because I'm lazy :-)
- Flag I2C_MODE_FREE was misleading, because one couldn't test
for it the same way as for I2C_MODE_BUSY. At an error
condition, 'i2c_mode & I2C_MODE_FREE' would still evaluate
to true.
- On error, drop not only the buffer, but the entire
transmission.
All of a sudden, the display works reliably, even at the
previously shaky speed of 100'000 bits/s!
TBH, probably I didn't understand some parts of Ruslan's code
earlier but tweaked it anyways. Shame on me!
If all error conditions are handled the same, there's not much
point to use distinct code for each of them.
Also, handle collisions like the other error conditions.
This saves a nice 52 bytes of program memory.
Program: 24404 bytes
Data: 1543 bytes
EEPROM: 32 bytes
Now we shouldn't experience wait cycles in i2c_write() during
typical display writes any longer. It should also distribute CPU
load of display writes a lot better.
Previously writing a line of text to the display would take
almost as long as it took to actually send it to the display,
because the I2C queue could hold only one transmission, which
effectively meant only one character. This could hold the main
loop for several milliseconds.
Now we queue characters, send them one by one, and return to the
main loop in between.
This costs 160 bytes program memory. Only 18 bytes RAM, because
the I2C queue was reduced accordingly. Now:
Program: 24456 bytes
Data: 1543 bytes
EEPROM: 32 bytes
This is
- clearing 'i2c_should_end', so i2c_write() doesn't hang and
- draining the buffer on errors.
This way we loose the remaining transmission, which is typically
half a character, but we no longer stall the entire firmware main
loop.
Actually, such error conditions are surprisingly frequent, at
least on the test hardware. Now they result in some flickering
of the displayed numbers.
This isn't pretty at all, but it shows the principle.
Unfortunately it also exploits a bug in the I2C sending mechanism,
I2C sending hangs a few seconds after reset.
Point of this change is to allow using these functions for
writing to the display, too, without duplicating all the code.
To reduce confusion, functions were renamed (they're no longer
'serial', after all:
serwrite_xxx() -> write_xxx()
sersendf_P() -> sendf_P()
To avoid changing all the existing code, a couple of macros
with the old names are provided. They might even be handy as
convenience macros.
Nicely, this addition costs no additional RAM. Not surprising, it
costs quite some binary size, 278 bytes. Sizes now:
Program: 24058 bytes 168% 79% 38% 19%
Data: 1525 bytes 149% 75% 38% 19%
EEPROM: 32 bytes 4% 2% 2% 1%
Regarding USB Serial: code was adjusted without testing on
hardware.
You see where the journey is going? This is the equivalent to the
function to write a character to the serial line, so we can
basically swap these two in other functions.
Monospaced fonts require a bit less space, right now it saves a
nice 110 bytes binary size.
Actually, the distinction between monospaced and proportional
fonts was in font.h already, so not supporting them was a bug.
But so far we have no monospaced font, so nobody noticed.
Note by Traumflug: this code was written by Ruslan Popov a lot
earlier already. I picked it to i2c_test.c to get "something"
visible running. This is the commit finally adjusted to the new
display infrastructure.
While this could also be done properly now, with a couple of
additional fonts, this would require quite some time. However,
it's more important to have at least one display working now,
rather than having a ton of sophisticated eye-candy, which isn't
even user-visible, because the upper layers are still missing.
What 'make size' previously reported was misleading, because
it didn't count the .data section as Flash usage. However, this
section is actually written to Flash.
The .data section holds the data needed for inititalising
variables. As such it counts to both, Flash and RAM usage.
Nice verification: reported 'Program' size now matches upload
size reported by avrdude exactly.
There's now the tool 'avr-size', which makes reading such stuff
much easier:
avr-size -C build/teacup.elf
Example output:
AVR Memory Usage
----------------
Device: Unknown
Program: 23704 bytes
(.text + .data + .bootloader)
Data: 1543 bytes
(.data + .bss + .noinit)
EEPROM: 32 bytes
(.eeprom)
So far for choices based on boolean sets, only, because choices
for values typically need no more readable names.
This elegantly removes the somewhat ugly check for '(', too.
Having a choice with a defined set of options is nice, but it
also requires these options to be #defined somewhere _before_
entering config.h. To keep class-like encapsulation, we'd need
two header files for each code unit, one for the options, another
one for the usual header.
That said, we use other examples of such options, e.g. CPU, F_CPU
or KINEMATICS. For CPU and F_CPU it works fine, because their
options are numbers or other values known by the compiler. For
KINEMATICS it kind of works, because this #define is used in only
one place ... and there it's suboptimal already, because no option-
set.
Anyways, I was unsure about this change and if it turns out to be
a poor decision later, it can be reverted.
Most work by Ruslan Popov, collected from various commits and
made compatible with regression tests by Traumflug.
Display test code is now enabled by #defining DISPLAY_BUS to
i2c_twi.
Markus Hitter
Phil Hord
Phil Hord
Ruslan Popov