Problem: Can not use LCD display from DSL

[frp-arduino]

Problem: Can not use LCD display from DSL

[mvcisback]

Are you referring to something like this: http://arduino.cc/en/Tutorial/LiquidCrystal ?

Getting something to appear on screen should be describable using the DSL because it only requires digital pins. The problem is reacting or changing the input.

[rickardlindberg]

Yes, that is exactly what I'm referring to.

My initial though was to do something like this:

lcd = [all the pins needed] -> Output Command

data Command = Clear | WriteText Int Int String

Then create LLI for outputting a command on the LCD. Then connect a stream of commands to that output.

I also thought about only using the outputs available (Output Bit), but the LCD seems to require quite a lot of syncronisation between the different outputs and modelling that with streams I found clumsy.

[mvcisback]

@rickardlindberg, indeed it requires quite abit of sync between the streams.
I think a good solution that is potentially more general are the product streams.

I.E.

prod :: Stream a -> Stream b -> Stream (a, b)
type LCD = Stream (Byte,Byte,Byte,Byte ....) -- I don't actually know the correct structure off hand

data Command = Clear | WriteText Int Int String

lcdAction :: LCD -> Command -> Action ()

Where I think prod is equivalent to Monoid.(<>)

[rickardlindberg]

Your suggestion got me thinking. Not sure if this is exactly what you mean, but I think it works out beautifully. Let me elaborate:

Let's say we have two regular pin outputs:

pin10 :: Output Bit
pin11 :: Output Bit

then we can join them with a function like this:

join :: Output a -> Output b -> Output (a, b)
join outputA outputB = ...

pinPair :: Output (Bit, Bit)
pinPair = join pin10 pin11

Now we can attach a stream of (Bit, Bit) to the pinPair output:

pinPair =: clock ~> mapS (\tick -> (isEven tick, not (isEven tick)))

This requires that we have tuples in the generated C code. Once we have that, it should be easy to extend to tuples of aribtrary size. And then we can create the tuples needed for LCD.

[rickardlindberg]

I've been working on implementing the join function and related functionality. It looks promising. I will probably complete it tomorrow.

[mvcisback]

@rickardlindberg yeah, that's the basic idea behind what I had in mind.

Question, is join a Semigroup? Specifically, is join associative. i.e.

• if (<>) = join and a,b, and c are all Outputs
• then does (a <> b) <> c = a <> (b <> c)

This would be a nice property to have for automatic verification (makes for an easy QuickCheck test), is more modular (functions for 3 joined outputs always work the same way), and is much easier to reason about (again because if you join 3 output, it doesn't matter which order they were joined)

Also, I imagine you're just using structs to encode the tuple? If so, it might also be interesting to consider unions for more complicated sum types. Though, this might not be necessary for the current use case (I can't think of any good use case for this off hand)

[mvcisback]

So, I've looked into this, and there's no way to make this work using the traditional Semigroup definition. I.e. I think the math definition holds fine, but Semigroup and Monoid utterly fail to capture the right abstraction.

That said, I've started down a (potentially dangerous) rabbit hole of Control.Category which "could" encode this.

Also, I stumbled upon a post by Conal Elliot on formulating all this using CoMonads (which are often used to model infinite streams. I'll post if I can get a successful prototype.

[rickardlindberg]

It is now possible to do this:

main = compileProgram $ do

    pairOutput pin10 pin11 =: every 5000 ~> flop

flop :: Stream a -> Stream (Bit, Bit)
flop = foldpS doFlop (pair (bitLow, bitHigh))
    where
        doFlop :: Expression a -> Expression (Bit, Bit) -> Expression (Bit, Bit)
        doFlop _ state = pair (pairSnd state, pairFst state)

But extending it to tuples of any size was harder and clumsier than I thought. It should be relatively easy to create pairs of pairs, but the syntax quickly becomes horrible.

Will have to think about this some more.

[rickardlindberg]

I think I've found a much simpler solution that will not even require tuples. Will work more on it tomorrow.

[rickardlindberg]

My last attempt at a solution to this problem looked like this:

lcd :: Output Bit
    -> Output Bit
    -> Output Bit
    -> Output Bit
    -> Output Bit
    -> Output Bit
    -> Stream Word
    -> Action ()
lcd enable rs d4 d5 d6 d7 stream = do
    x <- def stream
    rs     =: x ~> mapS (getBit 4)
    d4     =: x ~> mapS (getBit 3)
    d5     =: x ~> mapS (getBit 2)
    d6     =: x ~> mapS (getBit 1)
    d7     =: x ~> mapS (getBit 0)
    enable =: x ~> mapS (\_ -> listConstant [ delayMicroseconds 10 bitHigh
                                            , delayMicroseconds 10 bitLow
                                            ])
                ~> flattenS

But I was unable to figure out how to implement the delays. Not sure how to proceed with this. Maybe I will just solve some other problems and the solution to this will become apparent later :-)

[rickardlindberg]

Here is a minimal (attempted at least) C program that initializes the LCD and outputs "Hhh" on the display:

#include <avr/io.h>
#include <util/delay_basic.h>

// rs     = 3 = PD3
// enable = 4 = PD4
// d4     = 5 = PD5
// d5     = 6 = PD6
// d6     = 7 = PD7
// d7     = 8 = PB0

#define WRITE_BIT(reg, bit, val) if(val) { SET_BIT(reg, bit); } else { CLEAR_BIT(reg, bit); }

#define SET_BIT(reg, bit) ((reg) |= (1 << (bit)))

#define CLEAR_BIT(reg, bit) ((reg) &= ~(1 << (bit)))

#define US_DELAY(x) (uint16_t)((F_CPU*(x))/4000000.0)

void push(uint8_t rs,
          uint8_t b3, uint8_t b2, uint8_t b1, uint8_t b0,
          uint16_t settle_time_delay_2) {
    WRITE_BIT(PORTD, PD3, rs)
    WRITE_BIT(PORTD, PD5, b0)
    WRITE_BIT(PORTD, PD6, b1)
    WRITE_BIT(PORTD, PD7, b2)
    WRITE_BIT(PORTB, PB0, b3)
    SET_BIT(PORTD, PD4);
    _delay_loop_2(US_DELAY(1));
    CLEAR_BIT(PORTD, PD4);
    _delay_loop_2(settle_time_delay_2);
}

int main(void) {
    // Configure as outputs
    SET_BIT(DDRD, PD3);
    SET_BIT(DDRD, PD4);
    SET_BIT(DDRD, PD5);
    SET_BIT(DDRD, PD6);
    SET_BIT(DDRD, PD7);
    SET_BIT(DDRB, PB0);

    // Init by writing all zeroes
    CLEAR_BIT(PORTD, PD3);
    CLEAR_BIT(PORTD, PD4);
    CLEAR_BIT(PORTD, PD5);
    CLEAR_BIT(PORTD, PD6);
    CLEAR_BIT(PORTD, PD7);
    CLEAR_BIT(PORTB, PB0);
    _delay_loop_2(US_DELAY(10000));
    _delay_loop_2(US_DELAY(10000));
    _delay_loop_2(US_DELAY(10000));
    _delay_loop_2(US_DELAY(10000));
    _delay_loop_2(US_DELAY(10000));

    // === Init sequence ===

    push(0, 0, 0, 1, 1, US_DELAY(4600));
    push(0, 0, 0, 1, 1, US_DELAY(4600));
    push(0, 0, 0, 1, 1, US_DELAY(250));
    push(0, 0, 0, 1, 0, US_DELAY(100));

    // Display lines and character font
    push(0, 0, 0, 1, 0, US_DELAY(100));
    push(0, 1, 0, 0, 0, US_DELAY(100));

    // Display off
    push(0, 0, 0, 0, 0, US_DELAY(100));
    push(0, 1, 0, 0, 0, US_DELAY(100));

    // Display clear
    push(0, 0, 0, 0, 0, US_DELAY(100));
    push(0, 0, 0, 0, 1, US_DELAY(2100));

    // Entry mode set
    push(0, 0, 0, 0, 0, US_DELAY(100));
    push(0, 0, 1, 1, 0, US_DELAY(100));

    // === DATA ===

    // Display on
    push(0, 0, 0, 0, 0, US_DELAY(100));
    push(0, 1, 1, 1, 1, US_DELAY(100));

    // 'H' (data 0x48)
    push(1, 0, 1, 0, 0, US_DELAY(100));
    push(1, 1, 0, 0, 0, US_DELAY(100));

    // 'h' (data 0x68)
    push(1, 0, 1, 1, 0, US_DELAY(100));
    push(1, 1, 0, 0, 0, US_DELAY(100));

    // 'h' (data 0x68)
    push(1, 0, 1, 1, 0, US_DELAY(100));
    push(1, 1, 0, 0, 0, US_DELAY(100));

    while (1) {
    }

    return 0;
}

It feels natural to implement push as an output in the DSL. It can be implemented imperatively as a sequence of instructions that actually write a command to the LCD.

It doesn't feel right to do this in the DSL.

But generating "push data" seems appropriate to do with streams.

If we go with this approach, then this somehow must be encoded in a datatype that can be passed around between streams:

uint8_t rs,
uint8_t b3, uint8_t b2, uint8_t b1, uint8_t b0,
uint16_t settle_time_delay_2

[mvcisback]

I think a nice high level wrapper for the LCD would be an output (LCD String) that would hide any of these implementation details.

I'm not quite sure what you mean by having push in the DSL. Is the basic idea that you want to synchronize the setting of a bunch a pins similar to what you are doing in the push function?

Going back to the idea of just tupling the pins, the only problem seems to be the enable pin.
Specifically, you need some way of noting that the enable pin is what is synchronizing everything else.

Maybe a syntax for that could be:

output (Sync (Bool, Bool, Bool, Bool, Bool) (EnablePin settleTime))

And when you compile, it prints out (or writes to a file) the pin layout so you know how to wire.

[mvcisback]

Or, I suppose keeping with the (=:), the pins would be known based on how the output was created