Diving into PIC32

[Barry Gershenfeld-2]

It is my fate to become involved with the PIC32 line.  Mostly because that's
where the USB host functions are, and USB is some sort of unstoppable curse
upon the land.  I ordered the PIC32 starter kit, and the USB starter kit,
and now I must somehow rise to the competency level I have with my PIC16 and
PIC18 parts.  This isn't really the right time to sit down with a cup of
coffee and the PIC32MX Family Data Sheet (646 pages) or maybe just the
PIC32MX Family Reference Manual (1138 pages).  Better to get my feet wet and
learn the landscape first.

I've been a happy CCS user for 9 years and now I must learn the Microchip
way of C.  CCS doesn't have a PIC32 compiler (yet?).  Also throw in an
upgrade to some recent MPLAB for good measure. Figure out how to install the
USB connection to these eval boards--this time-- (do I install the driver
first, or do I plug in the device first?  The answer likes to change and
it's hard to know if you've got the latest information--or even if it
matters anymore).

I'm looking for some connectedness with the 32-bit pioneers among us.  I
will be looking at the Microchip forum, too, but somehow that just doesn't
have the same feel as the good old PICList.  I've got a lot of experience
under my belt, and I'd have to say about 50% of it came from reading the
list.  So maybe I'll post a tidbit or two as I run across them.

So here's my startle moment for the day.  The starter kit comes with a few
sample programs. I spotted one, which was older, no longer used, apparently,
but included nonetheless.  It's a 3-button 3-lamp "Simon" game.  So I
brought that one up, and was poking around with the debugger. There's a
switch() statement that looks at _gameState...kind of obvious what's going
on there...but the switch statement only had like 2 cases.  So most of the
time it would just do nothing there.  In the outer loop were statements to
debounce the buttons, and then to set some flags based on the switches.  The
only other line is for that switch statement.  Where's the rest of the
logic??  I went back to the source code and did some searching on variables
and function names and in particular, all the enumerated states that
_gameState could have.  And then I found the rest of the code.

Inside the interrupt handler.

Granted, there weren't any delay loops in there, although there's a lot of
fiddling with the timer.  So I suppose the code executes OK and then gets
out...but still...we just try not to do stuff like that.  I suppose they
give projects like this to the new kids, and well, it works, doesn't it?
(I'm not sure. One of the reasons for poking around is to figure out how the
game is supposed to flow).

Anyway, if I suddenly pop in with a question, this might provide some
background.

Barry
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Harold Hallikainen-2]

I'm also starting on PIC32. I've got the USB starter kit, the I/O
expansion, and the fast Ethernet board. I've run the USB client serial
port adapter demo code. It works, and I can see how the high level code
works. When I copy stuff over to my own project and compile, it looks
like variables are not getting initialized. I remember C18 had 3  sets
of startup code. One zeroed variables, one left them unitialized, and
one initialized them. I don't see anything like that for C32. So, that's
where I am now. I'm also trying to get the Ethernet working using
parallel mode (mode 1, I think it is - 8 bit data, 15 address lines).
The documentation is a little thin. I'll keep working on it! And this
just after I'm getting comfortable with the PIC24H..

Now, tomorrow, I get to try generating some I2S audio with a PIC33.

Harold


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Barry Gershenfeld wrote:
> It is my fate to become involved with the PIC32 line.  Mostly because
> that's where the USB host functions are, and USB is some sort of
> unstoppable curse upon the land.

You need to get over the attitude problem if you want to get anywhere and if
you want others to take you seriously instead of dismissing you as a time
wasting whiner.

USB was well thought out and is very useful.  You're apparently not old
enough to remember the days of the serial port.  The baud rate, parity, and
port number all had to be right, and all too often this was pushed onto the
unsophisticated user that didn't know how to spell SIO.  Then devices had to
be separtely powered, and the practical upper limit on speed was under
12Kbytes/sec.  There were also different connector types to chose from, and
there wasn't even agreement on which end should be M or F.

The serial port is still great for getting simple communication between a PC
and a microcontroller working, but that's only for those of us comfortable
with computer electronics, software, and microcontrollers.  Even then, I
nowadays grab a ReadyBoard-02 for one off projects that need to talk to a
PC.  Since the software/firmware chain via USB is all set up already, it's
no harder than doing the same with serial but there are less logistic
hassles.  I don't have to worry about whether I've used up both serial ports
on my machine and most of the time the device doesn't need separate power.

> I ordered the PIC32 starter kit,
> and the USB starter kit, and now I must somehow rise to the
> competency level I have with my PIC16 and PIC18 parts.  This isn't
> really the right time to sit down with a cup of coffee and the
> PIC32MX Family Data Sheet

On the contrary, this is exactly the right time to read the datasheets.  You
get the most bang for the buck by reading the documentation *before* bumping
around in the dark wondering why nothing works.  Sitting down and reading
the datasheet may not be fun, but trying to debug something without the
proper understanding is a lot less fun and a lot more time consuming.

> Figure out
> how to install the USB connection to these eval boards--this time--
> (do I install the driver first, or do I plug in the device first?

Always install the driver first.  If try to jump ahead for instant
gratification and plug in the device first, the system may decide what
driver the device uses and install that.  It can be difficult to convince
the system later to accept a new driver, particularly if the new one is not
signed.

Read the documentation first, then try things one step at a time.  That way
when things stop working you know what little thing you did to cause it.  If
you are looking for instant gratification, go find something other than
microcontrollers to play with.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Dave Tweed]

Barry Gershenfeld wrote:
> It is my fate to become involved with the PIC32 line.

I've played around with PIC32 a little bit. I got a USB starter kit when
Microchip used the Circuit Cellar sample network to sort-of "beta test"
the kits (we were required to provide feedback on our experiences). I tried
some of the sample code, which worked, and then did a little project of my
own.

It quickly became apparent that you are expected to program these chips
ONLY in C, not assembly. Microchip provides no documentation on the
instruction set -- they refer you instead to the generic MIPS
documentation. And there's no documentation at all from any source that I
could find on the assembler syntax. I was in a bit of a hurry and didn't
want to try to work out the MIPS-specific stuff from the generic GNU
documentation.

Nonetheless, I was able to complete my project in C, and I'm looking
forward to doing more with this family some time down the road.

I actually created my own I/O breakout board that the starter kits can plug
into; it makes it really easy to take advantage of the massive amount of
GPIO on these chips. Among other things, I hope to use it to build some ATE
fixtures for a set of boards I've built for one of my clients. You can see
a picture of it here: http://www.dtweed.com/images/20090209-016m.jpg

The 2mm grid of holes is actually quite convenient for tacking down 0805
SMT passives and SOT-23 transistors. That's a row of 40 green SMT LEDs
across the bottom, with a laser-printed label taped beneath them. This
particular setup is used to measure the shutter latency and exposure time
on digital cameras. There's a little FET next to the screw terminal strip
on the right that triggers the camera, and then you can learn things about
the exposure by which LEDs are lit in the resulting image.

-- Dave Tweed
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[John Ferrell-5]

Please consider a Blog on the journey. I know it will generate more work but
the upside is that writing what you learn reinforces your understanding.

Some of us just cannot grasp what is neccessary without some tutoring!

John Ferrell  W8CCW

"Extremism in defense of liberty is no vice, and moderation in pursuit of
justice is no virtue."
-Barry Goldwater
"You don't get harmony when everybody sings the same note."
-Doug Floyd

----- Original Message -----
From: "Barry Gershenfeld" <gbarry42@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Friday, September 25, 2009 9:46 PM
Subject: [PIC] Diving into PIC32

> It is my fate to become involved with the PIC32 line.  Mostly because
> that's
> where the USB host functions are, and USB is some sort of unstoppable
> curse
> upon the land.  I ordered the PIC32 starter kit, and the USB starter kit,
> and now I must somehow rise to the competency level I have with my PIC16
> and
> PIC18 parts.  This isn't really the right time to sit down with a cup of
> coffee and the PIC32MX Family Data Sheet (646 pages) or maybe just the
> PIC32MX Family Reference Manual (1138 pages).  Better to get my feet wet
> and
> learn the landscape first.
>
> I've been a happy CCS user for 9 years and now I must learn the Microchip
> way of C.  CCS doesn't have a PIC32 compiler (yet?).  Also throw in an
> upgrade to some recent MPLAB for good measure. Figure out how to install
> the
> USB connection to these eval boards--this time-- (do I install the driver
> first, or do I plug in the device first?  The answer likes to change and
> it's hard to know if you've got the latest information--or even if it
> matters anymore).
>
> I'm looking for some connectedness with the 32-bit pioneers among us.  I
> will be looking at the Microchip forum, too, but somehow that just doesn't
> have the same feel as the good old PICList.  I've got a lot of experience
> under my belt, and I'd have to say about 50% of it came from reading the
> list.  So maybe I'll post a tidbit or two as I run across them.
>
> So here's my startle moment for the day.  The starter kit comes with a few
> sample programs. I spotted one, which was older, no longer used,
> apparently,
> but included nonetheless.  It's a 3-button 3-lamp "Simon" game.  So I
> brought that one up, and was poking around with the debugger. There's a
> switch() statement that looks at _gameState...kind of obvious what's going
> on there...but the switch statement only had like 2 cases.  So most of the
> time it would just do nothing there.  In the outer loop were statements to
> debounce the buttons, and then to set some flags based on the switches.
> The
> only other line is for that switch statement.  Where's the rest of the
> logic??  I went back to the source code and did some searching on
> variables
> and function names and in particular, all the enumerated states that
> _gameState could have.  And then I found the rest of the code.
>
> Inside the interrupt handler.
>
> Granted, there weren't any delay loops in there, although there's a lot of
> fiddling with the timer.  So I suppose the code executes OK and then gets
> out...but still...we just try not to do stuff like that.  I suppose they
> give projects like this to the new kids, and well, it works, doesn't it?
> (I'm not sure. One of the reasons for poking around is to figure out how
> the
> game is supposed to flow).
>
> Anyway, if I suddenly pop in with a question, this might provide some
> background.
>
> Barry
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[jim-142]

Dave,

Do you have any more of your custom I/O breakout boards?   If so, would you
consider selling me one?
Let me know the cost?


Thanks and Regards,

Jim



-----Original Message-----
From: piclist-bounces@... [mailto:piclist-bounces@...] On Behalf Of
Dave Tweed
Sent: Saturday, September 26, 2009 10:09 AM
To: piclist@...
Subject: Re: [PIC] Diving into PIC32

Barry Gershenfeld wrote:
> It is my fate to become involved with the PIC32 line.

I've played around with PIC32 a little bit. I got a USB starter kit when
Microchip used the Circuit Cellar sample network to sort-of "beta test"
the kits (we were required to provide feedback on our experiences). I tried
some of the sample code, which worked, and then did a little project of my
own.

It quickly became apparent that you are expected to program these chips
ONLY in C, not assembly. Microchip provides no documentation on the
instruction set -- they refer you instead to the generic MIPS
documentation. And there's no documentation at all from any source that I
could find on the assembler syntax. I was in a bit of a hurry and didn't
want to try to work out the MIPS-specific stuff from the generic GNU
documentation.

Nonetheless, I was able to complete my project in C, and I'm looking
forward to doing more with this family some time down the road.

I actually created my own I/O breakout board that the starter kits can plug
into; it makes it really easy to take advantage of the massive amount of
GPIO on these chips. Among other things, I hope to use it to build some ATE
fixtures for a set of boards I've built for one of my clients. You can see
a picture of it here: http://www.dtweed.com/images/20090209-016m.jpg

The 2mm grid of holes is actually quite convenient for tacking down 0805
SMT passives and SOT-23 transistors. That's a row of 40 green SMT LEDs
across the bottom, with a laser-printed label taped beneath them. This
particular setup is used to measure the shutter latency and exposure time
on digital cameras. There's a little FET next to the screw terminal strip
on the right that triggers the camera, and then you can learn things about
the exposure by which LEDs are lit in the resulting image.

-- Dave Tweed
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Barry Gershenfeld-2]

On Sat, Sep 26, 2009 at 6:41 AM, Olin Lathrop <olin_piclist@...>wrote:

> dismissing you as a time wasting whiner.
>

I was rather hoping to be accepted as a time wasting whiner.

 USB was well thought out and is very useful.


I got the same speech about PCI as an improvement over the ISA bus, making
the world truly plug-and-play.  I guess I saw that as a frill, since I could
configure hardware anyway.  Now, all of these claims do have their merits;
it's just overkill for something like connecting a keyboard.  There was also
that problem of Microsoft and others getting the drivers to work properly,
and twice in a row without rebooting.


> You're apparently not old enough to remember the days of the serial port.


I'd like to let you think that, but I suspect I'd tip my hand in short order
anyway.

 > This isn't

> > really the right time to sit down with a cup of coffee and the
> > PIC32MX Family Data Sheet
>
> On the contrary, this is exactly the right time to read the datasheets.
>  You
> get the most bang for the buck by reading the documentation *before*
> bumping
> around in the dark wondering why nothing works.  Sitting down and reading
> the datasheet may not be fun, but trying to debug something without the
> proper understanding is a lot less fun and a lot more time consuming.
>

You should appreciate that not everyone learns the same way.  I will often
work from the inside out.  So last week I was looking at the code, and I saw
calls for the timer.  So I decided to investigate that.  This brings me to
the 32-bit Peripheral Library Guide (324 pages--did I mention I also have to
learn a new compiler?) and I see the various timer functions.  So, now to
make sense of that I have to go to the datasheet (but do I want the part
datasheet or the family datasheet?) where I find that the hardware for the
timer hasn't changed radically, but then I think Microchip is designing the
peripherals, so they at least should look familiar. So, then, the drill...

 - Read the datasheet section on the timer
 - Return to the library documentation, where now their calls and parameters
should make more sense
 - Return to the program, where the use of the timer should make more sense.

In this way, I can grok the thing an item at a time as I encounter each
piece.


> > (do I install the driver first, or do I plug in the device first?
>
> Always install the driver first.


Well, that's my default approach, but in the past, they've put stickers over
the port saying, "No, install the driver first!" and clear instructions.
Now I suspect that's not so important anymore, but I was left guessing.  I
don't recall what the actual procedure was that got it going, but I know I
had to go around trying things a few times before I got a connect.

The downside, by the way, of running the installer first, is that sometimes
you want to install a printer, and you wind up with three photo editors and
a subscription to a picture posting web site in the process.  So if I can
have a device call for a driver, I prefer doing it that way.


> Read the documentation first, then try things one step at a time.  That way
> when things stop working you know what little thing you did to cause it.


A.k.a., "What did you touch last?"


>  If you are looking for instant gratification, go find something other than
> microcontrollers to play with.
>

Homebrew aircraft, perhaps? ;)
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Kevin-40]

Hi,

I use a home grown proto board (5V) with a PIC16F88
w/bootloader and a Max232 chip to load programs via the pc serial port.

I would like to communicate to a TI CC1101 chip via SPI. The
TI CC1101 radio chip has voltage range of 1.8V to 3.6V. Does
anybody have a simple level conversion circuit or a favorite
chip they use to convert the 5V to 3V and vice versus ?


Thanks,
Kevin
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Barry Gershenfeld wrote:
>> USB was well thought out and is very useful.
>
> I got the same speech about PCI as an improvement over the ISA bus,
> making
> the world truly plug-and-play.  I guess I saw that as a frill, since I
> could configure hardware anyway.

PCI was a significant improvement over ISA.  Even if you understood what I/O
address and IRQ settings were, it was still a hassle to make sure none of
your devices collided.  And then it wasn't about the .01% of the people that
understood what hardware configuration was anyway.  PCI and USB are about
making things easier for the 99.99% of computer users who don't understand
the magic behind things.  It's also about reducing support costs and making
computers accessible to ever increasing numbers of morons, who ultimately
drive the prices down and indirectly pay a lot of our salaries.

Even though I do understand much of the magic behind the curtain, I like PCI
and USB as apposed to ISA and RS-232.  Understanding how it works still
doesn't tell me which I/O address to assign or whether I need a half twist
or straight cable between this device and that, or having to dig out or make
the right adapter cable because one device used a male DB-9 and the other a
female DB-15.  Good riddance.

Both PCI and USB achieve the better moron-level experience by pushing
complexity onto developers, but it's really not that big a deal.  USB is
actually a pretty nice way to connect even simple home brew devices to a PC.
The extra stuff on the micro and host ends only needs to be developed once,
then it can be used for lots of different projects.  I tend to use USB now
even for one off projects where a few years ago I would have used RS-232.

> Now, all of these claims do have
> their merits; it's just overkill for something like connecting a
> keyboard.

Not really.  You seem to think of USB as high overhead just because it
appears complex.  There are now plenty of micros with USB hardware built in
and firmware freely available.  Allowing you to plug something in and having
it just work isn't overkill.  You certainly can't do that with old RS-232
keyboards.  The dedicated keyboard and mouse ports on desktop PCs do just
work too, but it doesn't make sense for PCs with built in keyboards and
pointing devices to have such ports.  It makes more sense for such PCs to
have more of the general USB ports that you can plug in a keyboard and mouse
in those cases where you want to use external devices, but allow the same
ports to be used for other things when you are willing to use the built in
devices.

>> On the contrary, this is exactly the right time to read the datasheets.
>>  You
>> get the most bang for the buck by reading the documentation *before*
>> bumping
>> around in the dark wondering why nothing works.  Sitting down and
>> reading the datasheet may not be fun, but trying to debug something
>> without the proper understanding is a lot less fun and a lot more time
>> consuming.
>
> You should appreciate that not everyone learns the same way.

That's a lame argument I've heard too often.  All the really good engineers
I know have the sit down and read the datasheet first mentality.  Some
people don't have the patience for that or lose interest without a bunch of
instant gratification steps along the way, but that doesn't make it a good
idea.  Those kinds of people may eventually be able to do something useful,
but it's a good early warning indicator that they'll never be really good
engineers.  I've seen this too often, and the correlation is quite strong.

You can learn most of something by poking at pieces.  That may work, even be
desirable, in some disciplines, but not for detail oriented disciplines like
designing circuits and or writing firmware.  The problem with that you don't
learn all the things that are possible.  You may learn that a timer can be
used a certain way, but when faced with a new problem you have to have in
your head all the ways the timer could be used.  Without that, you wouldn't
think of looking in the timer chapter and realize it is a good solution to
the new problem because you've never seen a example of it being used that
way before.

> I will often work from the inside out.

But that doesn't make it a good idea.  This is a statement about you, not
about the method.

> So last week I was looking at the
> code, and I saw calls for the timer.  So I decided to investigate that.
> This brings me to
> the 32-bit Peripheral Library Guide (324 pages--did I mention I also
> have to learn a new compiler?) and I see the various timer functions.
> So, now to
> make sense of that I have to go to the datasheet (but do I want the part
> datasheet or the family datasheet?) where I find that the hardware for
> the timer hasn't changed radically, but then I think Microchip is
> designing the peripherals, so they at least should look familiar. So,
> then, the drill...
>
> - Read the datasheet section on the timer
> - Return to the library documentation, where now their calls and
> parameters should make more sense
> - Return to the program, where the use of the timer should make more
> sense.

This makes my point.  If you had read the datasheet first, then looked at
the library and the code, things would make sense from the start.  More
importantly, you'd know what was possible regardless of what this particular
app did and the library chose to surface.  You'd probably even find the
libary is largely pointless for those that have read the datasheet and can
handle the 5 to 10 lines of code it takes to set up most peripherals.
Peripheral libraries are mostly to give the impression that microcontroller
programming is easier than it really is.

> In this way, I can grok the thing an item at a time as I encounter each
> piece.

Exactly.  You won't know about the pieces you didn't encounter.  That may
work for understanding someone else's design, but is no good for
synthesizing your own design for a new problem.

>>  If you are looking for instant gratification, go find something other
>> than microcontrollers to play with.
>
> Homebrew aircraft, perhaps? ;)

I'm not sure what this is reference too, but it's funny you should mention
that since one of my side projects is making a piece of foam core fly, or at
least glide initially.  I've got a CAN side project to get to a certain
point first, then hopefully I can get back to this one in a few weeks.

If you just dropped a piece of foam core it would flutter to the ground like
a leaf.  Even if you gave it a initial push along a glide path, it would
quickly go into flutter mode.  Basically I want to make a flying wing from a
sheet of foam core.

The first pass will do a controlled glide only, meaning it won't have a
engine.  It won't have a tail either.  Way too many people have done that,
so it would be a lot less fun.  I know flying wings have been done before
too, but a lot less so on the hobby level and it sounds like a much better
challenge with more room for innovation.

In theory it takes 3 degrees of freedom to control a aircraft.  With a
vertical tail, you only need three control surfaces to provide those three
degrees of freedom.  I don't know if it can be proven mathematically, but it
looks to me like it takes at least 4 control surfaces when everything is in
a single plane.

I have two control surfaces on the trailing edge of each side of the wing,
for a total of 4.  Pitch and roll are easy, but yaw is more complicated
since it has to be achieved via drag.  But using the control surface to
create drag on one side also introduces forces in the other dimensions,
which then need to be cancelled out with the additional control surfaces.
This will make the control algorithms interesting.

I've thought about the algorithms and think I know how to approach this, but
I'm sure there'll be surprises along the way.  I'll probably plunk down a
dsPIC with enough PWM modules to make driving the hobby servos easy to allow
me to concentrate on the control algorithm.  The extra electrical power for
the dsPIC should be small compared to that required by the servos anyway.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Kevin wrote:
> Does
> anybody have a simple level conversion circuit or a favorite
> chip they use to convert the 5V to 3V and vice versus ?

5V to 3V only requires two resistors.

A quick and easy solution for 3V to 5V, especially for hobby projects, is to
use a 74HCT gate (or any gate with TTL inputs) at 5V power.  Its input
threshold levels are guaranteed to interpret the 3V signals correctly, and
its output will be 5V logic.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Brendan Gillatt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin wrote:

> Hi,
>
> I use a home grown proto board (5V) with a PIC16F88
> w/bootloader and a Max232 chip to load programs via the pc serial port.
>
> I would like to communicate to a TI CC1101 chip via SPI. The
> TI CC1101 radio chip has voltage range of 1.8V to 3.6V. Does
> anybody have a simple level conversion circuit or a favorite
> chip they use to convert the 5V to 3V and vice versus ?
>
>
> Thanks,
> Kevin

The circuit in
http://www.nxp.com/acrobat_download/applicationnotes/AN97055.pdf
is what I normally use to convert between two voltage levels.

Many people will tell you that you can use a voltage divider for 5v -> 3v
and rely on the 5v logic's 2.5v threshold for 3v -> 5v conversion. This
may work but it is not bidirectional and sounds a bit iffy.

- --
Brendan Gillatt | GPG Key: 0xBF6A0D94
brendan {a} brendangillatt (dot) co (dot) uk
http://www.brendangillatt.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFKwh+uHEhZ5Ws5poERAmPfAKDGUrvFgQS+TUWUGZnX4XrTz2OCVQCcDg02
dMJlwed0LI91mZxbxgkguHI=
=hTVJ
-----END PGP SIGNATURE-----
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Harold Hallikainen-2]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevin wrote:
>> Hi,
>>
>> I use a home grown proto board (5V) with a PIC16F88
>> w/bootloader and a Max232 chip to load programs via the pc serial port.
>>
>> I would like to communicate to a TI CC1101 chip via SPI. The
>> TI CC1101 radio chip has voltage range of 1.8V to 3.6V. Does
>> anybody have a simple level conversion circuit or a favorite
>> chip they use to convert the 5V to 3V and vice versus ?
>>
>>
>> Thanks,
>> Kevin
>
> The circuit in
> http://www.nxp.com/acrobat_download/applicationnotes/AN97055.pdf
> is what I normally use to convert between two voltage levels.
>
> Many people will tell you that you can use a voltage divider for 5v -> 3v
> and rely on the 5v logic's 2.5v threshold for 3v -> 5v conversion. This
> may work but it is not bidirectional and sounds a bit iffy.
>

For 3.3V to 5V logic level conversion, I use some sort of 74HCT chip. The
T makes Vih low enough to accept 3.3V logic levels.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Brendan Gillatt wrote:
> Many people will tell you that you can use a voltage divider for 5v ->
> 3v and rely on the 5v logic's 2.5v threshold for 3v -> 5v conversion.
> This may work but it is not bidirectional and sounds a bit iffy.

I don't see anything iffy?  All specs are met without waving of dead fish.

There is a tradeoff between speed and current consumption with the resistor
divider, but that is no different than the tradeoff of what family gate to
use for the other direction.  My standard answer is 2K ohms in series
followed by 3.9K ohms to ground for 5.0V to 3.3V, but some cases may require
lower values.  2Kohms // 3.9Kohms = 1.3Kohms, * 100pF = 130nS, so that
should be good for up to 2MHz square wave considering 100pF is very high for
on-board traces.

Do you have any fact-based objection or is your comment just silly
superstition?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Andy Tuthill]

I have used the voltage divider option in the past to make a 5V pic talk to an Analog Devices DSP running at 3.3V.  We thought it might be iffy as well but found it worked well and avoided us needing to add another chip.  Having said that I tried to do the same with a Xilinx fpga and found it wouldn't work so it's not a perfect solution.

If you want to be certain and use a level converter start with your usual supplier (Digikey, Farnell, Newark, etc.) and see what they offer.  They can be a great place to find what's available for different functions.

Regards,
Andy

> Date: Mon, 28 Sep 2009 21:39:15 -0400
> From: kben@...
> To: piclist@...
> Subject: [PIC] PIC SPI level conversion
>
>
> Hi,
>
> I use a home grown proto board (5V) with a PIC16F88
> w/bootloader and a Max232 chip to load programs via the pc serial port.
>
> I would like to communicate to a TI CC1101 chip via SPI. The
> TI CC1101 radio chip has voltage range of 1.8V to 3.6V. Does
> anybody have a simple level conversion circuit or a favorite
> chip they use to convert the 5V to 3V and vice versus ?
>
>
> Thanks,
> Kevin
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

     
_________________________________________________________________
Microsoft brings you a new way to search the web.  Try  Bing™ now
http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try bing_1x1
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Marcel Duchamp]

I've been using this dual buffer for a while for 5V to 3V and vice versa:
SN74LVC2G07DCKR
DIGIKEY: 296-13495-1-ND


It's a dual non-inverting buffer with open drain outputs.  The supply
voltage sets the input thresholds while the pull up voltage sets the
output high voltage.

>>
>> I use a home grown proto board (5V) with a PIC16F88
>> w/bootloader and a Max232 chip to load programs via the pc serial port.
>>
>> I would like to communicate to a TI CC1101 chip via SPI. The
>> TI CC1101 radio chip has voltage range of 1.8V to 3.6V. Does
>> anybody have a simple level conversion circuit or a favorite
>> chip they use to convert the 5V to 3V and vice versus ?
>>
>>
>> Thanks,
>> Kevin

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Funny N.]

>Having said that I tried to do the same with a Xilinx fpga and found it wouldn't work so it's not a perfect solution.

Any idea what makes it not working with FPGA?

 Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: Andy Tuthill <azandy63@...>
To: piclist@...
Sent: Tuesday, September 29, 2009 3:28:54 PM
Subject: RE: [PIC] PIC SPI level conversion


I have used the voltage divider option in the past to make a 5V pic talk to an Analog Devices DSP running at 3.3V.  We thought it might be iffy as well but found it worked well and avoided us needing to add another chip.  Having said that I tried to do the same with a Xilinx fpga and found it wouldn't work so it's not a perfect solution.

If you want to be certain and use a level converter start with your usual supplier (Digikey, Farnell, Newark, etc.) and see what they offer.  They can be a great place to find what's available for different functions.

Regards,
Andy

> Date: Mon, 28 Sep 2009 21:39:15 -0400
> From: kben@...
> To: piclist@...
> Subject: [PIC] PIC SPI level conversion
>
>
> Hi,
>
> I use a home grown proto board (5V) with a PIC16F88
> w/bootloader and a Max232 chip to load programs via the pc serial port.
>
> I would like to communicate to a TI CC1101 chip via SPI. The
> TI CC1101 radio chip has voltage range of 1.8V to 3.6V. Does
> anybody have a simple level conversion circuit or a favorite
> chip they use to convert the 5V to 3V and vice versus ?
>
>
> Thanks,
> Kevin
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

                         
_________________________________________________________________
Microsoft brings you a new way to search the web.  Try  Bing™ now
http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try bing_1x1
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist



     
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Barry Gershenfeld-2]

On Sat, Sep 26, 2009 at 8:38 AM, John Ferrell <jferrell13@...>wrote:

> Please consider a Blog on the journey. I know it will generate more work
> but
> the upside is that writing what you learn reinforces your understanding.
>

Just answering an email usually has me visiting 3 or 4 sites for reference,
so I think maintaining a blog might just fill up my day.


> Some of us just cannot grasp what is neccessary without some tutoring!
>

The other problem with this idea is, that most things I take note of are
things I didn't know, or things that surprised me (so, "discoveries").  I
guess such notes would make it "part of this nutritious breakfast", but I
don't think it in itself would be a tutorial for anyone.

So be it, though.  It's the sort of thing I always hope for--instructions
for those who already have a good working knowledge of the field, but for
whom this part is new.

For now, I will try to post some notes as I go.  If it turns into a blog,
we'll let it go there.

Barry
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Blick-4]

Olin Lathrop wrote:

>> You should appreciate that not everyone learns the same way.
>
> That's a lame argument I've heard too often.  All the really good engineers
> I know have the sit down and read the datasheet first mentality.  Some
> people don't have the patience for that or lose interest without a bunch of
> instant gratification steps along the way, but that doesn't make it a good
> idea.  Those kinds of people may eventually be able to do something useful,
> but it's a good early warning indicator that they'll never be really good
> engineers.  I've seen this too often, and the correlation is quite strong.

Those people you are trashing may be your boss someday. Unless they read
your emails first :)

I think you are waving a dead fish. Your perspective is merely your
perspective, sometimes objective, sometimes not.

Needless to say, you have turned this into another one of your "what
makes a good engineer" threads and it doesn't belong under the [PIC]
topic tag.

Cheerful regards,

Bob
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Álvaro Deibe Díaz-2]

Olin Lathrop wote:

... I'll probably plunk down a dsPIC with enough PWM modules to make driving
the hobby servos easy to allow me to concentrate on the control algorithm.
The
extra electrical power for the dsPIC should be small compared to that
required
by the servos anyway...


You only need a basic hardware PWM to generate your 4 servo outputs. Five
resistors and a little ISR will do. Easy to get 250ns from a 8MHz clock from
the hardware PWM, without glitches, although deadbands of 2-4us are usual in
the middle-priced servos, so usually there is no need to go beyond 1us of
resolution in the PWM's.

Split ailerons (split "ailevators", in this case) (or whatever the right
name
is in english) are usual to control fin-less flying wings (Northrop YB-49,
i.e.). If you keep the numbers in the integer field, I think it will
comfortably fit inside a PIC18.

(Perhaps) interesting links:
René Arnoux "Stabloplane", "Stablavion" and family:
   http://www.ctie.monash.edu.au/hargrave/arnoux.html
Alexander Martin Lippisch flying wings and deltas:
   http://www.ctie.monash.edu.au/hargrave/lippisch.html
Horten brothers flying wings:
   http://en.wikipedia.org/wiki/Horten_brothers
Northrop wings:
   (I think you don't need points to them... :o)

Regards.



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

"Álvaro Deibe Díaz" wrote:
> You only need a basic hardware PWM to generate your 4 servo outputs.
> Five resistors and a little ISR will do. Easy to get 250ns from a 8MHz
> clock from the hardware PWM, without glitches, although deadbands of
> 2-4us are usual in the middle-priced servos, so usually there is no
> need to go beyond 1us of resolution in the PWM's.

I agree there are various ways the hardware could be minimized, especially
with more responsibility pushed onto the firmware.  Those would actually
matter if this were a production product.  However, it's a one-off design,
and largely a research test bed at that.

I am finishing up another side project now, and haven't really thought about
the electronics for the flying sheet yet.  I want to use a dsPIC because I
have no idea how compute intensive the control algorithm may end up.  Most
likely a 18F could do it, but I want to have room just in case I want to try
something complicated.  With a dsPIC running at 30 MIPS, I'm pretty sure CPU
power isn't going to be a problem.

Since quite a few dsPICs have lots of PWM modules, dedicating one to each
servo is the immediately obvious thing to do.  Another simple approach is to
externally multiplex the output of a single PWM module and run the servo
pulses in sequentially.  If that reduces overall weight I may do it.

> Split ailerons (split "ailevators", in this case) (or whatever the right
> name
> is in english) are usual to control fin-less flying wings (Northrop
> YB-49, i.e.).

If I remember right, the Northrop flying wing and the B-2 split the
"ailevators" such that they have two surfaces, one directly above the other.
That means you can use them both together to create drag without any net up
or down force.

Having two control surfaces above each other would be too mechanically
complicated for what I'm doing, so I have them next to each other.  The
drawback is that when you activate both in opposite directions you get a net
torque applied in the roll axis.  This then needs to be cancelled by the
surfaces on the other side of the wing, but with less drag else you haven't
achieved control over yaw.  This part I have thought about in my head and I
believe it is possible to do, just that the math gets a little more
complicated.  In other words, I'm deliberately making this mechanically
simple and making up the difference in the math.  I really think it's
doable, but either way, it will be fun to try.

> If you keep the numbers in the integer field, I think it
> will comfortably fit inside a PIC18.

It probably would, and that would be a appropriate thing to look at if this
were a real product.  But it isn't, so I won't.  I'll most likely use all
floating point on a dsPIC.  I'm interested in the control algorithms and
don't want CPU power or numeric problems getting in the way, even for trying
things lots more complicated than may ultimately be necessary.

> (Perhaps) interesting links:

No!  I know flying wings exist, but the fun part is breaking new ground,
even if it's just new ground for me.  I don't know if others have solved
exactly the same problem (same arrangement of control surfaces) as I'm
trying to solve, but if they have I don't know about it and certainly don't
know of their solutions.  And I want to keep it that way until I've come up
with my own solution.

This is for two reasons.  First, inventing the solution is the fun part.
Otherwise I'd be just a dumb monkey building a model, and there's not fun in
that, at least for me.  Second, it's a lot easier to think outside the box
if you've never looked inside.  Right now I have the advantage of not
knowing the "right" way to do this.  All too often conventional wisdom gets
stuck in a rut about how something should be done.  If I don't know what
that rut is, I can't get stuck in it.

After I've got my flying sheet working, then it will be interesting to see
how others did it and how my approach differed.  When I've got mine working,
I'll obviously have found a right way too.  Maybe I'll converge on their
right way after a lot of trial and error, but maybe I'll come up with
something a little different too.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist