Home/ Questions/Q 6372939
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T01:18:06+00:00

I am currently working on a control system for Arduino type devices using Twisted,and

  • 0

I am currently working on a control system for Arduino type devices using Twisted,and have a bit of a design issue

Here is how things are currently: (sorry in advance, might be a bit long)

  1. to handle different type of devices (each having a different firmware & communication protocol ) i have a designed a “driver” system :
    • each driver is made of :
      • a “hardware handler class” : a wrapper around Twsited’s serial class with a few added helper methods
      • a custom serial protocol

2- While implementing drivers for Reprap 3d printers (also based on arduino, also using a serial connection) with rather specific protocols (ie enqueue point, set temperature etc), i have started to wonder if i am placing the methods for handling those features (each having specific commands) in the right place..

This all leads me to my questions:

I am not quite sure about the good practices as far as twisted protocols go , but having looked through the documentation / code of quite a few of them, it seems they tend to have relatively few methods

  • is this always the case? should the protocol only be used for very low level functions and in/out formatting and communication ?
  • certain devices i want to manage have very clearly defined protocols (Makerbot etc), should i consider general protocol specifications to be a different thing then the actual Twisted protocol classes i am creating ?

Any advice, tips and pointers are more than welcome !
Thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ll try my best at answering a, well, quite general question.

    1) The interface that make up a Twisted protocol has only 4 methods:
    http://twistedmatrix.com/documents/11.0.0/api/twisted.internet.interfaces.IProtocol.html
    So this will be where all the interaction between your protocol implementations and Twisted happens.

    2) Besides instances of protocol, there is of course the factory which produces instances of your protocol (for each new connection). So for example, stuff that should be available to all connections (like i.e. current number of connected clients, whatever) naturally resides there.

    3) Of course it might make sense to build small class hierarchies, where you derive from Protocol, implement stuff that is shared by all your subprotocols, and then only implement the subprotocol specifics again in a derived class.

    • 0