Searching \ for 'Universal PIC Hardware interface...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Universal PIC Hardware interface...'.

Truncated match.
PICList Thread
'Universal PIC Hardware interface...'
2007\07\14@223600 by Tobias Gogolin

picon face
Hello everybody, an enjoyable weekend!

being a PIC virgin and not even having a PIC programmer yet I am facing the
challenge now to make the intelligent parts of my Parabolic 2 Axis Solar
Tracker
I mean the parts that read the sensors and decide when and how to energize
With other words I got the rest of the hardware up that is the dish the
actuators and the sensors (photo resistors)
And I even made up a circuit in my head with accessible components to read
the data into a computer over the parallel port...
I am alarmed by the extensiveness and amount of soldering involved I realize
I could be replacing all those more complex chips with a PIC!
But I do want the ease of developing the more complicated parts on the PC
first!

I'm thinking to have a C program that tracks by sensors and learns dish
coordinates (as given by pulse counts from those linear actuators) relative
to time.
This way type of tracking (closed loop) on sunny days and apply the learned
to cloudy days (open loop)
So for example it will know at what position to expect the sun, then correct
if sensors provide better information and its not an overly unusual sensor
input and position for the time of day.
I think it should be a fuzzy type of program that averages sensor readings
for a while before turning motors on, and even then I may consider to
gradually increase from the minimal PWM % to get the linear or rotary
actuator motors moving!

So I am concerned that I would use more cycles redoing this program than my
PIC would have rewrite cycles :)
Therefore the idea about a minimal circuit that I could load into the 16F676
(or even a bigger chip I may have) that would just allow me to read the ADC
values and to read inputs and set outputs on the other pins that I could
activate easily from a PC for example over a software interface and the
serial port! That would reduce a lot of soldering for me, and eventually
when I like the program I am hoping adapt the interfaces and just compile it
to run on the PIC autonomously...

So does any kind of Project exist that I could use to have this generic
hardware software interface?

Thanks in Advance!


--
Tobias Gogolin
skype: moontogo
messenger: spam_OUTusertogoTakeThisOuTspamhotmail.com

You develop an open source motor controller at
http://groups.yahoo.com/group/GoBox

2007\07\16@051415 by Forrest W Christian

flavicon
face
I'm having a hard time understanding exactly what you are looking for,
but I think the gist is that you're trying to figure out if there is an
easy way to make a PIC work for your application... and whether or not
it is easy enough (or has enough capabilities) that the PIC can run the
whole show.

I would point you in a couple of directions:

1) If you want to get a jumpstart on developing the software without a
lot of hardware development, I would recommend you look at one of the
development boards available.   I recently purchased a MikroElectronika
EASYPIC4 and have been very happy with it.   I also purchased the
EasyConnect boards which provide screw terminal attachment to all of the
ports, and also the boards which connect to a proto board (I think
EasyProto).     They also have a PICPLC8 and PICPLC16A which may or may
not be better suited to what you are doing since they have some
additional input/output filtering (Optoisolated inputs, relay
outputs).   Other boards also exist.

2) In relation to trying to develop this first on a PC (via the parallel
port) and then migrating it to a PIC, I personally haven't ever really
wanted to do this.   There isn't really any easy way to port the code,
and with the C, Basic, Pascal and Other compilers available for the
complete PIC range, I really haven't found any benefit of doing this
since it's now really easy to develop for the PIC since you can pick
your language and run with it.   With a good ICD which is integrated
with your development environment, it doesn't really gain you anything
to do it on the PC itself since the PIC development board really becomes
more or less a peripheral to your PC.   That said, if you do find
yourself in a situation where you need the capabilities a PC offers
(better interface, lots more processing power, etc), but need to
interface with the real world, it is fairly common to find a PIC setting
between the PC's Serial or USB port and the interface.   I doubt this
would be ideal for your situation.

3) In regards to your idea regarding the sunny/cloudy day algorithm,
this might be workable, but knowing what I know about solar (and the
effectiveness of the passive (hot water) trackers), I'm not 100% sure
that the cloudy day algorithm would be needed if your sensors were set
up correctly.  Ideally, they should determine if the hottest sun is
left, right, up, or down from the currently pointed direction - and
should work whether cloudy or not.   Plus, you may not want to move the
tracker at all if it is too cloudy - if it costs more watts to move the
panel than you would gain by moving it, then why move it?  That said,
I'm not about to discourage you from trying it at all, since sometimes
the complicated solution works better.  You may also want to consider a
simple algorithm which does some math based on sunrise, sunset and
latitude or similar.   The whole point of this point is that you should
think about effort versus wattage gain.  This is why solar trackers are
rare for those applications with constant wattage needs (engineer the
system and point the panel for winter solstice and forget it since
everything else is better watt hours/day), and also the reason why the
passive tracking using water temperature effects is so popular (don't
burn any watts moving the panel).

4) In regards to the rewrite cycle (flash durability) issue, you are
correct in some cases that with newer pics with lower flash durability
that there's a development issue with # of write cycles (other people
might be able to be more specific).  However, that's what a socketed
processor is for.  If you do exceed the write cycles, yank the PIC and
put a new one in.  

5) One last thing.  You really probably don't want to deal with a PC for
this long term, since the PIC circuit is a lot lower power than a PC.  
Plus the newer PICs have a very low power technology (Nanowatt), which
would allow you to look at the position of the tracker, move if
necessary, and then sleep for minutes until it is time to make another
decision about the position of the panel.

-forrest

Tobias Gogolin wrote:

{Quote hidden}

2007\07\16@054928 by Tobias Gogolin

picon face
Thanks Forrest that was an extensive reply!
Yes I agree I don't want the PC in this in the long run for obvious reasons
of power consumption...
What I figure by now it must be extremly easy to make a PIC program that
serial port receives the register number and the value to be written to it
and maybe have a few predefined routines such as for reading analog inputs
or writing eeprom locations
So basically the program wont even have to change much, I can have a routine
in C that says write register, and in the PC to Pic version it will write
the data to the serial port,
later the code can be compiled with small changes to run directly on the
PIC.

I think that tracking through cloudy hours is a good idea because it may
clear up at any time, besides I noticed that even when the sun is hardly
recognizable in the sky some heat is being concentrated!

Anyhow I think it is such an easy and obvious project to make a universal
Serial Software to Hardware Interface, it was probably already done and if
not it could probably be done within a few hours even when using assembly
language! For me being slightly serial port phobic I remain wondering will I
be able to do it without any expensive level converters? (MAX232 etc)


On 7/16/07, Forrest W Christian <.....forrestcKILLspamspam@spam@imach.com> wrote:
{Quote hidden}

> -

2007\07\16@060629 by Hector Martin

flavicon
face
Tobias Gogolin wrote:
> Anyhow I think it is such an easy and obvious project to make a universal
> Serial Software to Hardware Interface, it was probably already done and if
> not it could probably be done within a few hours even when using assembly
> language! For me being slightly serial port phobic I remain wondering will I
> be able to do it without any expensive level converters? (MAX232 etc)

You can use discretes to create a simple level shifter, but I doubt you
want to. MAX232 is cheap, rugged, and easy to use.

--
Hector Martin (hectorspamKILLspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\07\16@105001 by Forrest W Christian

flavicon
face
Tobias Gogolin wrote:

>So basically the program wont even have to change much, I can have a routine
>in C that says write register, and in the PC to Pic version it will write
>the data to the serial port, later the code can be compiled with small changes to run directly on the
>PIC.
>  
>
I think you're underestimating how different C is on a PIC versus on a PC.

Because a PIC has limited memory and other resources, many algorithms
need to be specifically tailored for the PIC.   Especially if they
involve storage of tables of data or the like.  I'll give you a little
example.   One of my recent development projects involved parsing GPS
NMEA strings.  These look something like:

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

On a PC, you'd read a line into a buffer and then split it apart with
things like strchr and the like. On the PIC, I didn't have enough room
for the buffer so I had to do it with a state machine of sorts,
splitting it apart as it was being received.

>I think that tracking through cloudy hours is a good idea because it may
>clear up at any time, besides I noticed that even when the sun is hardly
>recognizable in the sky some heat is being concentrated!
>  
>
Yes, but the most efficient position when the sky is cloudy is not
necessarily pointed at the sun.  Because the sun's rays are scattered,
often pointed straight up is best on overcast days since it has the most
visibility to the entire sky.  There are several reference materials on
google which talks about this whole topic.  One I quickly found is at
http://www.rpc.com.au/products/panels/pvmodules/pvmodules.html .   It
all comes down to wattage increase versus cost to move the panel.  If it
costs 100mah to gain 50mah it doesn't make sense to move the panel at
all.  

The point I was trying to make is that moving the panel on a given
overcast day may not be the best thing for gaining efficiency.  You may
end up having less net power stored in the batteries after tracking the
sun than if you had just left the panel in whatever position it was in.  
If you really want to gain energy efficiency, you need to understand how
much power it is taking to move the panel versus how much power you
might gain by moving the panel.  

>Anyhow I think it is such an easy and obvious project to make a universal
>Serial Software to Hardware Interface, it was probably already done and if
>not it could probably be done within a few hours even when using assembly
>language!
>
Yes, it would be fairly easy... but if the defined reason for doing it
is just to ease development, I really think you'd be better off with an
ICD and a copy of a C compiler for the PIC which supports it.

>For me being slightly serial port phobic I remain wondering will I
>be able to do it without any expensive level converters? (MAX232 etc)
>
I generally will use a pair of 2n7000 fet's, a couple of resistors, and
some diodes to level shift and invert the 0 to 5V to 0 to 9 V or so (not
technically standardized, but will work on most ports).  There are also
schematics floating around for doing it with NPN transistors, and
stealing the - rail off of the RX line.  

-forrest

2007\07\16@112301 by Michael Rigby-Jones

picon face


{Quote hidden}

Bit of a chicken and egg problem surely, as you won't necessarily know how much power you could gain without moving the panel in the first place?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\07\16@113723 by Tobias Gogolin

picon face
Anyhow there is no gain in being lazy if in case the sun comes out, (and I
think that is normal at most places even if in the afternoon) you're going
to move the dish there anyway.
Besides I would estimate right now that tracking once across the range takes
a minute, at 24V 3A max that would be 72Wmin, so for any decent size of PV
that would be worth to track you would recuperate the energy if the sun came
out for only a minute...

On the serial interface: what if I had a serial interface coming straight
from a not level converted source such as my WRT54G?
That is a cheap little low power  Linux Box that could even add remote
monitoring capabilities to an installation!

On 7/16/07, Michael Rigby-Jones <Michael.Rigby-Jonesspamspam_OUTbookham.com> wrote:
>
>
>
> >{Original Message removed}

2007\07\16@134833 by Robert Rolf

picon face
Tobias Gogolin wrote:
> Besides I would estimate right now that tracking once across the range takes
> a minute, at 24V 3A max that would be 72Wmin, so for any decent size of PV

3A??? Just how big is this panel that you need such a power hungry motor?
DISeQC Satellite dish motors (rated to 1M dish size) draw about 300mA @18V
while moving and do H-H in about 90 seconds.

> that would be worth to track you would recuperate the energy if the sun came
> out for only a minute...

Really? What is your loss due to angle error?
SIN (75), a 15 degree tracking error, is 0.97 or a 3% loss. Hardly seems
worth the trouble to move for less than a 20 degree error.
And then you have losses due to inertia (start surge) so it would probably
be more efficient to move for longer periods, but less often.
You can probably measure your motor/system and then model it to see what
minimum update time to use (10's of minutes I would think).

And if you want to be really efficient, wait for a 15 degree track error,
then overshoot by 15 degrees so you activate the motor/PIC less often.

> On the serial interface: what if I had a serial interface coming straight
> from a not level converted source such as my WRT54G?
> That is a cheap little low power  Linux Box that could even add remote
> monitoring capabilities to an installation!

It's not THAT low powered. 30W or so.
A PIC would draw sub milliampers. e.g. microwatts, since it only needs to
do something a few times an hour. With a RTC (real time clock ) chip like
the Dallas 1302, it wouldn't need to have ANY communication since it
could compute everything from the current date/time.
And some flavours of the RTCs have 'alarm' outputs which you would program
to periodically wake up the PIC to do some work. (saving lots of power in the
process).

As for level conversions, I use a 74HC14 schmidt input inverter.
10k input resistor and clamp diode for the RS232 in side. Paralleled gates and 100
ohm protection R on the out side. Good for 100's of feet.
Although given that you are far away, and up high (good lightning target),
I would use fiber optic cables for communication. And to save power, only
turn on the LED to send a SPACE condition (opposite of most logic).

You can get the optical drivers from dead DVD players that have an optical
output. Lots to be found at the local eco recycle center.

Robert

2007\07\16@142740 by Tobias Gogolin

picon face
Well yes I was using a conservative worst case estimate for my old oversized
linear satellite actuators
And its worth mentioning that since I am using recycled fiberglass satellite
dishes to concentrate the energy, they do need to point straight at the
source of parallel rays
For old style PV the controller could get a specific mode where it actually
measures the power produced to optimize the positioning, actually I am
hoping to investigate that soon, also in order to apply the same electronic
infrastructure some day to an automatic wifi antenna tuning setup!

And my WRT definitely does never use anywhere close to 30 Watts, as a matter
of fact its powersupply is rated at 12W and I read somewhere that it doesn't
even use half of it!

Anyhow let me make clear that obviously the long run solution will be just a
pic, an LCD and a few buttons or maybe some form of wired or wireless way of
connecting it to the computer to monitor, fine tune and to do statistics...

Its just that I don't have a pic programmer yet and I want a solution that I
could even program with a friends programmer and then continue developing
here...
I have been impressed by programmers that I have seen that just seem to use
two transistors and a few diodes (like this one for example:
cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ih=014&sspagename=STRK%3AMEWA%3AIT&viewitem=&item=330146276296&rd=1&rd=1#nogoI
may get one of these soon! Do you recommend it?)
Is there such a published circuit that I could implement here quickly?

>As for level conversions, I use a 74HC14 schmidt input inverter.
>10k input resistor and clamp diode for the RS232 in side. Paralleled gates
and 100
>ohm protection R on the out side. Good for 100's of feet.
>Although given that you are far away, and up high (good lightning target),
>I would use fiber optic cables for communication. And to save power, only
>turn on the LED to send a SPACE condition (opposite of most logic).

I like your suggested solution! is there a schematic you would be willing to
share?
How many optocouplers would I need to do also separate the computer side
from the tracker side?

Thanks for the collaboration!







On 7/16/07, Robert Rolf <@spam@Robert.RolfKILLspamspamualberta.ca> wrote:
{Quote hidden}

> -

2007\07\16@214938 by Forrest W. Christian

flavicon
face
Tobias Gogolin wrote:

>And its worth mentioning that since I am using recycled fiberglass satellite
>dishes to concentrate the energy, they do need to point straight at the
>source of parallel rays
>  
>
Well, that's a whole different problem than optimum pointing of a flat
panel (which has a wide tolerance of misalignment and is pretty
forgiving of not being moved at all).  The effective beamwidth of a dish
is relatively narrow, so you're going to have to be really accurate in
this case, which means you're going to have to be moving the dish a
lot.  It will be interesting to see the efficiencies you get with doing
this..

Personally, I'd be tempted to implement this using an accurate clock and
lat/long data to come up with accurate az/el settings for every moment
of the day so that you could be sure you are pointing *exactly* at the
sun.   I'd probably also do some intential misaligns also to ensure I
was tracked ok.

>For old style PV the controller could get a specific mode where it actually
>measures the power produced to optimize the positioning, actually I am
>hoping to investigate that soon, also in order to apply the same electronic
>infrastructure some day to an automatic wifi antenna tuning setup!
>  
>
That would work also, but for efficiency sake, I'd probably use a
predicted az/el (using lat,long and date/time) as a starting point, then
optimize from there.   This is what I meant by "intential misaligns".  
Move to the az/el, then move up, down, left, or right and verify that
there is less sun when you are off-axis.  If there's more sun off-axis,
then use this to either warn the operator, or to slightly tweak the
table.   If you got really fancy and you had one of the bigger pics (and
you were good at writing tight code), you may even be able to figure out
whether the misalign was due to date/time inaccuracies, az/el
positioning errors, or lat/long inaccuracy.

I don't remember if your original description included this, but it may
also be interesting to have more than one panel (or to have some sort of
slightly off-axis sensor) to determine if the sun is brighter in any
given direction without moving the dish.

>Its just that I don't have a pic programmer yet and I want a solution that I
>could even program with a friends programmer and then continue developing
>here...
>  
>
Then the magic word you are looking for is "bootloader".  Program the
bootloader on the friends programmer, and then just download your
program to the PIC via the serial bootloader program.

-forrest

2007\07\17@010602 by Tobias Gogolin

picon face
Yes there could probably be a automatic adjustment mode, where the head
temperature or electric energy output is used to figure at which balance
between fotoresistor readings the optimum is... but I think I better make
that a manual option!

The bootloder came up before
I guess thats a chip that is 'Self-programmable under software control'
like one of these:
18LF4320
or
18LF4539
those bootloaders are some of the shelf programs?
where do I find them?

On 7/16/07, Forrest W. Christian <KILLspamforrestcKILLspamspamimach.com> wrote:
{Quote hidden}

> -

2007\07\17@100330 by Forrest W. Christian

flavicon
face
Tobias Gogolin wrote:

>Yes there could probably be a automatic adjustment mode, where the head
>temperature or electric energy output is used to figure at which balance
>between fotoresistor readings the optimum is... but I think I better make
>that a manual option!
>  
>
I was actually envisioning a situation where you point based upon
calculated az/el values, and then use the photoresistors only to
determine if it really needs to be above/below/left/right of the
calculated values to ensure proper alignment.  I.E. calculate that the
array needs to be at 32*x15* from lat/long and time, and then use the
resistors to tweak it slightly - if you get meaningful data from them.

>The bootloder came up before I guess thats a chip that is 'Self-programmable under software control'
>like one of these:
>18LF4320
>or
>18LF4539
>those bootloaders are some of the shelf programs?
>where do I find them?
>  
>
Most of the modern PIC's will do this.  There's also a appnote by
microchip on this.  Google "PIC Bootloader" or "Bootloader 18F4320" or
similar.

-forrest

2007\07\17@150108 by Tobias Gogolin

picon face
>I was actually envisioning a situation where you point based upon
>calculated az/el values, and then use the photoresistors only to
>determine if it really needs to be above/below/left/right of the
>calculated values to ensure proper alignment.

Yes except that I don't want any complicated calculations, only experience
values, and those also only for the case there is no contrast on the sensor
values (cloudy/overcast)
I choose first open loop, and then a differential type dp/dt open loop
advancing when sensors go milky (where dp is the speed to change actuator
pulses)

So are there any open source boot loaders?
After all this is an open source project!
I am still thinking to go the min. PIC program way first and then only
gradually moving the code from the PC side of the serial port to the PIC
side
There are probably nice little code blocks to implement a simple serial
interface that I can build on?
Looks like the sourceboost C IDE which I have been familiarizing myself with
supports the 18LF4320!
I guess the bootloader would be the master of the serial interface and when
its not a load new code command forward serial data to a specific function
in the code area...


On 7/17/07, Forrest W. Christian <RemoveMEforrestcTakeThisOuTspamimach.com> wrote:
{Quote hidden}

> -

2007\07\18@071103 by Tobias Gogolin

picon face
How about this thought of the engineering mind?
How efficient would your solar PV equipment be to make it worth to track the
moon?

On 7/16/07, Tobias Gogolin <spamBeGoneusertogospamBeGonespamgmail.com> wrote:
{Quote hidden}

> > >{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...