Serial Control

[dbrgn]

It would be great if there would be a serial interface for controlling the desk lift from the computer!

I have started a similar project for an Actiforce desk lift: https://github.com/dbrgn/desklift/ It's not done yet, but the serial protocol used is the following:

- Baudrate 115'200
- Every command is a single signed byte
- Positive values move up, negative values move down
- The value must be multiplied by 0.1s to get the move duration

So for example when sending 0x13, the desk would move up for 1.9 seconds.

This should be quite simple to implement I in the firmware. The issue would probably be available pins.

It looks like the ATtiny841 has two USART. If I read your schematics correctly, USART0 is used by the LIN transceiver. USART1 is available at PA4/PA5, but those pins are shared with SCK/MISO from the programming header... But maybe this could be solved somehow, e.g. by automatically disconnecting the serial pins if there's power on the programming header?

[tagno25]

The way that the load command is implemented, the controller thinks that you have pressed the button repeatedly. This implementation makes values 0, 1, and 16 unable to be used for memory locations.

[gcormier]

I've merged into the serial branch. I"ve just applied some memory tweaks (mainly int's to byte's).

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.3% (used 232 bytes from 512 bytes)
Flash: [==========]  97.5% (used 7984 bytes from 8192 bytes)

We can save another 28 bytes of memory by changing pushCount from int to byte, but it has some effect on your serial code, mainly push_addr in some functions that do bit shifting.

[tagno25]

I have converted pushCount, push_addr, and memorySlot to from int to uint8_t. As well as changing recvInProgress from bool to uint8_t. I have also changed all the byte to uint8_t to maintain a standard.

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.1% (used 231 bytes from 512 bytes)
Flash: [==========]  96.9% (used 7936 bytes from 8192 bytes)

LIN_MOTOR_IDLE could also be changed to uint8_t which would save 42 bytes.

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.1% (used 231 bytes from 512 bytes)
Flash: [==========]  96.4% (used 7894 bytes from 8192 bytes)

[gcormier]

Okay I've changed LIN_MOTOR_IDLE

:) I actually change all the uint8_t to byte. All the same I guess :)

My plan is to let the serial branch "soak" for a bit and hopefully have people run it to comment. I'd like to run it for a month having it stable before merging to master.

I also need to consider if serial should be added with compile-time options. If the code base for other options grows based on some of the other features (motor recalibrate), that would explode our memory consumption and would mean we'd need to choose the features at compile time to fit on the attiny841. I can see if there any other avr's that have a similar price point but more memory.

[gcormier]

The new AVR 1624 looks great - 16kb of program memory, 2kb RAM and 2 hardware UARTs. It's delay and not available yet, will be probably the summer until they're obtainable in a reliable qty, but maybe late spring I can get one to start a prototype.

[dbrgn]

Oh wow, they still make new 8-bit AVR models? Nice, I thought those were deprecated in favor of the 32 bit SAMD series 🙂

[gcormier]

Okay I've got the serial branch flashed on my desk, I'll run it for a few weeks before merging to master. Even then it may be disabled by default as I think 99% of folks won't use the serial function. Those who want to use it will need to open up the board and solder on a header anyways and get their hands dirty.

[tagno25]

It seems that the output from holding the up and down buttons is incorrect. The write commands are being called faster than the desk is able to move to the next position. I am thinking that the only easy way to fix it, is to change the output to be a "=" command with the target height.

[gcormier]

This is now in the newly made dev branch. I think I'll close this issue and if there's more work needed we can open another one or re-open this one if it makes more sense.

[tagno25]

With the new ability to use both buttons for memory, should the load function be modified to work with the down button?

I can think of the following two options:

• new command (lowercase L?) to load the down button memory positions (+26 bytes)
• if the memory position is above DOWN_SLOT_START, and bothmode is enabled, then act like the down button was pressed (+24 bytes)

[gcormier]

That works for me!

[philwmcdonald]

Another view. I've just been L(oading)/S(toring) 32+down_slot value. The other end of the serial link has to be programmed too, the translation might be easier on whatever communicates with megadesk. Chances are it's less resource constrained than this attiny.

[philwmcdonald]

I've been working on a plain-ascii human-interfacing serial mode, no need to talk/read raw-serial bytes. It appears to be robust provided you don't paste more than 16character at a time. accepts the same commands but in plain ascii like:

<T2000,255
<=3000,. 
<C0.0.  
<+200,0.  
<L.2. 
<C.. 
<R,0
<R.34

(the 2 numeric fields are terminated by any non-numeric character like a newline or .) Note the use of the small L command below.

<T2000,255
<C0,0
>=1545,0
<l0,2
>L1683,34
>+21,0
>=1629,0
>+9,0
>=1638,0
>+12,0
>=1650,0

This mode pushes the flash usage extremely close to the maximum. So with this on, there's little space for new features.

see #70