Go Down

Topic: Software system development procedure question (Read 1 time) previous topic - next topic

oldradio

I am engineering a still controller that has a number of different I/O devices to operate. The procedure I intend to use is to build each I or O interface circuit and then write a sketch to operate it and to test it out. When done, I will have a bunch of sketches that I know work well with my hardware. My plan is to then put these I/O sketches in the form of functions that can be used in my over all system control sketch. Then I copy each separate I/O function sketch and paste it into the system control sketch.

Does this make sense as a strategy, or is there a better way?

Thanks,

Barry

marco_c

This can make sense and is a good way to build up a system. However, you have limited resources (memory mostly) in the AVR processors, so you may need to tweak the overall process to make sure you are as efficient as possible at the end (ie, reduce duplication). This will depend on the application, but as we have no more details ...
Arduino libraries http://arduinocode.codeplex.com
Parola for Arduino http://parola.codeplex.com

Nick_Pyner

What you are describing is essentially standard procedure. Further to Marco's you need to look at what you want to do. This sort of work can be categorised.

variety of devices

number of devices

local display

data recording

communication

I point this out as I took the usual path of getting a Uno but landed up needing a Mega. If you need to consider all of the above, the Uno is likely to have insufficient memory and you might as well get a Mega to start with. 

oldradio

Since I have no experience with the Arduino, I am worried about memory space. We are using the Mega. I don't think I will have trouble with the basic functions of running the still, but I am almost paranoid about using this device in an industrial environment so I do have a lot of error detection and diagnostic hardware and software in mind.
My boss also wants fancy data logging and the ability to do things from an attached computer, and while this is certainly possible, it will eat up Arduino memory if I'm not clever about it. Any suggestions would be appreciated, and we are prepared to add shields or even another (serial connected?) Arduino if we have to. I have the "Maker Plot" software in mind for running on the PC to do all the data logging and reporting and control he wants, but I have no idea at this point what Arduino resources this will eat up.

Some how I managed to get this post in the wrong forum. Can someone tell me how to move it to the software forum?

radman

Quote
I don't think I will have trouble with the basic functions of running the still, but I am almost paranoid about using this device in an industrial environment so I do have a lot of error detection and diagnostic hardware and software in mind. My boss also wants fancy data logging and the ability to do things from an attached computer


Frequently in industrial environments people use Programmable Logic Controllers (Allen Bradley, Siemens etc.), along with a SCADA system on a PC/Server for mimics, reports etc. That approach will be a lot more expensive than an arduino but you might want to consider if it is appropriate for your application (e.g. value of process, future expansion etc.).


Nick_Pyner


I have the "Maker Plot" software in mind for running on the PC to do all the data logging and reporting and control he wants, but I have no idea at this point what Arduino resources this will eat up.


I imagine not so many. If the Arduino is standing alone, it needs to be considered in the way I described, but a Mega can do a hell of a lot of work. If it is connected to a PC in the way you describe, it is simply an interface device passing the data along to the PC, where the real work gets done.

Quote

Some how I managed to get this post in the wrong forum. Can someone tell me how to move it to the software forum?


It seems in the right place. If it isn't, the moderator will move it.

wildbill

Given that you're using a Mega, you've got loads of flash and RAM to play with. The reporting can simply be reporting the state of your I/O devices through serial to the PC - put any smarts you require there. Make use  of program to store any text you're going to send to the PC.

How much I/O are you going to need?

UKHeliBob

One thing to look out for is that your test programs, and hence your functions, do not use the delay() function, as this will prevent anything else running until the delay() is finished.  This may work for the test program but would be unacceptable in a program that reads many sensors and processes the data.
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

RoyK

#8
Aug 27, 2013, 05:41 pm Last Edit: Aug 27, 2013, 05:50 pm by RoyK Reason: 1
One thing I've learned over the years is that projects like this tend to be vulnerable to "feature creep" as they are developed. More and more requirements are heaped on to what starts out as the solution to a simple problem. My advice is to figure on this happening right from the outset and make sure you have much more capability in the hardware than you think you will need. Not really much of a restriction given the low prices of some pretty high end hardware today.

This is exactly the kind of system something like a PC running LabVIEW would work great for.



tylernt


One thing I've learned over the years is that projects like this tend to be vulnerable to "feature creep" as they are developed.
Agreed. Freeze the (minimal) feature set for version 1.0 as early as you can. Any additional features they want, say "sure thing boss, that'll go right into version 2.0".

RoyK

Quote
"sure thing boss, that'll go right into version 2.0"


To which my boss would have replied. "Fine. Skip straight to version 2 and take an extra day or two."  :)

PaulS

Quote
To which my boss would have replied. "Fine. Skip straight to version 2 and take an extra day or two."

Lucky you. I never get extra time.

westfw

Quote
... write a sketch to operate it and to test it out. When done, I will have a bunch of sketches that I know work well with my hardware. My plan is to then put these I/O sketches in the form of functions ...

I would try to design and write the IO code as functions to start with, designing a "sensible API" from the beginning.
That is, instead of writing code like:
Code: [Select]
void setup() {
   pinMode(12, OUTPUT); // clock line to thermometer
   // Blah blah
}
void loop() {
   digitalWrite(12, 1); // enable thermometer chip
   // blah, twiddle bits, etc.
   Serial.print(temperature);
   delay(10000);
}

Do this instead:
Code: [Select]
void thermometer_init(uint8_t pin) {
    pinMode(12, OUTPUT); // clock line to thermometer
   // Blah blah
}
int thermometer_read() {
   digitalWrite(12, 1); // enable thermometer chip
   // blah, twiddle bits, etc.
}
void setup() {
  thermometer_init(12);
}
void loop() {
  temp = thermometer_read();
   Serial.print(temperature);
   delay(10000);
}

RoyK

Quote
Lucky you. I never get extra time.


I was on monthly salary and projects were often due end of day on a Friday. He'd give me until Monday morning sometimes.

PaulS

Code: [Select]
void thermometer_init(uint8_t pin) {
    pinMode(12, OUTPUT); // clock line to thermometer
   // Blah blah
}

Pass in a pin number that gets ignored. Great idea. Not.

Go Up