Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Which port would I be better using to program my atmosperic climate
control system?

Which lends itself better to ease of programming?



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "c04203420" <c04203420@y...> wrote:
> Which port would I be better using to program my atmosperic climate
> control system?
>
> Which lends itself better to ease of programming?

If I was doing this project, I would use the Basicx and program the
climate controls you are going to use with it. The basicx would only
send Raw data back to the computer by serial.
Once back at the PC you could use any programming langauge to make
your graphicial displays you need.
This could be programmed in one of two ways. The data is always coming
into the pc or the PC asked for the data in which the basicx would
respond. The latter would be nice if you wanted more than one location
to be monitored. Each Basicx would have an address. With serial you
can convert to Ip and put the data on an ethernet or to an Rs422 line.
The Basicx has 8 AD's in it so this should be no problem.

An example is I had a problem with some servos in a project I was
building. I was using an Basicx to capture the 2 joysticks information
and send it by serial to a radio. I wrote a program on the PC to show
me graphical what each of the 5 servos were doing and the data at the
bottom of each graphical point. To make a long story short it turned
out to be the radios.

Ken Smith




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Unless you NEED parallel, then you will save many pins by going with
serial.

Parallel is faster, but usually serial is fast enough.

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> Unless you NEED parallel, then you will save many pins by going with
> serial.

How does serial deal with concurrency?



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I am not sure what you mean by concurrency in this situation.

It is asynchronous, and relatively low speed, although some hardware
can deal with up to 1M bits/sec. I am not sure of the top speed of
the BX hardware, but I bet it is considerably less than 1M. 115K is
the usual "fast" speed for RS-232

If you want other popular standard serial formats, then there is 12C
(2 Wire Interface)which is limited to about 400K bits/sec, and this
is pretty easily achieved with the AVR hardware. I have not tried
actually using it on the BX platform.

A faster serial format SPI. The BX supports this format, but....
The EEPROM which is accessed for the instructions uses the same
bus, so a lot of SPI activity might slow the BX program execution
speed. I believe the AVR hardware is capable of up to 8M bits/sec
with the SPI protocol. In real life, I would expect subatantially
less speed than that, especially with the highlevel programming and
sophisticated operating system of the BX. If your were totally
optimized for pure SPI and essentially nothing else on the raw AVR
hardware, then maybe you could approach 8M.

I have never tested the actual through-put on the BX platform for
either the I2C or SPI.

None of this deals with "concurrency", so please let me know exactly
what you mean. I would usually take it to mean in this type of
situation, "immediacy" or "simultaneity". Since the hardware can
only do one thing at a time (except setting/reading 8 port pins
simultaneously), concurency is really just REALLY fast serial which
gives the appearance of things happening at the same time.

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

[Much removed by moderator]

> None of this deals with "concurrency", so please let me know
exactly what you mean. Thanks for that. Your last paragraph answered what i needed to know.
I obviously didn't read what i had wrote. It was a little
contradiction in its own right.

Thanks for your input. As a new forum member I have noticed people
really do go out of there way in here to answer questions with great
depth. For that i give praise. Some forum members would be quick to
say RTFM. (Read the F****** Manual). Im very new to pysicial
computing so thanks to all who have helped so far. Im also reading
the manual(s) for electronics. Its just that could take years and i
like interaction along the way.

Thanks people...



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I agree, not liking the RTFM! responses. In many cases the manual
only makes sense once you know tha answer, especially if you have to
go the hardware datasheets!

A few minutes spent giving a couple of basic pointers (learned through
long hard experience) and simple examples can save someone else many
hours of trying and failing. Getting that little boost up the learning
curve makes a real difference.

It sounds like you are getting into something interesting in your
project if you are considering issues of "concurrency", and if
maintaining absolute concurrency is a consideration..... What is the project?




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> [removed]
> What is the project?

Im attempting to build an atmosperic climate control system that
faithfully automates the artificial plant growth process. Initially I
wanted to do the whole thing in Java and considered buying a javelin
for the job but Im thinking of holding out and doing it basicx style.
Even though VB has to be one of the worlds worst languages.

I'll interface with the system using swing under Java though. Should
be fun...



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Basic is really for quick programming projects and beginners. Java
is more C like. You might want to go to C directly, but then you
lose the hand-holding that the BX designers give you. You will have
to find and customize all the interface routines. Not that hard,
actually.

You then have access to ALL the pins and ALL the power of the
processor.

As far as I am concerned, the two options would be the BX-based
rapid development platform, then IF you find it inadequate, step up
to the raw AVR hardware.

I am attempting to develop, for my own uses, a stamp/BX-like AVR
platform. I am trying to pack a ATMega128 64 pin device with the
necessary support hardware into a breadboardable DIP package similar
to the BX. You would then be able to program it with your favorite
programming package which creates a compiled program to be placed on
the hardware (more steps than BasicX).

I am also designing stackable daughter cards to add functions such
as I2C-based FRAM, RTC, and access to the hardware I2C bus. SPI-
based FRAM and miniSD card memory. I/O daughter card with the 2
RS232 hardware ports and maybe RS422.

One could stack 2 of the CPU DIPs for multiprocessing. I have not
tried this one out, but it could be FUN!

This is very much in the design process....

Anyway, I got off the original topic. I really don't see much
advantage to using JAVA, but that is just my prejudice. However, I
am using the BX as the prototyping base for hardware testing. This
way I do not have to worry as much about the programming, BasicX
takes care of itself more than the lower level languages, so I can
focus on the hardware. Once I get the hardware working properly, I
then move over to the AVR hardware and C, knowing that the only
issue is getting the programming to work!

But, if the job is not too demanding (most are not) then I could
stop with the BX-based solution.

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Coming from software engineering my approach to things will
undoubtedly differ to those of electronics engineers.

The idea behind using Java was purely based on my solution being
cross platform and well designed. Java fits both these goals and is
high level enough for extemely rapid interface development.

I rely exclusively on Linux so I was trying to avoid the pitfalls of
using a miscrosoft like solution (Subset of VB) to get the horse
power done.

Java would have helped greatly into putting my project into a purely
Object Orientated Design and this would improve design and increase
devleopment speed. This however is only a personal project so I
really dont have any restrictions on how i develop. For me the
biggest problem is this huge learning curve that I must overcome.

I know java has a serial api what i dont know is how to communicate
directly with the bx-24 using that api. You mentioned AVR and C.
Could you elaborate more on this concept.





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "c04203420" <c04203420@y...> wrote:
> I know java has a serial api what i dont know is how to
communicate
> directly with the bx-24 using that api. You mentioned AVR and C.
> Could you elaborate more on this concept.

Well, if you are already familiar with a certain language, then it
is a pretty good starting place no matter what other consideratons
you may have.

RE: AVR. The Atmel AVR is the CPU on the BX chip. The availability
of certain functions on the chip influences the availability and
speed of what is offered in the BasicX language.

Re: C. I bet you know that C is a mid-level programming language.
I consider it "low level" because usually I can predict the exact
ASM that the C commands will generate. C++ is the object oriented
version and is more abstract. To use C you would have to leave the
BX philosophical works and enter the world of direct interraction
with the hardware, at least more direct than BasaicX.

Java is very C-like in its syntas and appearance from that little I
know of it. So, I bet you could learn it quickly. While Java may
have a serial function built-in, it would rely on the compiler to
know what to do to interract with the hardware. Probably not an
problem, at least with the Javelin.

Since these microcontrollers are so small, with such limited memory,
I find the abstract object-related functions of certain programming
languages to be a hinderance in writing streamlined code. In my
personal experience, "objects" are great when you are writing
generic cross-platform code and do not particularly care if it is
the most efficient in terms of speed and size.

"Objects" are more complicated to use, at least initially. But
eventually, with large projects, then the objects ad classes are
great boons.

I am not sure that the use of objects is all that helpful for this
sort of hardware.

So, it boils down to what language you want to use, the availability
of functions you need within the language, and what platform will be
suffcient to get the job done. Last night I interfaced the BX with
a GPS card in about 5 minutes. It certainly would have taken much
longer if I tried to do it with C and my ATMega development
platform. Now I know it works beautifully, and I can now pursue
that stage.

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I suppose I could program the microcontroller in C low level style.
Could you point me towards some resources for doing this with the bx-
24. Im not sure whether this jump in at the deep end approach would
suit me at first glance because not only am i new to the bx-24 im also
new to electricity and electronics.

Im still wading through the learning curve. As for you viewpoint on OOP
i wasn't planning on using it for anything but the GUI front end. Where
resources are not held ransom to mr limitations.

Could you also explain how i could set up a suitable environment under
linux with the bx-24 or is this just a bit of a dreamers dream?

Much appreciated for your feedback.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

[This is a continuation of a thread under a different name. The
topic has become as above]

The issue of the front-end vs the BX are quite different. All the
PC-based front-end needs to do is to communicate with the BX to get
it to do something.

All the PC needs to know is what commands to send, and how to send
them.

All the BX nees to know is how to get the commands and what to do
with them.

There is no other need for a connection between the development of
one part vs the other. So, you could easily program in JAVA or
anything else for the PC, and this would not directly relate to how
you programmed the BX.

Since it sounds like you are familiar with PC programming in Java,
then this should be your programming language. This is especially
true since the front-end tends to be more complex than the actual
end-device.

I would NOT recommend trying to go to C and direct use of the AVR
hardware with all the complexities it entails until there is an
established need. Go ahead and program the BX with everything you
need. If you end up needing more I/O pins, more memory, more speed,
then it would make sense to go with the raw AVR hardware.

You can get basic compilers for the AVR hardware but it is costly
compared to the FREE really good C compiler. Now the C compiler has
a more user-friendly front end too. I have not yet tried it. I
still do it the hard way. Recently, though, I have been working on
hardware and have not messed with the C programming. When I get the
next iteration of the hardware done, then I will have to modify
about 100 pages of C code. ugh.

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Firstly thanks for your response.

Im new to all this so please dont despair.

Id like to develop as high level as possible for the obvious reasons.
Me being new and all. Could you please clarify how my java front end
would communicate with the bx. All the bx code is a subset of VB.

Please take me through an abstract or preferably more technical scenario.

For example. If i had a temp sensor on the bx and i wished to read the
value, display it in Java and then still in Java manipulate the rpm of
the fan connected to the bx and then get the values of the rpm speed
back in Java how would this go exactly. Sorry if that is gobbledigoo.
Im half awake as usual.

I dont get how Java will talk to the VB subset.

Thanks...



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Would i be better reading the serial port standard and then asking
questions?




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Hi c04203420!

> Please take me through an abstract or preferably more technical scenario.
>
> For example. If i had a temp sensor on the bx and i wished to read the
> value, display it in Java and then still in Java manipulate the rpm of
> the fan connected to the bx and then get the values of the rpm speed
> back in Java how would this go exactly. Sorry if that is gobbledigoo.
> Im half awake as usual.
>
> I dont get how Java will talk to the VB subset.

Did you see my reply to your original thread? It was on 9/30.

Basically, the languages used for the PC and BX are irrelevant when it comes
to the communication between the two devices. Doesn't matter at all.

It just so happens that the BX requires the BX language (VB-like). So that's
what you have to use with the BX-etc. On the PC, all you need is a language
that can communicate using the serial port. You connect a serial cable (null
modem) between the BX and the PC, and voila! they can talk to each other.
They do NOT communicate using the source code. Think of a console app. It
sends output to the standard output (screen), and receives input from the
standard input (keyboard). The application doesn't need to know if the
screen is a 15" or a 17", and it doesn't need to know if the keyboard is
black or white. All it needs to know is how to send data to the screen, and
how to receive data from the keyboard.

Go back to my previous post from 9/30, and see if the example makes more
sense. If not, email me and I'll try to answer your questions about
specifics in your project.

Sloan



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Well, this can get complicated pretty fast.

Here is a list of the jobs:

1) The BX reads the sensors.

2) The BX then sends some data or codes to the PC. Easiest through
a serial cable, but you can use your imagination for the
communication.

3) BX listens for commands from the PC over the cable. Checks
every so often and the serial buffer is big enough to store all the
data that comes in until the BX next checks.

4) The PC takes the info it got from the PC and displays it to the
user who then makes changes to various settings and variables.

5) The PC then sends the new settings to the BX

6) The BX updates its settings and then commands the stuff to
happen (move motors etc.)

7) The BX should be doing autonomous decision-making in the absence
of user input. This is the ideal mechanism. The BX program is
smart enough to know what you want to do before it even tells you.
The commands you sent it are simply to change the ground rules, not
to micromanage the details. In the ultimate case, the BX is such an
expert system that it NEVER needs to have updated settings, and you
never need to have such a sophisticated interface to the BX as a PC-
based front-end. Just a little LCD screen on the BX to make some
basic choices about what is being done.

As for the details for the programming, Again, the programming of
the PC and the BX are totally separate. You (yes, YOU) simply
determine what data you need the BX to send to the PC, and when.
You then decide what commands the BX should get in return. You
write the program for the BX to handle those commands.

The programming language should allow you to make the decisions of
what to do and how, not vice-versa. In this example, all the BX and
the PC need to do is know how to send and recieve data over the
serial line. What happens on the other end is not important to that
particular device.

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "c04203420" <c04203420@y...> wrote:
> Would i be better reading the serial port standard and then asking
> questions?

NO!!! The point we are making is that the hardware in the end does
not (should not) matter. The specific programming language does not
matter.

In the end what happens is that data is transferred (the less you
know about how that happened the better) from one device to
another. You need to know what data needs to be sent back. That is
it!

The hard part is deciding what data is sent and how to act on it.
The beauty of the BX philosophy is the INSULATION it gives you from
the hardware so you spend your time on the real task: the decisions
for which actions/when.

Unfortunately, the various modules (sensors, wireless comm) are
still so crude that you need to know how to make it work and what it
does. Ideally all the modules (sensors, communications, effectors)
are black boxes. All you do is connect them up and they work. You
need to think about the program (expert system) that runs the whole
thing.

Stuff like serial communication on the BX really IS a black box.
You do NOT keed to know HOW it works. You just need to know how to
get the data out of it at the end. Reading stuff off the
communication queue is simple. The queue takes care of itself.

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Thanks ever so much. Now that it has sunk in a little it is time to
decide on design. As we speak i was doing some practice with the
soldering iron for the first time and the ali i was working on has
heated up so much the plastic coating on my desk is now sticky!

Oh dear. A little too much playing. Never mind.

Anyway back to the point. I got what you said eventually. I think. I
program the bx to listen for commands/data coming in from the serial
port. These commands originate from whatever language i so care choose
to use so long as that language can transmit through the comm ports.
My gui front end traverses this process.

As for the LCD front end. Forget that. I spend all my time on a pc and
sometimes away from home so my ssytem will eventually hook up to a web
based interface to manually intervene or check on status wherever and
whenever.

This is truly fascintating stuff. I pulled out of my final year in UNI
becuase i realised that I wanted to both interact at a virtual and
physical level within my domain. So far the trasition has proved
interesting. The learning curve is massive as you would expect but i
think i'll get there.

Before i proceed any further i'll need to buy the transducers.

I have narrowed the first phase of my project into a series of inputs
and outputs. Here goes.

Cloning Chamber
===============

1) A light (AC 55w) [Already have this]
2) A low powered water pump (AC - approx 50w) [This I have too]
3) Digital Hygrometer (SHT75 or 71 from sensirion or similar)
4) Submersible temperature sensor (Any ideas are welcome on these)
5) A submersible ph sensor (Would be good if combined with temp sensor)
6) A submersible water heater with thermostat to change water temperature)
7 Single AC extractor fan. 120 - 180mm.

I believe that is all for now. I have considered a water level sensor
but this is going above my head at present. I'd like the sensor to
alert me when water levels fall below a certain threshhold.

I have heard the sensirion digi hygrometer are excellent value for
money but as for most of the other components im totally stumped. Any
help would be much appreciated.

Im really gunna have to get some documentation in motion here but its
just i have a zillion ideas and questions floating around in my head
at present its hard to get any sense of structure going.

Thanks.

Marc.




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "c04203420" <c04203420@y...> wrote:
> I dont get how Java will talk to the VB subset.

Think command/response protocol over a serial channel. It has nothing
to do with the language used at either end to implement the program
that does the commanding/responding.

All you need to worry about is specifying what the command/response
protocol is. Well, not quite all. There are still the inherent
limitations of the system at each end to contend with plus possible
errors in the communication channel, etc.

Don





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

OK, you got it!

Web-based stuff would be cool for this.

To control some of this stuff you will need to learn how to do PWM
for lights. For the fans, maybe DC with PWM would be easiest.
Otherwide I guess you need to learn how to do Variable frequency
sine wave to change AC motor speed, I think.

I also sort-of pulled out at the university level. Not completely,
but just engineering. I never bothered to ENTER engineering. I
wanted to do a little of EE, and a little of ME, etc. The
curriculum was way too narrow for such a liberal-arts approach, so I
dumped the plan of engineering. I then thought about Math, but I
was not smart enough. Physics was fun, but ultimately boring.....
oh well.

Actually my favorite stuff was philosophy. And you can see here,
our real discussion was on the philosophy of interfacing to the
outside world!!!!

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )