Coding needed.

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
Why don't you like PIC.?

I started with PIC's therefore I have PICS. What do you like , Chips?

So any part numbers for me ? so I can start with the layout.

I need to talk to my cousin about the terminal box design. After that I can figure out how to put the PCB in.

What ever cuts the cost down we will go with it, SMD or not.

I believe the terminal will need programing right ?
Aren't there any ready made IC's for these kinda purpose ?
 

MrChips

Joined Oct 2, 2009
30,707
Serial Communications Protocol

1. The serial transmission data format will be 9600 baud, 7 bits, even parity, one start-bit, one stop-bit.

2. All characters will consist of printable characters, case sensitive, and may include SPACE and RETURN.

3. Messages will have the following format:

<start> <address> <command> <data> <checksum> <end>

where the individual fields are defined as follows:

<start> single char $ ASCII 36, 0x24
<address> single char 0-9, A-Z, a-z
<command> two chars uppercase only A to Z
<data> optional as defined
<checksum> 2-char hex 0-9, A-F ?? is used for testing
<end> single char CR ASCII 13, 0x0D

4. Responses will have the following format:

<start> <address> <response> <data> <checksum> <end>

where the individual fields are defined as follows:

<start> single char * ASCII 42, 0x2A
<address> single char 0-9, A-Z, a-z
<response> two chars uppercase only A to Z
<data> optional as defined
<checksum> 2-char hex 0-9, A-F ?? is used for testing
<end> single char CR ASCII 13, 0x0D

Devices may or may not respond to commands depending on specific application.
Error reponses have not yet been defined.

5. The checksum, when applied, is computed as the MOD-256 sum of all characters starting with and including the <start> character up to and including the <data> characters (if present). The checksum uses the 7-bit ASCII value of the character and does not include the <checksum> or the <end> characters. The checksum is transmitted as two hexadecimal characters, 0-9 and A-F, using uppercase letters only. The most significant hexadecimal character is transmitted first.
(The checksum characters may be replaced by ?? during testing.)

6. Address "0" is reserved for broadcast purposes only. Any unit receiving a valid command with the address "0" must execute the command. At the present time, the unit must NOT reply with a response.
(The address "0" is not intended to be used as a default address and should not be used as such.)

7. A unit will not execute a command on detection of any one or more of the following conditions:
(a) a parity, framing, or overrun error
(b) a checksum error
(c) an address that does not match the unit's predefined address
(d) an invalid command
(e) a syntax error

Furthermore, the unit will not send a reply on detection of an error.

8. Turn-around delay is the time delay between the reception of the command and the transmission of the reply. The turn-around delay is expected to be approximately one character transmission time (approx. 1ms at 9600 baud). The total delay experienced will include the time to process the command and may or may not include the time to completely execute the command. In some cases, the reply may be sent before the command has been executed.
Special Case: The turn-around delay will be modified when the broadcast command $0ID is received.



Some examples of basic commands:



General Commands

Command Purpose
ID request unit device code
SN request unit device Serial Number
VN request unit Version Number
MT request unit Module Type
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
Egad !! :eek:
I will get back after a few days sleep.

Good night...!

Hope that I will have something to make by that time.
 

Markd77

Joined Sep 7, 2009
2,806
I could probably code the basics of the terminal with that protocol in a few hours (might be spread over a couple of days depending on what else I'm doing).
My PIC of choice would be the 16F628, it's fairly cheap, I've got a couple of them, and it has everything required.
I can't guarantee that I would code the master terminal, especially if it needs some of the more advanced features suggested recently, it's a much bigger job.
 

MrChips

Joined Oct 2, 2009
30,707
Don't worry Mark. This is a relatively straight forward project. My task is to demonstrate an example of clean design using the top-down approach. This means getting the big picture up front while having the knowledge, experience and confidence to know that I can tackle the details. As you can gather, R!F@@ is a bottom-up guy. He wants to tackle the little things first, one step at a time, to build confidence. I am struggling with getting him to commit and disclose the purpose and objectives of the project. In the meantime, I can provide the best solution from a systems approach given the information that he has given us.

Proper systems engineering requires having all the specifications written down on paper. This way all parties involved have clear guidelines to follow. The Communications Protocol is likely to scare away any novice while in reality it is fairly simple and straight forward once one has gotten familiar with similar specifications.

Tomorrow I will attempt to present a hardware schematic using a generic MCU. I am not going to pull hairs with which specific MCU to choose.

After that, we have to nail down some specifics about the modes of communication between terminal and controller, i.e. peer-to-peer or master-slave relationship. A hardware drawing at this point may placate R!f@@ but then I really need to understand the purpose of the system.
 
Last edited:

thatoneguy

Joined Feb 19, 2009
6,359
Thank you, MrChips for the excellent project layout! I agree with the 16F627/628 for the terminal, they are essentially the same chip, with the 628 having 2k of program flash while the 627 only has 1k, which should be enough.

Both are identical in all other respects, including having a UART, 3 timers, 128 byte EEPROM for ID & serial# storage, and plenty of I/O for the task.

They are also low cost. $1.61 for the 16F627A and $1.73 for the 16F628A from microchipdirect.

Finding the RS-485 IC is the only other major hardware decision for the terminals, if the 16F627A is acceptable. Depending on if RIFAA wants to splurge, he can spend the extra 12 cents per terminal for the 16F628A in case more terminal side features are needed in code.
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
Hey chips did my PM go thru, I think my browser made a booboo.
I replied to u like just now.

U think the terminal can be changed to 10 rating if say needed.
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
I still cannot believe u did that.
I dunno what to ask in order to to know what needs to be known..

I guess we can start from there..

But just so you know that I made a commitment to AAC.
further more I am meeting great guys in AAC not to mention you, MrChips.
So I want to be here more but Admin title is so sexy...

{ed}

Chips....How about we go with a low cost and trouble free solution. I believe we would have to make a new one with more advanced and more features later if it gets through
Let's keep this to low budget kinda thing so that I could too learn from this.
Basic Idea about the cat 5 is that it is wired so it will work without hassle like low batteries and terminal getting stolen and dropping....U would be surprised how things are here.
 
Last edited:

BillO

Joined Nov 24, 2008
999
Just looked through this whole thing.

I honestly do not want to upset or annoy any one, but here goes...

First, this can be done very simply. What I mean by this is, no more than about 500 lines of code. 450 for the controller and about 50 on the terminal.

Mr. Chips is right. You need to work this out as a complete system before you get too far into implementing the design, otherwise you'll be trying to build the system to suit the weakest point. Not a great approach

Thirdly, it needs to be kept simple. It has to be repaired and maintained locally. Rifaa needs to be able to support this himself, unless you all wish give out your cell phone numbers. So, I'd forgo the RS-485, addressable protocol and cyclic redundancy checks.


Here is my shot at a (brief) design out-line:

Noise is not going to be an issue. We are, or can be (should be), dealing with low impedance, very low speed (basically DC), communication between the terminal and the controller hub. As elegant as a multi-drop network protocol would be, it's just not required. I'd suggest a simple 5-wire inter-connect and a mux at the controller end. Cheap and easy to program. The five wires would be power, ground, data_0, data_1, acknowledge.

The terminal will handle all the operational control at its end and make the data available to the hub. The terminal MCU scans the buttons for a press event. When one occurs it asserts that button's LED, stops the scan, beeps the buzzer, then put's the address of the button on the 2 bit data bus and waits for an acknowledge signal from the hub. Once it gets the acknowledge, it waits for 10 seconds, turns off the LED, zeros the data bus and begins it's button scan again. The terminal is supplied its power from the hub through the cable. Cat5/6 cable is cheap and readily available. Unshielded is fine and RJ45 connectors are cheap and ideal. The terminal does not need to have a unique ID. It can be identified by which mux port it is plugged into.

The hub will contain the main MCU, sufficient memory to record a months worth of events, the access/control keypad, the display, the system power supply, and the mux. All housed in a secured cabinet. Other components still need to be decided on. In particular, does it need removable storage and does it need a real time clock? For my part, these are easy to add and will immensely improve the end product and some of the discussion indicates they may indeed be required. Also we need to know the hub capacity, as in how many terminals do we want the final design to be able to handle per hub.

The MCU monitors the mux and the keypad in a round-robin fashion. If it finds data on one of the data busses, it captures the data stores it with a time stamp and mux location, then sends back an acknowledge to the terminal, waits a few milliseconds, and continues its round-robin scan. Each scan should complete in a small fraction of a second so there will be no contention problems or lost events. One stop on the round-robin scan could be to scan the keypad for an event, or equally acceptable, the keypad can utilize an interrupt. Once a keypad event is detected, the mux scanning is stopped and the access code routine is entered.
If access is granted, the system provides a short menu of options (eg. 1> Restart, 2> Download and clear, 3> Change Passcode). Option 2 would wait for the insertion of the removable storage, then on command, copy the recorded data to the removable storage, verify the data copied, reset the internal storage and return to the menu for the user to enter the restart command or change passcode. Once the restart command is given, normal operation resumes. If during the verification step of the download process an error occurs, the system reports the error, records a download error with a time stamp, does not clear the internal memory and returns to the command menu.

If access is denied, an access violation event is recorded with a time stamp, a message is displayed then normal operation resumes.

Communication from the MCU to the user would done through a small LCD display. I would suggest 4 lines by at least 20 characters.

Okay, so there is a simplistic first iteration. Also, I'd like to suggest an Arduino for the hub MCU. It has everything needed and most of the code required already exists in libraries and would need little modification. plus, it comes in two forms. One that is ideal for prototyping and one that is ideal for the final application. The only boards that need to be designed are the mux and the terminal. Everything else could be off the shelf. A small 14 pin PIC would be fine for the terminal. Even a PICAXE for ease of programming.
 

MrChips

Joined Oct 2, 2009
30,707
Thanks Bill. You have given this much thought and have laid out a thorough and sound plan. Looks like this is the way things are heading. One problem is with the mux part. The design calls for 32 max terminals. I haven't had time to work on a schematic as yet.
 

thatoneguy

Joined Feb 19, 2009
6,359
The terminal will handle all the operational control at its end and make the data available to the hub. The terminal MCU scans the buttons for a press event. When one occurs it asserts that button's LED, stops the scan, beeps the buzzer, then put's the address of the button on the 2 bit data bus and waits for an acknowledge signal from the hub. Once it gets the acknowledge, it waits for 10 seconds, turns off the LED, zeros the data bus and begins it's button scan again. The terminal is supplied its power from the hub through the cable. Cat5/6 cable is cheap and readily available. Unshielded is fine and RJ45 connectors are cheap and ideal. The terminal does not need to have a unique ID. It can be identified by which mux port it is plugged into.

Okay, so there is a simplistic first iteration. Also, I'd like to suggest an Arduino for the hub MCU. It has everything needed and most of the code required already exists in libraries and would need little modification. plus, it comes in two forms. One that is ideal for prototyping and one that is ideal for the final application. The only boards that need to be designed are the mux and the terminal. Everything else could be off the shelf. A small 14 pin PIC would be fine for the terminal. Even a PICAXE for ease of programming.
The problem with this is chance of race condtion when polling each hub, and more hardware would need to be added, and code changed, to handle the expansion.

I agree with the CAT 5 cabling, but in conduit. If you've ever helped/worked with stuff in factory type environments, employees can turn into clever vandals if they are about to quit, or when they get mad that a count was missed. They generally hit buttons instead of pushing, etc.

The problem with the Arduino is that it would cost more than a PIC solution, and doesn't have provisions for code protection, etc. I'm under the assumption that RIFAA doesn't want the code to be known, but the hardware is open.

With the 485 network, one master RTC could update internal clocks on all terminals every hour to ensure their timestamps are correct. Time stamping on the terminal end eliminates any race condition that would occur with a polled hub.

I was under the assumption that 2 pairs of the Cat5 for RS-485 would be used to power the terminals already, anyway.

Your input is excellent, however, and correct me if I missed any assumptions about the function of the MUX'd hub and Arduino.
 

BillO

Joined Nov 24, 2008
999
The problem with this is chance of race condtion when polling each hub, and more hardware would need to be added, and code changed, to handle the expansion...
Since the data is asserted by the terminal and remains asserted until it is acknowledged, there should be no race condition. The hub services each terminal in order.

With this method there is only one clock in the hub MCU so that there cannot be a synch problem. The terminals need not have any time function at all.

Certainly the PIC would be less expensive. I only suggested the Arduino/AVR for the wealth of available code.

MrChips said:
One problem is with the mux part. The design calls for 32 max terminals.
It not hard to design and there is only one per system. One 74LS138 and 8 74LS245 would make that happen. The idea being a little more hardware would save a ton of complexity in the software and allow the terminals to be butt simple.

Anyway, it was just a suggestion.
 

thatoneguy

Joined Feb 19, 2009
6,359
Since the data is asserted by the terminal and remains asserted until it is acknowledged, there should be no race condition. The hub services each terminal in order.

With this method there is only one clock in the hub MCU so that there cannot be a synch problem. The terminals need not have any time function at all.

Certainly the PIC would be less expensive. I only suggested the Arduino/AVR for the wealth of available code.



It not hard to design and there is only one per system. One 74LS138 and 8 74LS245 would make that happen. The idea being a little more hardware would save a ton of complexity in the software and allow the terminals to be butt simple.

Anyway, it was just a suggestion.
If the polling time was in the hundreds of milliseconds (say, 250mS for a full scan of 32 ports), the hardware for 32 ports could be added but without the actual jacks, only pads for the expansion jacks. The code could be written to poll all 32, even if half are missing.

I'm unsure if the terminals need to be relocatable or not, which is a benefit of having device addresses at the device, but other than that, I can see how your solution is viable.

There are plenty of libraries for PICs in C compilers such as LCD, EEPROM, UART, PWM, etc., so programming will still be relatively straightforward for the controller side using the fixed port method (vs. RS-485 addressed method).

It's up to RIFAA to decide which he would like to go forward with.

--ETA: For IP retention, this wouldn't be the strongest method, especially since the 485 network would allow somewhat basic encryption of the data passed back and forth to severely compound the amount of work to reverse engineer the system. With the simple 2 line and multi port controller, the timing could be found quickly with a logic analyzer, that's just something to keep in a paranoid mind.
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
Don't say it is upto me guys. If it were up to me, you will see a freakin thing in action and giving me loads of headache.

Your thought and comments is well worth to make it a better device in action.
 

BillO

Joined Nov 24, 2008
999
If the polling time was in the hundreds of milliseconds (say, 250mS for a full scan of 32 ports), the hardware for 32 ports could be added but without the actual jacks, only pads for the expansion jacks. The code could be written to poll all 32, even if half are missing.
Correct. Poll all mux ports.

I'm unsure if the terminals need to be relocatable or not, which is a benefit of having device addresses at the device, but other than that, I can see how your solution is viable.
I would think location would be more important than the actual terminal, but that is assumption on my part. If these are more or less hardwired to location (conduit) then it would be more important to have the wire in a fixed mux port than worry about where a particular terminal is. This would also be handy if one needed replacing.

There are plenty of libraries for PICs in C compilers such as LCD, EEPROM, UART, PWM, etc., so programming will still be relatively straightforward for the controller side using the fixed port method (vs. RS-485 addressed method).
I'm sure there are, just I'm not familiar with them. I only made the suggestion of Arduino because I am more familiar with it and have a better grasp of what is available. I know PIC are just s capable as AVR, and I am learning about them too. PIC has just been a rougher road for me than AVR. Mostly because the Ardunio was available to help get into the AVR side.
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
Further Discussion on this project is suspended in this forum due to copy right violation by me ...:D

Don't ask why just go here. Cause me not a MOD.
 
Top