Loading ...
Sorry, an error occurred while loading the content.

Re: [smartsockets]Where and what? B7971

Expand Messages
  • John
    GUI is updated... Don t let my wife catch me playing with SmartSockets!!! http://www.tayloredge.com/reference/Circuits/1386SmartSocket/index.html jt
    Message 1 of 22 , Jan 31, 2010
    • 0 Attachment
      GUI is updated... Don't let my wife catch me playing with SmartSockets!!!

      http://www.tayloredge.com/reference/Circuits/1386SmartSocket/index.html

      jt

      --- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
      >
      > The full font management system is in place along with a simple animation utility.
      >
      > jt
      >
      > http://www.tayloredge.com/reference/Circuits/1386SmartSocket/editor.GIF
      >
      > http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
      > <controllers><[1386] SmartSocket>
      >
    • fixitsan2
      ... John, the new command is in binary format, not ascii. The reason for the change was because it was the best way to maximise the eeprom space (1008/4 bytes
      Message 2 of 22 , Feb 1, 2010
      • 0 Attachment
        --- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
        >
        > Chris,
        >
        > Changing the GUI to match whatever you come up with will be trivial.
        >

        John, the new command is in binary format, not ascii. The reason for the change was because it was the best way to maximise the eeprom space (1008/4 bytes per digit)

        The new command to write a UDC is as follows

        $B7W<d><c><16-bit segment pattern>

        "$B7W" is the ascii header, same as before

        "d" is the binary digit position, range = 1-254
        "c" is the UDC character position to write, binary 0 - 125
        "16-bit pattern" is the segment pattern. Same as the original version except the "0" and "1" characters are no longer ascii character 0 and 1, but are binary numbers 0 and 1

        NB there is no CR/LF following this command because each byte is counted on arrival.

        I hope to change the other smartsocket types to use this format in the future, but in the meantime using the 'wrong' UDC write instruction type for a particular socket should result in that instruction being ignored.

        It would be really easy to write a master device which outputs either or both formats.

        Chris
      • fixitsan2
        I wish we could edit posts... I forgot to mention that the new write command requires a minimum of 10mS to take effect, and therefore all write commands ought
        Message 3 of 22 , Feb 1, 2010
        • 0 Attachment
          I wish we could edit posts...

          I forgot to mention that the new write command requires a minimum of 10mS to take effect, and therefore all write commands ought to be followed with a 10mS pause.

          An example, using PIC Basic is as follows....

          Hserout ["$B7W",2,2,0,0,0,1,1,1,0,0,0,1,1,1,0,0,0,1]
          pause 10

          This command will write the bit pattern 0001110001110001 to segments abcdefghijklmnop , and save it as UDC #2 in digit #2.



          Chris
        • fixitsan2
          I would like to know if anybody thinks it would be of use to have a command which allows the user direct access to the segments of a particular tube. The
          Message 4 of 22 , Feb 1, 2010
          • 0 Attachment
            I would like to know if anybody thinks it would be of use to have a command which allows the user direct access to the segments of a particular tube.

            The command could follow a similar format to the UDC write command, except no eeprom space would be used at that time, the bitpattern transmitted in the instruction will be displayed immediately on the relevant segments.

            The only downside that I can see is that there would be a delay in displaying each digit in this way, of about 20mS per digit. On the upside, any pattern at all could be displayed and the combinations of patterns are not limited to the number of free UDC's. If the Host controller has 3kB of ram then it could all be used to display bespoke characters and would not require the intermediate step of packing the UDC's

            Chris
          • John
            ... With a binary fixed length command format, how do you ensure that only good packets are being acted on? With the display of the date, time and such,
            Message 5 of 22 , Feb 2, 2010
            • 0 Attachment
              > > Chris,
              > >
              > > Changing the GUI to match whatever you come up with will be trivial.
              > >
              >
              > John, the new command is in binary format, not ascii. The reason for the change was because it was the best way to maximise the eeprom space (1008/4 bytes per digit)

              With a binary fixed length command format, how do you ensure that only good packets are being acted on? With the display of the date, time and such, serial data errors are washed out because the data is continuously updated but UDC data once stored in EEPROM becomes the permanent representation of that data, errors or not. Using a bit-mapped command that writes the specific pattern to each display instead of an index pointing to a stored pattern would maintain the natural error tolerance of data redundancy and would only require as much memory in the master as the number of unique characters (This is what I do when I switch the SmartNixie modules to display in 7-segment Numitron format instead of 1-of-10 nixie format).

              I suppose that the master could monitor the output from the last slave to compare it to the original data for error detection since the RS232 is simplex: There is no way for a master to know whether a slave is happy with its data.

              jt
            • fixitsan2
              ... There is no way for a master to know whether a slave is happy with its data. ... No there isn t, but the user will be able to tell if they are happy with
              Message 6 of 22 , Feb 3, 2010
              • 0 Attachment
                --- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
                There is no way for a master to know whether a slave is happy with its data.
                >
                > jt
                >


                No there isn't, but the user will be able to tell if they are happy with the results or not.I'm not trying to be ignorant but this isn't a safety critical application.

                The eeprom write command is unlike the other display commands because it is likely that the programmer will write them one at a time and test them immediately afterwards, noticing any details at that time.

                Also, any data errors will show up as general bad performance and the unit not working very well, if at all.

                The eeprom write command still uses the '$B7' header , which is still checked as it arrives, and if those characters are received intact the write command is allowed to proceed. If there are data errors then all the other commands like $B7E, $B7M, etc will be affected too and the user will deal with those problems in their usual manner.

                I could add a simple XOR-ing checksum with very little trouble, if it is generally felt that data reliability is an area of concern, but my own experience leads me to believe that if you can send ordinary $B7M commands and the display works properly then there is nothing wrong with the data transmission.
              Your message has been successfully submitted and would be delivered to recipients shortly.