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

Fwd: [smartsockets] Where and what? B7971

Expand Messages
  • Brett Paulin
    John Taylor at Taylor Edge Electronics stocks the parts needed to build the SmartSockets that are the easiest way to drive B7971 tubes.
    Message 1 of 22 , Jan 17, 2010
    • 0 Attachment
      John Taylor at Taylor Edge Electronics stocks the parts needed to build the SmartSockets that are the easiest way to drive B7971 tubes.

      http://www.tayloredge.com/storefront/1386_B7971SmartSocket/index.html

      Keep in mind however, that the Smartsockets do NOT include an inbuilt "clock program". They are designed to receive a message from a serial port (a computer or standalone Microprocessor) and display that. Without some form of control, they dont do anything by themselves.

      Its very easy to write a simple program to drive the Smartsockets from your PC's serial port, or if you want them Standalone, to use something like an Arduino to drive them.

      Chris/Fixitsan (the designer of the Smartsockets) is working on a standalone smartsocket driver, or one of these days I might get around to knocking up some basic Arduino code to drive them if people want it.. I'm working on other SmartNixie projects at the moment, but if enough people make some noise at me, I might switch to doing some SS driver code as a break from the current project for a while.

      regards

      Brett
    • fixitsan2
      ... Hi Brett, yes it is pretty easy to make something to drive the sockets, and I welcome any projects for inclusion in the files section from anyone willing
      Message 2 of 22 , Jan 18, 2010
      • 0 Attachment
        --- In smartsockets@yahoogroups.com, Brett Paulin <yahoogroups@...> wrote:

        > Chris/Fixitsan (the designer of the Smartsockets) is working on a standalone smartsocket driver, or one of these days I might get around to knocking up some basic Arduino code to drive them if people want it.. I'm working on other SmartNixie projects at the moment, but if enough people make some noise at me, I might switch to doing some SS driver code as a break from the current project for a while.
        >
        > regards
        >
        > Brett
        >

        Hi Brett, yes it is pretty easy to make something to drive the sockets, and I welcome any projects for inclusion in the files section from anyone willing to share their work.

        The driver I am working on has been postponed while I work on the IV-17 smartsocket, and I've made some progress here so I hope to get the smartsocket driver off the ground soon. I've already experimented with creating a scripting language which would allow anyone to write their own display routines in a non complex pseudo language using Windows notepad, or other ascii text editor. Then it could be saved onto an SD card and then plugged into the array of smartsockets. Eventually I would like to make this something which just plugs into a USB port whenever changes need to be made. An onboard RTC is going to be included.

        Chris
      • v_f_d
        ... Eventually I would like to make this something which just plugs into a USB port whenever changes need to be made. An onboard RTC is going to be included.
        Message 3 of 22 , Jan 18, 2010
        • 0 Attachment
          --- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
          >
          Eventually I would like to make this something which just plugs into a USB port whenever changes need to be made. An onboard RTC is going to be included.
          >
          > Chris
          >

          Sweet. Patiently waiting...

          I bought an Arduino (Duemilanove) starter pack to play with, but so far I have been keeping busy planning an analog 3 meter clock using just ICs- no microcontroller. One version uses a CMOS binary clock circuit -> 3 DACs with adjustable precision voltage reference -> op-amp buffer/driver output.

          Regards,
          Vince
        • fixitsan2
          ... I m not very familiar with DACs, and wonder how you convert and transmit data between the CMOS clock and the DAC input ? I guess there must be DACs with a
          Message 4 of 22 , Jan 18, 2010
          • 0 Attachment
            --- In smartsockets@yahoogroups.com, "v_f_d" <v_f_d@...> wrote:

            >
            > I bought an Arduino (Duemilanove) starter pack to play with, but so far I have been keeping busy planning an analog 3 meter clock using just ICs- no microcontroller. One version uses a CMOS binary clock circuit -> 3 DACs with adjustable precision voltage reference -> op-amp buffer/driver output.
            >

            I'm not very familiar with DACs, and wonder how you convert and transmit data between the CMOS clock and the DAC input ? I guess there must be DACs with a full assortment of serial interfaces these days ?

            Something I forgot to add earlier, is a note to PICKIT2 owners who haven't yet discovered the inbuilt 3 channel digital analyser and graphical display, hidden in the tools menu. It cut my dev time this morning down to a few minutes as I tweaked my code and watched the data show in the analyser, much like it would on an oscilloscope, to make sure the right step occurred at the right time. It is a very useful tool.

            Chris
          • v_f_d
            ... True, there are fancy serial input DACs. However, as best I can tell, the first and most plentiful through the years are parallel input. The 8-bit ones
            Message 5 of 22 , Jan 18, 2010
            • 0 Attachment
              --- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
              >
              > ...and wonder how you convert and transmit data between the CMOS clock and the DAC input ? I guess there must be DACs with a full assortment of serial interfaces these days ?
              >
              > Chris
              >

              True, there are "fancy" serial input DACs. However, as best I can tell, the first and most plentiful through the years are parallel input. The 8-bit ones seem to be suited for this use- just feed them the binary output from each clock section (hours/minutes/seconds) and they output a varying voltage in response to the binary "word" [number]. Essentially, they are a ladder resistor network with elements switched in by a high on one (or more) of the inputs.

              See:
              http://www.ikalogic.com/dac08.php

              http://hyperphysics.phy-astr.gsu.edu/hbase/electronic/dac.html#c4
            • v_f_d
              Maybe I should add that by CMOS clock I mean a clock circuit of CMOS chips as here: http://www.flickr.com/photos/barnoid/337592097/
              Message 6 of 22 , Jan 18, 2010
              • 0 Attachment
                Maybe I should add that by "CMOS clock" I mean a clock circuit of CMOS chips as here:

                http://www.flickr.com/photos/barnoid/337592097/
              • fixitsan2
                ... Thanks for clearing that up. It all looks interesting. Chris
                Message 7 of 22 , Jan 18, 2010
                • 0 Attachment
                  --- In smartsockets@yahoogroups.com, "v_f_d" <v_f_d@...> wrote:
                  >
                  >
                  > Maybe I should add that by "CMOS clock" I mean a clock circuit of CMOS chips as here:
                  >
                  > http://www.flickr.com/photos/barnoid/337592097/
                  >


                  Thanks for clearing that up. It all looks interesting.

                  Chris
                • John
                  I ve added a SmartSocket controller GUI to my calculators program to figure out how these modules operate and to possibly build a generic clock controller. To
                  Message 8 of 22 , Jan 25, 2010
                  • 0 Attachment
                    I've added a SmartSocket controller GUI to my calculators program to figure out how these modules operate and to possibly build a generic clock controller. To speed development I've also integrated the protocol pdf into an internal help file that has been cleaned up and had some of the fuzzy bits cleared up: Everything in the help file has been tested via the GUI on actual hardware. I also integrated a font editor that is as yet a bit clunky (Done just enough to test the protocol) but will eventually allow entire character set save and load from file and upload to the socket modules.

                    http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
                    <controllers><[1386] SmartSocket>

                    I built this program to help two groups of experimenters:

                    1. I just want to build a clock without having to program it!
                    In order to assist users such as yourself that don't want to program code I had to build a smart socket system (Using 14 segment LED displays as I don't have the tubes) in hardware so that I could understand the hardware and protocol: From this I will be able to program a clock master controller that you can plug-and-play to get a clock.

                    2. I want to program and build my own but...
                    Essentially, this is for me and others who code their own. It is much easier to figure this stuff out with a high level interface like VB on a PC and then port what you learn to the embedded processor. This GUI will have the added benefit to allow me to split the task into master/slave and test the slave hardware independently and quickly.

                    jt

                    /////////////////////////////////////////
                    --- In smartsockets@yahoogroups.com, Brett Paulin <yahoogroups@...> wrote:
                    >
                    > John Taylor at Taylor Edge Electronics stocks the parts needed to build the SmartSockets that are the easiest way to drive B7971 tubes.
                    >
                    > http://www.tayloredge.com/storefront/1386_B7971SmartSocket/index.html
                    >
                    > Keep in mind however, that the Smartsockets do NOT include an inbuilt "clock program". They are designed to receive a message from a serial port (a computer or standalone Microprocessor) and display that. Without some form of control, they dont do anything by themselves.
                    >
                    > Its very easy to write a simple program to drive the Smartsockets from your PC's serial port, or if you want them Standalone, to use something like an Arduino to drive them.
                    >
                    > Chris/Fixitsan (the designer of the Smartsockets) is working on a standalone smartsocket driver, or one of these days I might get around to knocking up some basic Arduino code to drive them if people want it.. I'm working on other SmartNixie projects at the moment, but if enough people make some noise at me, I might switch to doing some SS driver code as a break from the current project for a while.
                    >
                    > regards
                    >
                    > Brett
                    >
                  • fixitsan2
                    ... John, that was very helpful, and I would like to take this chance to mention a future change in the format of the UDC write command. The next Smartsocket
                    Message 9 of 22 , Jan 27, 2010
                    • 0 Attachment
                      --- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
                      >
                      > I've added a SmartSocket controller GUI to my calculators program to figure out how these modules operate and to possibly build a generic clock controller.


                      John, that was very helpful, and I would like to take this chance to mention a future change in the format of the UDC write command.

                      The next Smartsocket device is the 4 tube IV-17/IV-4 vfd device, each tube has sixteen segments (the upper and lower 'bars' are now made of two, not four segments)

                      I am changing the UDC write command because the new Smartsocket has 1024 bytes of ram available so about 500 UDC's will be available. I don't yet know if it is better to allow the whole group of 4 tubes access 500 seperate UDC's, or if each tube in the group should be assigned their own 120 or so UDC's

                      The problem with the existing UDC command is that it operates across the whole group of sockets, it is impossible to assign one set of UDC's to one socket and another set of UDC's to another socket, unless you disconnect them and program them independently.

                      I have not finalised the format which the new command will take, but it will probably be something like

                      $B7W <8-bit tube_array_number> , <8-bit Address of digit to assign>, <16-bits of bitpattern mask>
                      ...only the tube_array_number field is new with this option

                      Or alternatively it may be that 500 UDC's for all 4 tubes to use is a better option, in which case I will need to look into 16-bit addressing and possibly 16-bit serial commands. This could get messy, and would mean the new sockets would be completely incompatible with existing smartsockets for that reason, so I am keen to avoid this.
                      One way around it is to create a unique 16-bit command just for these sockets which would be ignored by the existing sockets so if anyone feels that 500UDC's would be better then can they please say so !

                      Chris
                    • Quixotic Nixotic
                      Message 10 of 22 , Jan 27, 2010
                      • 0 Attachment
                        On 27 Jan 2010, at 13:12, fixitsan2 wrote:

                        > ..it may be that 500 UDC's for all 4 tubes to use is a better
                        > option, in which case I will need to look into 16-bit addressing
                        > and possibly 16-bit serial commands. This could get messy, and
                        > would mean the new sockets would be completely incompatible with
                        > existing smartsockets for that reason, so I am keen to avoid this.
                        > One way around it is to create a unique 16-bit command just for
                        > these sockets which would be ignored by the existing sockets so if
                        > anyone feels that 500UDC's would be better then can they please say
                        > so !
                        >
                        > Chris
                        >
                      • Quixotic Nixotic
                        ... Isn t it the other way round Chris? Each tube has sixteen segments (the upper and lower bars are now made of four, not two segments) How many people have
                        Message 11 of 22 , Jan 27, 2010
                        • 0 Attachment
                          On 27 Jan 2010, at 13:12, fixitsan2 wrote:
                          > ...The next Smartsocket device is the 4 tube IV-17/IV-4 vfd device,
                          > each tube has sixteen segments (the upper and lower 'bars' are now
                          > made of two, not four segments)
                          >
                          Isn't it the other way round Chris? Each tube has sixteen segments
                          (the upper and lower 'bars' are now made of four, not two segments)
                          How many people have used the UDC facility, I wonder? I played around
                          with them but never made anything concrete and finished that used them.

                          As the IV-17/4s have 16 rather than 14 segments the UDCs will be
                          different anyway. I'd certainly want to use all 16 segments, not be
                          stuck with the top and bottom bars being coupled together.

                          I'd treat this as a new start, don't worry about backward
                          compatibility. How many are seriously going to want to mix the jumbo
                          nixies with VFDs?
                          > I am changing the UDC write command because the new Smartsocket has
                          > 1024 bytes of ram available so about 500 UDC's will be available. I
                          > don't yet know if it is better to allow the whole group of 4 tubes
                          > access 500 seperate UDC's, or if each tube in the group should be
                          > assigned their own 120 or so UDC's
                          >

                          I vote for keeping the same set of UDCs across all tubes. Users will
                          find it hard to keep track otherwise. I'd expect if someone redefined
                          the entire charset they'd want this across all tubes. But I suppose
                          there could be cases where this is not so.

                          Perhaps you could use a grouping system? Group select byte for
                          UDCSET1, UDCSET2 etc then UDC character definition or selection.

                          John S
                        • guus.assmann@wolmail.nl
                          Hello Chris, Why not do both, a part for all tubes and a part for indivudual tubes. It should be just another devision of the memory and the distinction in
                          Message 12 of 22 , Jan 27, 2010
                          • 0 Attachment
                            Hello Chris,

                            Why not do both, a part for all tubes and a part for indivudual tubes.
                            It should be "just" another devision of the memory and the distinction in
                            the command to address the common or individual one.
                            >
                            >--- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
                            >>
                            >> I've added a SmartSocket controller GUI to my calculators program to figure
                            >out how these modules operate and to possibly build a generic clock controller.
                            >
                            >
                            >
                            >John, that was very helpful, and I would like to take this chance to mention
                            >a future change in the format of the UDC write command.
                            >
                            >>One way around it is to create a unique 16-bit command just for these sockets
                            >which would be ignored by the existing sockets so if anyone feels that 500UDC's
                            >would be better then can they please say so !
                            >
                            >Chris
                            >
                            >
                          • fixitsan2
                            ... Thanks for that John. I prefer to have 125 for each tube, rather then 500 available for all 4 tubes anyway. I was thinking in terms of different languages,
                            Message 13 of 22 , Jan 27, 2010
                            • 0 Attachment
                              > I vote for keeping the same set of UDCs across all tubes. Users will
                              > find it hard to keep track otherwise. I'd expect if someone redefined
                              > the entire charset they'd want this across all tubes. But I suppose
                              > there could be cases where this is not so.
                              >
                              > Perhaps you could use a grouping system? Group select byte for
                              > UDCSET1, UDCSET2 etc then UDC character definition or selection.
                              >
                              > John S
                              >


                              Thanks for that John.
                              I prefer to have 125 for each tube, rather then 500 available for all 4 tubes anyway.

                              I was thinking in terms of different languages, having 125 chars gives maybe three languages, ? , 500 chars allows for ten or more ?

                              I will probably review the UDC write command to allow a specific tube position to be the target recipient of the UDC write command, and try to include at least two language sets in the basic firmware (group input may be required here please ! .. possibly French and German, and one other ?). I can see I will have to comb over some extended character set lists, and so on if I go ahead with that idea.

                              Whatever I do I think it is simple enough to make sure that both version 1 and version 2 software ignores each other's commands.

                              After programming the unit today so that it retains font, effect and speed settings in eeprom , things still to do are ....

                              1) UDC write comand (125 Chars per tube)
                              2) Three or four more animated transition effects to add
                              3) Finalise the power supply

                              Presently, the supply demand at 5V is 295mA, approx 1.5 Watts, for 4 tubes and using a 56 ohm resistor in series with each tube's heater to give about 2.6V (still a bit too high)

                              I'm using only about 20k of the possible 64k of memory, and also noted that it might be possible to drive 6 tubes, multiplexed, without any flicker, although they will be slightly dimmer due to the duty cycle. An alternative is to run a 3x2 mux scheme, but that will require another Supertex driver so I might leave that for now.

                              All parts available in SM packages and if I can get my board design skills up to speed the whole display could be very small and compact which could allow them to be installed in very tight spaces.

                              Thanks for the comments
                              Chris
                            • fixitsan2
                              ... Thanks Guus. The more I think about this the more I think it is likely that the sockets will always be connected up to a controller with some sort of
                              Message 14 of 22 , Jan 27, 2010
                              • 0 Attachment
                                --- In smartsockets@yahoogroups.com, guus.assmann@... wrote:
                                >
                                > Hello Chris,
                                >
                                > Why not do both, a part for all tubes and a part for indivudual tubes.
                                > It should be "just" another devision of the memory and the distinction in
                                > the command to address the common or individual one.


                                Thanks Guus. The more I think about this the more I think it is likely that the sockets will always be connected up to a controller with some sort of intelligent control features which could easily reprogram a charset whenever required.

                                Keeping some sort of compatibility among the different types of sockets means that a single unified controller can be used. John's clock for B7971 tubes for example should be allowed to work equally well with a new socket version which comes along, to cut down on the number of controller versions required, but I accept there might come a point when the hardware dictates that different versions will be required.


                                Chris
                              • John
                                Chris, Changing the GUI to match whatever you come up with will be trivial. http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
                                Message 15 of 22 , Jan 28, 2010
                                • 0 Attachment
                                  Chris,

                                  Changing the GUI to match whatever you come up with will be trivial.

                                  http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
                                  <controllers><[1386] SmartSocket>
                                  http://www.tayloredge.com/reference/Circuits/1386SmartSocket/editor.GIF
                                  (To edit the font, click on the segments in the picture or edit the pattern of 1/0s; these two entry methods track each other.)

                                  The next enhancement of the tool will be to use the character editor to create, save, load and upload entire UCD character sets to sockets. Doing this from a PC is fast and easy and since the UDC is non-volatile you could presumably abstract the UCD functionality out of the master embedded controller: "A" would remain the same in the master. Program every socket string in the string or each individually so they would display their interpretation of the same character.

                                  When you build the 16 segment displays, this will be even more useful as the alphabet can now be enhanced: The 14 segment display was the bare minimum for A-Z and 0-9.

                                  jt

                                  --- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
                                  >
                                  >
                                  >
                                  > --- In smartsockets@yahoogroups.com, guus.assmann@ wrote:
                                  > >
                                  > > Hello Chris,
                                  > >
                                  > > Why not do both, a part for all tubes and a part for indivudual tubes.
                                  > > It should be "just" another devision of the memory and the distinction in
                                  > > the command to address the common or individual one.
                                  >
                                  >
                                  > Thanks Guus. The more I think about this the more I think it is likely that the sockets will always be connected up to a controller with some sort of intelligent control features which could easily reprogram a charset whenever required.
                                  >
                                  > Keeping some sort of compatibility among the different types of sockets means that a single unified controller can be used. John's clock for B7971 tubes for example should be allowed to work equally well with a new socket version which comes along, to cut down on the number of controller versions required, but I accept there might come a point when the hardware dictates that different versions will be required.
                                  >
                                  >
                                  > Chris
                                  >
                                • John
                                  The full font management system is in place along with a simple animation utility. jt http://www.tayloredge.com/reference/Circuits/1386SmartSocket/editor.GIF
                                  Message 16 of 22 , Jan 30, 2010
                                  • 0 Attachment
                                    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>
                                  • 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 17 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 18 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 19 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 20 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 21 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 22 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.