Hi gang,
I think I'm finally in over my head.
I've got a project lined up that will ultimately display 29 7-segment digits. The hardware for controlling the digits is not a problem.
The problem is getting a screen on a PC like the attached which will be the source of the digits to be displayed.
I have no idea how to create an interactive screen and then get it sent out to my card.
The software to run things has to be run on an XP equipped laptop, output can be USB, ethernet, or RF via usb/XBee adapter.
Where do I start on this?
Thanks
Crossroads
(I think I'd have no problem making a '1284P version with a ton of buttons instead and a smaller display, also 7-segments, and pass the displayed data on to the larger digit display located some distance away).
Thanks for the suggestion.
Will that combination allow a user to have a running countdown timer be displayed on the screen, and be sent out over ethernet or out to a USB port (to FTDI chip driving an Xbee for wireless)?
I've used excel a lot, never with Active X tho, whole new area for me.
There is a Developer tab which is not showing by default. Go to Office button up left and choose “show Developer tab in the ribbon” under Options. In this tab, under Insert, there are a number of controls that can be used, like buttons, text boxes and so on. Each one of these create and trigger a subroutine in the VBA code which can be accessed by alt-F11. Cells in the display sheet can be activated and updated through VBA. Cell appearance can be adjusted through formatting and there is also conditional formatting with a number of interesting options, like degrading between cell color depending on cell’s value.
To have a countdown clock into the display sheet, could insert ActiveX buttons next to the clock’s cell, in order to start, stop, reset, lap or whatever and also use that time in the program. Once finished programming, could lock cells and hide tabs and command lines so as to get a clear display active buttons and controls only.
Identify who will use the software. If the person is expected to be a bonehead then Excel is a bad choice (they will muck up the workbook on a regular basis with you getting dragged in to clean up the mess). If the person is expected to be technically savvy then Excel may be a viable choice.
Identify the audience size. For a small audience, technical support is typically no big deal. Some rough edges are no problem. For a large audience, technical support will quickly destroy your sanity. Even very minor rough edges will balloon into endless requests for help.
Identify where the software will run. Are you guaranteed the software will only be run on a Windows PC?
Will the software be "on-line" (does the user expect to make changes during a game) or is the software intended only for configuration?
What is the cost if the application fails? Are cash prizes awarded? Trophies? Will a soccer mom go ninja on your ass?
In addition to displaying data, there appears to be some functional requirements. For example: "shift's up after upper is empty" and "gametime count down". Make absolutely certain you understand those (my partner and I typically walk through every possible combination to ensure the requirements do not have any holes). I've seen it written many times: cost to change during requirement gathering is $1; cost to change during development is $10; cost to change during debugging is $100; cost to change after delivery is $1000. Holes in the requirements typically end up in the last two categories (very expensive).
Make absolutely certain you understand those (my partner and I typically walk through every possible combination to ensure the requirements do not have any holes).
Try explaining the requirements to someone who does not understand programming. If they understand, chances are the requirements are pretty darned good. If not, or if you find yourself unable to explain both the what and the why for the requirements, chances are pretty good that translating them into code won't be any easier.
That's what I was figuring, too many things to go wrong.
I've changed the approach and will instead have a control box with a couple buttons and maybe a keypad, and 12 field of 7-segment LEDs all controlled by as '1284P and some MAX7219s. Be far quicker for me to write the emedded code and control what goes out to a remote box.
