verifying an array?

[aymanoo]

Is the code correct in line 2?

[ezflyr]

Hi,

Give it a try, and I think you'll find it doesn't work. It may not even compile....

You'll need something like this:

[FvM]

You can use strcmp(), but than the array must include a terminating null and have the length increased by one character.

[aymanoo]

[RF_Developer]

There are other approaches to solve this problem, and problems like it.

This sort of thing is OK if its all the PIC is doing, i.e. in an exercise or a very simple widget. I say that as comparing an entered password against a single constant password hardwired into the code is very simple indeed, and almost useless in practical systems... except just possibly as a developer's backdoor. In most real systems you generally can't afford - space and money - to allocate one PIC to one function, so its going to have to do more than one thing, such as operate a lock, scan a keypad, multiplex a display AND communicate to a remote access control system all at the same time. In these sorts of systems a state machine approach is probably more useful.

I use this approach for all sorts of things including system state control and sequencing, numeric decoding and verification, button press detection/debouncing (including single/double click detection etc), comms protocol implementation and packet reading/decoding/verification.

In this instance consider your code running on a PIC that has a main loop running round and round continuously doing stuff is sequence - the standard main loop thing. You can't lock up other tasks while one bit delays, or waits for a button press, or a character to arrive on a serial port, or a message from CAN or whatever. All these things must run all the time without interfering with each other. State machines, one for each function that needs sequencing, all get called from the main loop. Other stuff runs too, like ADC measurements or checking input pins. The password input machine looks for a keypress, or serial input or whatever its input is, if it gets one it compares it to the relevant entry in the array, if good then it changes its state to look for the next keypress/character/whatever. If bad, it goes back to the idle state. Only once the machine has worked its way through all the entires one by one, can it enter the "release authorised" state and enable the lock. It starts a timer, either hardware or firmware derived from an interrupt routine, which will raise a flag in due course. When the flag is seen the lock is closed and the state machine goes back to idle to await the next time....

State machines are often introduced with the classic traffic light assignment, but there are many, many uses for them. They are a powerful tool in embedded systems.

RF Developer