No announcement yet.

Is or can the SGC slave code be made available to customers so it can be tweeked for their needs

  • Filter
  • Time
  • Show
Clear All
new posts

  • Is or can the SGC slave code be made available to customers so it can be tweeked for their needs

    I have been working with your uLCD-32PT product, primarily using the slave-type SGC code loaded. Most of my work has been quite easy and most of the documentation is accurate though as I have seen in other posts, questions do arise. I will address these in another thread. The FREE utilities you provide work well and have allowed me to (very quickly) create a touch-screen keypad that will be used for an access control device. I have also read and played a bit with the GFX, standalone-type code loaded and have loaded one of the samples to see how that works and as usual, it also worked well.

    So this post deals with some issues I have found to be a bit frustrating in attempting to get my implementation to work well and accordingly with my 'host' MCU with which your unit will be embedded. I have seen a number of posts where some folks have complained about some (if not most) of the items I will list below.

    My desire is to be able to get a full copy of the SGC source so I can make a few mods specific to the use with our product. It would be very useful to have this code as it is complete and not just parts as I have seen in your samples (that are quite useful I should say...oh and per one thread, any micro/firmware engineer that complains about a 'new language' needs more experience with the various embedded products out there as many use 'new languages' for their flash requires tight tools, including languages...but I digress...).

    The advantage of providing the code (like as mentioned in threads an open source version say...) is customers can see your programming model and then can actually make changes as they desire. The items I list below may not be implemented because of space issues on the chip you use, so any customer that needs more space can, using this source, remove items they would not use thus providing more space to add what they need.

    Then customers could also (in an open source model say) provide their ideas in code that 4D Systems might incorporate into their base. Of course 4D Systems would NOT support this SGC code if it has been modified...except say for a fee (I was an auto mechanic in my youth and we LOVED when folks worked on their own car...then brought it in...we always made more $$ on that ).

    So the list. Here are the items I would like to see.add to a copy of the SGC code. Most of the comments deal with the serial communications portion of the SGC implementation. Per another thread, I do not just like complain, but do provide some ideas...

    1) So for some reason, over the years I have found that asynchronous models are somehow left out of folks implementation. It took me 2 years working at Motorola to get them to model a 'pure' asynchronous system in a device I was working with. Once they did, it fixed a number of issues that had 'bugged' their system for years. I would change the SGC code to provide pure asynch for at least your touch screen processing. Pure asynch processing in my view is where the device will provide say the x/y coordinates of a touch at ALL times and this background loop would NOT pre-empt any (or most) other commands.

    I would basically modify the Get Touch processing so that when in one of the wait for touch modes (00 - 03), it would still take other commands and respond. Then I would change it so that I could take the device out of this asynch mode for the touch screen with another command (or a different version of the get touch command). I believe that any time a slave device can be placed into a state where it does NOT in the SGC where it waits for a touch. It just makes the interface implementation to your device a bit more difficult and more implementation-heavy.

    2) IF say item #1 is too difficult based upon your SGC model (providing a full/pure asynch model that is), I would just change or add a single command that will ALWAYS make it through the com interface. This command would STOP any processing and reset the uLCD back into a ready-to-process mode. I would either enhance the auto-baud command as it is not utilized directly in the SGC or add another that I would call say an 'escape' command. Single byte that is always looked for. This would solve a number of my current issues I have when I place the uLCD into the wait for touch mode.

    My desire on this is to NOT have to reset the device too much. I will have an open-collector style reset connection to my MCU in any case, but really do not want to use this unless I have to. It would just be a good addition to have something that just rests the SGC state so I can just run scripts/commands without a reset.

    3) Next, I would enhance a few commands to actually return an ACK at all times. Basically, except for the sleep commands that say return an ACK when the uLCD actually wakes (which is a nice feature when it actually returns the ACK), I would set the command processor in the SGC code to check back command structure, then ACK, then actually do what is desired. As an example I saw a moderator response where it was asked why the execute script command(s) do not return an ACK and they stated that the script could run forever, etc and so an ACK was not appropriate. I would actually change the code to return an ACK when the command structure of the execute command is verified, but prior to the script execution. In the embedded world of interfaces, ACKs (and NACKs of course) are very important with the common use of state machines in the various (especially com) interfaces.

    4) Next, I would specifically change the sleep command (0x5A) to allow for a sleep forever but also wake up under the same set of items that are used for a sleep time up to 0xFF (255) seconds instead of requiring GPIO pin actions. Now allowing for an external wake-up here is a good idea, so maybe one could say sleep for 1 - 254 seconds then use 0 for this special GPIO P0/P1 wake up and use 255 for the sleep forever, but wake up on serial/touch/etc. per the timed sleep version. Once again, also providing the items listed in #1 and #2 above would be very useful here as well.

    5) Lastly, I would modify the Get Touch command using mode 04. It seems that on at least the uLCD-32 that the max coordinates never use the top nibble of the 2-byte coordinate response. I would change this repose to always report the full x/y coordinate and report the 0 - 3 result in the top nibble of the y-coordinate. This can easily be masked off to get the true y-coordinate. It would just aloow for less commands to get coordinates when using the 04-version on the Get Touch command.

    So I can think of a few others, but it would just be great to have the source to work on these items myself. Since I have already decided to use the SD card in raw mode, I would immediately remove all of the FAT file type processing from the SGC code and I believe have plenty of room for these mods.

    So this was long, but hopefully informative with ideas and potential solutions. Ultimately, SGC source access would be the BEST answer to these items.

    Thanks much and take care.

    - jon

  • #2

    0) The source for SGC will not be made available. The source of an SGC written in 4DGL is provided with workshop and updates/alterations to it can be found on this forum.

    1) If you modify your code so that you wait for the ACK (if applicable) before sending the next command, rather than at the end of the previous command, then you essentially have an async model. The 'Wait' touch commands are not intended for 'proper' touch usage, you need to use the 'get' commands for 'real' work. Considering that around 100 touch 'status' updates can happen per second there is no way any resonable use of touch could be done in the background. If you need that type of touch activity detection you should be using GFX.

    2) Since the interface allows all 256 possible hex codes in any combination there is no scope to have an 'escape' command without completely rewriting the SGC protocol.

    Regardless, I have seen SGC running 24x7 for months without issue, if you haven't made a mistake with your command (somewhere) there is no need for an 'escape' command.

    3) The command script is the only command that doesn't return something (well, other than sleep, but really). If you really want to see an ACK, just make the sending of and ACK the first command in your script.

    4) Sleep forever uses less power than sleep seconds, which is why things happen the way they do in that command. But, yeah, the ability to sleep forever with wake on Serial or touch would be a good idea.

    5) Why try to confuse things by changing two commands into one, especially when when 1/2 of the possible responses to the status command have no valid X/Y coordinates?

    Thanks, for your input, sorry if we appear somewhat negetive to some of your suggestions, there are many tens of thousands of SGC displays out there, in use for many different purposes, we need to consider all of those uses when making changes.