Searching \ for '[PIC] Bit-banging in C' 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/languages.htm?key=c
Search entire site for: 'Bit-banging in C'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Bit-banging in C'
2010\09\12@111801 by PICdude

flavicon
face
I'm finally going to start really using a higher (than 8-bit) PIC and  also looking into Atmels and C instead of assembly (for the PIC too).   Since there will be optimizations, how would timing-specific code  (such as bit-banging) be done?  Are these pieces put into inline  assembly, or is there a way to use C code with known timing?

Cheers,
-Neil.

2010\09\12@124018 by Tamas Rudnai

face picon face
It depends on your needs but generally speaking you need to use a timer
module that tells you the exact timing you need. In other words you should
not depend on the instruction cycles, and all you need is to make sure you
can done the bit banging before the next tick comes... You can do this by
interrupts or by polling the timer register, depending again what are the
specifications and if the service routing can handle the demand (ISR could
have a bigger overhead with all the context savings and such stuff than a
polling...).

Tamas




On Sun, Sep 12, 2010 at 4:18 PM, PICdude <spam_OUTpicdude3TakeThisOuTspamnarwani.org> wrote:

> I'm finally going to start really using a higher (than 8-bit) PIC and
> also looking into Atmels and C instead of assembly (for the PIC too).
> Since there will be optimizations, how would timing-specific code
> (such as bit-banging) be done?  Are these pieces put into inline
> assembly, or is there a way to use C code with known timing?
>
> Cheers,
> -Neil.
>
>
>

2010\09\12@154032 by Isaac Marino Bavaresco

flavicon
face
Em 12/9/2010 12:18, PICdude escreveu:
> I'm finally going to start really using a higher (than 8-bit) PIC and  
> also looking into Atmels and C instead of assembly (for the PIC too).  
> Since there will be optimizations, how would timing-specific code  
> (such as bit-banging) be done?  Are these pieces put into inline  
> assembly, or is there a way to use C code with known timing?
>
> Cheers,
> -Neil.

Inline assembly is one option. Another would be to write the routines in
an all-assembly module with the correct structure to be called from C.

Don't forget that higher-end processors use caches, DMA, dynamic RAM and
several other things that may interfere with the code execution speed.
So their timing may be much less deterministic than a PIC.


Best regards,

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com

2010\09\12@173732 by M.L.

flavicon
face

On Sun, Sep 12, 2010 at 11:18 AM, PICdude <.....picdude3KILLspamspam@spam@narwani.org> wrote:
> I'm finally going to start really using a higher (than 8-bit) PIC and
> also looking into Atmels and C instead of assembly (for the PIC too).
> Since there will be optimizations, how would timing-specific code
> (such as bit-banging) be done?  Are these pieces put into inline
> assembly, or is there a way to use C code with known timing?
>
> Cheers,
> -Neil.
>

Neil,
It's generally pretty simple to call assembly subroutines from C and
vice versa. Your compiler should have a straight-forward document that
describes calling conventions. The Microchip C30 compiler has a good
document for this:
http://ww1.microchip.com/downloads/en/DeviceDoc/C30_Users_Guide_51284f.pdf

Anything other than assembly is impossible to know exact timing. I
can't speak for any Atmel compilers but I know that I really like
working with the dsPIC/PIC24 architecture. The C30 compiler does a
good job and these parts seem to be well engineered.

-
Martin K.

2010\09\13@024217 by PICdude

flavicon
face
Quoting Tamas Rudnai <tamas.rudnaispamKILLspamgmail.com>:

> It depends on your needs but generally speaking you need to use a timer
> module that tells you the exact timing you need. In other words you should
> not depend on the instruction cycles, and all you need is to make sure you
> can done the bit banging before the next tick comes... You can do this by
> interrupts or by polling the timer register, depending again what are the
> specifications and if the service routing can handle the demand (ISR could
> have a bigger overhead with all the context savings and such stuff than a
> polling...).
>
> Tamas


Ugh -- actually sounds like an overhead nightmare with either option.   Not the answer I wanted to hear.  I was expecting some way to switch  off optimizations perhaps, and a way (such as a profiler) to figure  out how many instructions or clock-cycles a particular code sequence  takes.  Perhaps the C-compilers (which I haven't used yet) would allow  me access to the intermediate assembler code when it compiles it, as  from that I could possibly make a better determination of which is the  best way to handle certain timing-specific tasks.

Thanks,
-Neil.


2010\09\13@024348 by PICdude

flavicon
face
Quoting Isaac Marino Bavaresco <.....isaacbavarescoKILLspamspam.....yahoo.com.br>:

> Inline assembly is one option. Another would be to write the routines in
> an all-assembly module with the correct structure to be called from C.

This sounds better now.

> Don't forget that higher-end processors use caches, DMA, dynamic RAM and
> several other things that may interfere with the code execution speed.
> So their timing may be much less deterministic than a PIC.

Forget?  I still don't know about them (yet).  I guess I'll be finding  out soon though.

Cheers,
-Neil.

2010\09\13@024906 by PICdude

flavicon
face
Quoting "M.L." <EraseMEmspam_OUTspamTakeThisOuTlkeng.net>:

> Neil,
> It's generally pretty simple to call assembly subroutines from C and
> vice versa. Your compiler should have a straight-forward document that
> describes calling conventions. The Microchip C30 compiler has a good
> document for this:
> http://ww1.microchip.com/downloads/en/DeviceDoc/C30_Users_Guide_51284f.pdf

<significant sarcasm>Yet another few hundred pages for me to read in  my ample spare time</significant sarcasm>.  But I guess I have to  sometime soon.


> Anything other than assembly is impossible to know exact timing. I
> can't speak for any Atmel compilers but I know that I really like
> working with the dsPIC/PIC24 architecture. The C30 compiler does a
> good job and these parts seem to be well engineered.

Maybe not impossible, but most probably not practical.

Thanks,
-Neil.

2010\09\13@025515 by Jan-Erik Soderholm

face picon face


On 2010-09-13 08:42, PICdude wrote:
> Quoting Tamas Rudnai<tamas.rudnaispamspam_OUTgmail.com>:
>
>> It depends on your needs but generally speaking you need to use a timer
>> module that tells you the exact timing you need. In other words you should
>> not depend on the instruction cycles, and all you need is to make sure you
>> can done the bit banging before the next tick comes... You can do this by
>> interrupts or by polling the timer register, depending again what are the
>> specifications and if the service routing can handle the demand (ISR could
>> have a bigger overhead with all the context savings and such stuff than a
>> polling...).
>>
>> Tamas
>
>
> Ugh -- actually sounds like an overhead nightmare with either option.
> Not the answer I wanted to hear.

What has *that* to do with anything ?
Why ask in the first place if you only accepted some answers ?
And you have gor the right answers so far, as far as I have seen.

> I was expecting some way to switch
> off optimizations perhaps, and a way (such as a profiler) to figure
> out how many instructions or clock-cycles a particular code sequence
> takes.

Yes, for that particular piece of code. A minor adjustment could
make it produce quite different code. And always running without
optimizations could get you more deterministic code but also
probably worse code in general then otherwise.

> Perhaps the C-compilers (which I haven't used yet) would allow
> me access to the intermediate assembler code when it compiles it,...

Of course. I have never seen a compiler (on any kind of "computer")
that doesn't produce an assembly or machine code listing.

> as
> from that I could possibly make a better determination of which is the
> best way to handle certain timing-specific tasks.
>
> Thanks,
> -Neil.
>
>
>

2010\09\13@064408 by Robin Abbott

flavicon
face
Well firstly, most higher level languages directed to the PIC will have
library routines which will handle bit banging where hardware is
unavailable. The second source would be the current user community who may
well have developed library routines to undertake your function.

If it's timing critical and nothing's available you'll have to write in
assembler in whatever form the compiler accepts. Even with all optimizations
turned off calculating delay routines in a high level language is a
nightmare.

Finally you could ask your compiler supplier - if sufficient interest exists
they may add it for you !

Regards,

Robin Abbott
Forest Electronics
The home of WIZ-C ANSI C RAD development for the PIC !
http://www.fored.co.uk
07801 718136 (+44-7801-718136)


{Original Message removed}

2010\09\13@065612 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: @spam@piclist-bouncesKILLspamspammit.edu [KILLspampiclist-bouncesKILLspamspammit.edu] On
Behalf
{Quote hidden}

timer
> >> module that tells you the exact timing you need. In other words you
> should
> >> not depend on the instruction cycles, and all you need is to make
sure
> you
> >> can done the bit banging before the next tick comes... You can do
this
> by
> >> interrupts or by polling the timer register, depending again what
are
> the
> >> specifications and if the service routing can handle the demand
(ISR
> could
> >> have a bigger overhead with all the context savings and such stuff
than
> a
> >> polling...).
> >>
> >> Tamas
> >
> >
> > Ugh -- actually sounds like an overhead nightmare with either
option.
{Quote hidden}

And a compiler update could change code generation and screw up your
timing!

If you are using a grown up MPU, then get the one with the peripherals
you need to avoid bit bashing if possible (unless you are trying to
shave 1/10ths of a penny off product cost).  If not then you probably
have enough CPU horsepower to handle most stuff within interrupts.


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.
=======================================================================

2010\09\13@072701 by Olin Lathrop

face picon face
PICdude wrote:
> I'm finally going to start really using a higher (than 8-bit) PIC and
> also looking into Atmels and C instead of assembly (for the PIC too).
> Since there will be optimizations, how would timing-specific code
> (such as bit-banging) be done?  Are these pieces put into inline
> assembly, or is there a way to use C code with known timing?

High level languages have no guarantee exactly what instructions will be
used and therefore what the timing will be.  Often you can guess and get it
right, but that's bad programming.

If you need instruction-level known timing, write it in assembler.  That can
be either inline assembly or subroutines in a seperate assembly module.  I
really don't understand the reluctance to use assembly when required.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\09\13@082403 by Walter Banks

picon face


PICdude wrote:
>
> I'm finally going to start really using a higher (than 8-bit)
> PIC and also looking into Atmels and C instead of assembly
> (for the PIC too).  Since there will be optimizations, how
> would timing-specific code (such as bit-banging) be done?  
> Are these pieces put into inline assembly, or is there a
> way to use C code with known timing?

Most of the timing specific code in the larger processors is done using timers or event driven code. This can be done
in C (including most PIC's)in most cases reducing or eliminating the need for instruction specific timing.

http://bytecraft.com/downloads/Exceptional%20Programming.pdf

http://bytecraft.com/event_driven_sine_wave_generation

Inline assembly is one way but there are alternative implementation that overall may be just as effective.
Think for example the difference between instruction timing and the use of a single bit timer for serial ports.
Implementation code is similar in size but minor application changes and processor load becomes part of a code maintenance nightmare.

Regards,


w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.co

2010\09\13@084554 by Michael Watterson

face picon face
 On 13/09/2010 13:25, Walter Banks wrote:
>
> Think for example the difference between instruction timing
> and the use of a single bit timer for serial ports.
> Implementation code is similar in size but minor application
> changes and processor load becomes part of a code maintenance
> nightmare.

And on x86 / x64 it can be simpler and cheaper to add a USB port PIC18F2550 and do the bit banging on it.

The PIC is deterministic.

A PC running most OS is not "real time". With all the Intel/AMD go faster tricks it's probably impossible even in assembler on x86/x64 to calculate execution time.
While not impossible, it's easier to do bit bang I2C, ICSP or RDS capture reliably on a PIC than on PC, even if using C or JAL on the PIC using "bit banging

2010\09\13@084853 by Olin Lathrop

face picon face
PICdude wrote:
> <significant sarcasm>Yet another few hundred pages for me to read in
> my ample spare time</significant sarcasm>.

Grow up already and get over it, or find something else to do that doesn't
require knowing anything.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\09\13@092635 by PICdude

flavicon
face
Quoting Jan-Erik Soderholm <spamBeGonejan-erik.soderholmspamBeGonespamtelia.com>:

> What has *that* to do with anything ?

Everything actually.


> Why ask in the first place if you only accepted some answers ?

Because on this first response, the only suggested answer was the one  that would make it very difficult to do what I'd need to.  Later  responses suggested that it really is possible to inline assembly.   I'm guessing you misintrepreted something here.

Cheers,
-Neil.

2010\09\13@093508 by PICdude

flavicon
face
Quoting Michael Rigby-Jones <TakeThisOuTMichael.Rigby-JonesEraseMEspamspam_OUToclaro.com>:

> If you are using a grown up MPU, then get the one with the peripherals
> you need to avoid bit bashing if possible (unless you are trying to
> shave 1/10ths of a penny off product cost).  If not then you probably
> have enough CPU horsepower to handle most stuff within interrupts.

On this one intended application, I'll most probably have several  channels of non-standard serial data, hence the need to bit-bang.  The  pennies aren't really a concern on this one, but I'd like to avoid  having several peripheral chips doing the comms and then feeding to  one bigger processor.

Cheers,
-Neil.

2010\09\13@095630 by PICdude

flavicon
face
Quoting Olin Lathrop <RemoveMEolin_piclistspamTakeThisOuTembedinc.com>:

> ...
> really don't understand the reluctance to use assembly when required.

Not a reluctance, but a consideration (and hence investigation) to try  C instead, yet be able to handle some low-level comms.  The thought of  C came up because I'd need to do a considerable amount of  floating-point math, and I'm also considering Atmel chips (which  really touts C as being able to do everything).

I'm now reminded of eevblog where he discussed assembly-language  programmers. :)

Cheers,
-Neil.

2010\09\13@101230 by Jan-Erik Soderholm

face picon face


On 2010-09-13 15:26, PICdude wrote:
> Quoting Jan-Erik Soderholm<jan-erik.soderholmEraseMEspam.....telia.com>:
>
>> What has *that* to do with anything ?
>
> Everything actually.
>
>
>> Why ask in the first place if you only accepted some answers ?
>
> Because on this first response,

When I wrote my reply, that you are commenting above, you had got
several responses that you seems to have been missed. They wasn't
"later", I had them in my inbox at the time I wrote my reply and
so had you also probably.

Jan-Erik

2010\09\13@101751 by Olin Lathrop

face picon face
PICdude wrote:
> Not a reluctance, but a consideration (and hence investigation) to try
> C instead, yet be able to handle some low-level comms.  The thought of
> C came up because I'd need to do a considerable amount of
> floating-point math, and I'm also considering Atmel chips (which
> really touts C as being able to do everything).

Don't believe everything "touted".

It sounds like from another post the real issues is doing several
asynchronous serial in/out.  Asynch serial out is pretty easy as you can
control when each byte starts.  Receiving asynch is a lot harder since you
have to capture the leading edge of the start bit to a fraction of a bit
time.  If you know both ends are using the same baud rate down to crystal
accuracy, then you can get away with about 1/4 bit time slop measuring the
time of the start bit leading edge.

How many asynchronous serial channels do you need, what baud rate, and how
much baud rate error do you expect between ends?  If the baud rate is slow
enough, then multiple channels can be handled with a 4x, 8x, or even more
interrupt per bit time.  The timing is then done by a timer and the
individual instruction execution times aren't critical.  You could do this
with compiled code, but this is a critical routine that has a chance of
using a lot of CPU, so carefully written assembly might still be the way to
go just for efficiency.

Let's pick a few parameters and see where we're at.  Let's say you're using
a 33F running at its max rate of 40 MIPS, and you want asynch serial in and
out at 9600 baud.  Let's say the other end is crystal controlled and it's
baud rate is "exact" within crystal tollerance.  That means you could get
away with a interrupt rate of 4 x 9600 = 38.4KHz, which leaves 1042
instruction cycles per interrupt.  I expect servicing 8 channels would
require a few 100 cycles, so that sounds within the doable range.  But you
don't want those 200 cycles blowing up into 400 due to the compiler if you
need a lot of CPU for the foreground code.  If the other end can't be
counted on to be exactly (for practical purposes) 9600 baud, then you
probably need a 8x baud interrupt for 521 instructions per interrupt.  Now
the difference between carefully written assembly and compiled code could
make a significant difference in the effective CPU speed seen by the
foreground code.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\09\13@101850 by Jan-Erik Soderholm

face picon face


On 2010-09-13 15:56, PICdude wrote:
> Quoting Olin Lathrop<EraseMEolin_piclistspamembedinc.com>:
>
>> ...
>> really don't understand the reluctance to use assembly when required.
>
> Not a reluctance, but a consideration (and hence investigation) to try
> C instead, yet be able to handle some low-level comms.  The thought of
> C came up because I'd need to do a considerable amount of
> floating-point math,

There is nothing stopping you from having complex float calculations
and also having some called or in-line ASM for time critical stuff
at the same time in the same application. If you have control over
when to run the float calcs and when to run the bit-bang, there
might be some trouble if they need to be done at the same time.


> and I'm also considering Atmel chips (which
> really touts C as being able to do everything).
>

There isn't any (significant) differense between AVR and PIC
in that area. As far as I know, the same inline ASM or
called ASM routines are available on both.

2010\09\13@102655 by Herbert Graf

picon face
On Sun, 2010-09-12 at 23:43 -0700, PICdude wrote:
> > Don't forget that higher-end processors use caches, DMA, dynamic RAM and
> > several other things that may interfere with the code execution speed.
> > So their timing may be much less deterministic than a PIC.
>
> Forget?  I still don't know about them (yet).  I guess I'll be finding  
> out soon though.

I'm going to be frank: don't bother trying.

Higher end chips are NOT meant for this sort of thing, and have ALL
kinds of design decisions that make deterministic timing very unlikely
to ever be reliable.

Even if you were to turn off every cache and every optimization I'm sure
there is SOMETHING that will trip up timing every once in a while
(access to RAM comes to mind).

And remember, if you're turning off every cache and every optimization
you've kinda blown the point of moving to a "higher" part.

If you need really tricky timing either use a peripheral feature
(sometime like a timer) or use a second chip meant for the purpose at
hand (small PIC or CPLD).

TTYL

2010\09\13@102751 by Mike Harrison

flavicon
face
On Mon, 13 Sep 2010 06:56:29 -0700, you wrote:

>Quoting Olin Lathrop <RemoveMEolin_piclistEraseMEspamEraseMEembedinc.com>:
>
>> ...
>> really don't understand the reluctance to use assembly when required.
>
>Not a reluctance, but a consideration (and hence investigation) to try  
>C instead, yet be able to handle some low-level comms.  The thought of  
>C came up because I'd need to do a considerable amount of  
>floating-point math, and I'm also considering Atmel chips (which  
>really touts C as being able to do everything).
>
>I'm now reminded of eevblog where he discussed assembly-language  
>programmers. :)
>
>Cheers,
>-Neil.

In practice, once you get used to a compiler, you can write fiddly code and have a pretty good idea
what code it's going to generate. You can always look at the generated code to check it's doing what
you think it should.

Inline assembler or seperate assembler modules are also not a problem to do, however you may have
some constrints imposed by the way the compiler uses memory or registers. Most MCU compilers'
documentation gives a reasonable amount of info on the constraints, calling conventions  etc. when
mixing C and assembler.

An issue that can be problematic to work round is where you have a very time-critical interrupt
routine and the compiler insists on doing more context-save than is necessary, so in this case you
may start having to fiddle with the standard startup/linker files and have assembler- only interrupt
routines.
Looking at a compiler's assembler output will tell you a lot about how it likes to do things, and
alert you to possible pitfalls.

2010\09\13@103750 by Tamas Rudnai

face picon face
On Mon, Sep 13, 2010 at 2:26 PM, PICdude <RemoveMEpicdude3spam_OUTspamKILLspamnarwani.org> wrote:

> Because on this first response, the only suggested answer was the one
> that would make it very difficult to do what I'd need to.  Later
> responses suggested that it really is possible to inline assembly.
> I'm guessing you misintrepreted something here.
>

Not necessarily difficult. Many HLL has a library that already does few
different protocols for you already by software. Like I2C, SPI
and Asynchron Serial typically. Sometimes you will find these as 'software
modules'. Some Atmel lib also do USB bitbanging -- I would not say the best
thing to do but in some circumstances they work as expected. You  only need
to calculate with the CPU power or other resources those routines required
but you do not need to reinvent the wheel if you are lucky enough to use one
of these protocols.

Tamas





>
> Cheers,
> -Neil.
>
>
>

2010\09\13@104640 by Michael Watterson

face picon face
Herbert Graf wrote:
{Quote hidden}

Atmel is a sideways move unless you going from PIC16 to ARM.

IF going to ARM there are better choices than Atmel if you need performance or specialist SoC (Samsung, Texas, ADI, Qualcom, National, Philips).
If an 18F isn't "enough" you might want a high end ARM Cortex A series with Linux and a $1.20 PIC16 or PIC18 as a peripheral interface controller. :-)

The only value of x86/x64 is to run Windows.

2010\09\13@111937 by PICdude

flavicon
face
Quoting Olin Lathrop <RemoveMEolin_piclistTakeThisOuTspamspamembedinc.com>:

> Grow up already and get over it, or find something else to do that doesn't
> require knowing anything.


Oh brother, someone got up on the wrong side of the bed again today.

2010\09\13@112656 by Mark Rages

face picon face
On Mon, Sep 13, 2010 at 9:27 AM, Mike Harrison <EraseMEmikespamspamspamBeGonewhitewing.co.uk> wrote:
{Quote hidden}

I suggest the OP take the compiler's assembly output and use it as the
starting point for his inline assembly.

Regards,
Mark
markrages@gmail
-- Mark Rages, Engineer
Midwest Telecine LLC
markragesSTOPspamspamspam_OUTmidwesttelecine.com

2010\09\13@113413 by PICdude

flavicon
face
Quoting Herbert Graf <spamBeGonehkgrafSTOPspamspamEraseMEgmail.com>:

> ...
> If you need really tricky timing either use a peripheral feature
> (sometime like a timer) or use a second chip meant for the purpose at
> hand (small PIC or CPLD).
>

This is a very possible option still -- to use one of more small PICs  with assembly to handle the comms, then I2C that with the bigger chip  doing the math in C.

Cheers,
-Neil.

2010\09\13@114239 by PICdude

flavicon
face
Quoting Tamas Rudnai <KILLspamtamas.rudnaispamBeGonespamgmail.com>:

> Not necessarily difficult. Many HLL has a library that already does few
> different protocols for you already by software. Like I2C, SPI
> and Asynchron Serial typically. Sometimes you will find these as 'software
> modules'. Some Atmel lib also do USB bitbanging -- I would not say the best
> thing to do but in some circumstances they work as expected. You  only need
> to calculate with the CPU power or other resources those routines required
> but you do not need to reinvent the wheel if you are lucky enough to use one
> of these protocols.
>
> Tamas
>

In my case, the protocol(s) may not be common or even proprietary.   But knowing that inline assembly is a standard capability of C  compilers on processor this size is enough to know that I can work  around the optimization or unknown-timing issue.

Cheers,
-Neil.

2010\09\13@164727 by Gerhard Fiedler

picon face
PICdude wrote:

> Quoting "M.L." <EraseMEmspamEraseMElkeng.net>:
>
>> Neil,
>> It's generally pretty simple to call assembly subroutines from C and
>> vice versa. Your compiler should have a straight-forward document that
>> describes calling conventions. The Microchip C30 compiler has a good
>> document for this:
>> ww1.microchip.com/downloads/en/DeviceDoc/C30_Users_Guide_51284f.pdf
>
> <significant sarcasm>Yet another few hundred pages for me to read in  
> my ample spare time</significant sarcasm>.  But I guess I have to  
> sometime soon.

An easy way to get started is to write a C function that has the
signature (argument number and type, return type) you need with some
code that does (maybe approximately) what you want to do, then look at
the assembly listing. It should show you how the arguments are passed in
and how the result is passed out. (Both is very specific to a given
compiler.)
The assembly listing generated by the compiler gives you a framework.
Now you can add your assembly as inline assembly, or you can use
whatever the compiler generated and put it as inline assembly.

Gerhar

2010\09\13@200320 by M.L.

flavicon
face

On Mon, Sep 13, 2010 at 4:47 PM, Gerhard Fiedler
<@spam@lists@spam@spamspam_OUTconnectionbrazil.com> wrote:
>> <significant sarcasm>Yet another few hundred pages for me to read in
>> my ample spare time</significant sarcasm>.  But I guess I have to
>> sometime soon.
>
> An easy way to get started is to write a C function that has the
> signature (argument number and type, return type) you need with some
> code that does (maybe approximately) what you want to do, then look at
> the assembly listing. It should show you how the arguments are passed in
> and how the result is passed out. (Both is very specific to a given
> compiler.)
>
> The assembly listing generated by the compiler gives you a framework.
> Now you can add your assembly as inline assembly, or you can use
> whatever the compiler generated and put it as inline assembly.
>
> Gerhard

You can certainly do this, but you might spend more time deducing the
logic than reading the documentation.
The PDF I listed has only about 15 pages about calling conventions. It
really only takes a few minutes to skim.

--
Martin K.

2010\09\14@075748 by RussellMc

face picon face
> If you are using a grown up MPU, then get the one with the peripherals
> you need to avoid bit bashing if possible (unless you are trying to
> shave 1/10ths of a penny off product cost).  If not then you probably
> have enough CPU horsepower to handle most stuff within interrupts.

Given the  comments on multiple  non standard and/or proprietary
interfaces, perhaps a "Propellor" may be a good choice?

                  http://www.parallax.com/propeller/
                  http://en.wikipedia.org/wiki/Parallax_Propeller

(Ducks ...  :-) )



     R

2010\09\14@161004 by James Newton

face picon face
Prop Rocks

And the basis of the prop and the SX before it (sad to see it go) was that
if you run fast enough, with deterministic timing, you can make everything
in software that you could in hardware. And you can: http://www.sxlist.com/techref/ubicom/virtperf.htm

And in many cases, it's much less expensive and requires less power. http://www.sxlist.com/techref/ubicom/power.htm
And can be much less complex. I'm working on MSP430's now which have
hardware peripherals which are so complex to configure that I swear I could
do a better job bit banging. In at least one case, the I2C interface had to
be bit banged because the timing of the built in peripheral, although to
standard, would not work with the chips we were talking at.

The other advantage of bit banging is code reuse. I took the I2C code that I
had used on the SX and translated it to the MSP430. If that had been written
in C, it would have been even easier to do.
Having a handy library of C code for IO, especially synchronous stuff like
LCD, I2C, SPI, and on top of that EEPROM, ADC, DAC, etc... protocols, and so
on can be a very good investment. Even async like RS232 can be "mostly"
managed in C with a bit of assembly or hardware diddling at the bottom to
shift out the bits at a steady rate.

Peripherals are overrated. Each one has a different errata, weird problems,
lack of availability, and proprietary setup.
There is /some/ C code for io at:
http://www.piclist.com/techref/microchip/language/c/ios.htm
I would love to have more.

--
James Newton
1-970-462-7764
{Original Message removed}

2010\09\14@182533 by William \Chops\ Westfield

face picon face

On Sep 14, 2010, at 1:10 PM, James Newton wrote:

> In at least one case, the I2C interface had to be bit banged

I don't think that anyone has pointed out yet that few "bit-banged"  protocols actually rely on counting instruction cycles to get accurate  timing any more, and that this becomes increasingly true as cpu clock  rates go up and get less deterministic.  Most bit-banged code ends up  looking like:
   set_bit x,y
   delay_us(midsized_number);
   set_but x,z
   delay_us(midsized_number);
Sometimes the midsized number is big enough that timer isrs can be  used for the delays, and other times they are "as fast as possible",  but in either case the code will work equally well in C...

IIRC, the SX/Ubicom chips were very big on being able to service a  timer interrupt fast enough to use for quite-speed serial protocols...

BillW

2010\09\16@084236 by PICdude

flavicon
face
Quoting Michael Watterson <spamBeGonemikespamKILLspamradioway.org>:

> Exactly the point I tried to make earlier
>
> Atmel is a sideways move unless you going from PIC16 to ARM.

Allow me to digress from my own topic -- I think C would be better for  some parts of this (just to make the math a bit simpler), and my  understanding is that AVR's are more optimized for C.  There is one  other feature of the AVR's that are enticing me to keep them in the  loop -- the alleged ability to read multiple analog channels *almost*  simultaneously, by initiating a conversion only one cycle after  another has started, and so forth.  This as told to me by an Atmel  FAE.  If so, this would be great.

My current thought is to split it up into multiple chips, linking them  with I2C.  Some low-end PICs would handle the serial data (bit-banged  or otherwise), a low-end AVR would handle the analog stuff (few  channels), and some high-end PIC or AVR would integrate all of it.  A  high-end AVR may eliminate the need for the low-end AVR doing the  analog conversions.  I need to read up a bit more on this.

Cheers,
-Neil.

2010\09\16@085913 by Olin Lathrop

face picon face
PICdude wrote:
> There is one
> other feature of the AVR's that are enticing me to keep them in the
> loop -- the alleged ability to read multiple analog channels *almost*
> simultaneously, by initiating a conversion only one cycle after
> another has started, and so forth.

How many channels do you need to sample, and how close in time do the
samples need to be?  Some dsPICs have multiple sample and holds and can
sample up to 4(?) channels simultaneously.  Some can also convert so fast
that sequential sampling might be good enough for what you are trying to do..


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\09\16@092428 by PICdude

flavicon
face
Quoting Gerhard Fiedler <.....listsspam_OUTspamconnectionbrazil.com>:

> An easy way to get started is to write a C function that has the
> ...

My purpose for asking was to get a better understanding of the  capabilities before having to acquire and completely learn every  option just to decide which way to go.  Once I narrow down the options  and basic architecture, I'll definitely be experimenting with actual  code at that point.

Cheers,
-Neil.

2010\09\16@094036 by Tamas Rudnai

face picon face
Mind you that synchronising tasks with multiple chips are not that easy.
Also it might be easier to use similar products so that you do not need to
deal with everything -- most engineers cannot deal with different chips
equally good (or bad). And as all things has issues you might need to build
up experience on one platform (or limited number of platforms) so that you
can have a better chance to know that selected things in more detail.

So if you think AVR is better for your needs you most probably do not want
to mix it with PICs in my opinion.

Tamas



On Thu, Sep 16, 2010 at 1:42 PM, PICdude <TakeThisOuTpicdude3.....spamTakeThisOuTnarwani.org> wrote:

{Quote hidden}

>

2010\09\16@104721 by rolf

flavicon
face

I guess if something is worth saying, it's worth saying often, right?

;-)

Rolf

On Thu, 16 Sep 2010 14:30:56 +0100, Tamas Rudnai <.....tamas.rudnaispamRemoveMEgmail.com>
wrote:
> Mind you that synchronising tasks with multiple chips are not that easy.
> Also it might be easier to use similar products so that you do not need
to
> deal with everything -- most engineers cannot deal with different chips
> equally good (or bad). And as all things has issues you might need to
build
> up experience on one platform (or limited number of platforms) so that
you
> can have a better chance to know that selected things in more detail.
>
> So if you think AVR is better for your needs you most probably do not
want
> to mix it with PICs in my opinion.
>
> Tamas
>

2010\09\16@132931 by Tamas Rudnai

face picon face
On Thu, Sep 16, 2010 at 3:47 PM, rolf <RemoveMErolfspamspamBeGonetuis.net> wrote:

>
> I guess if something is worth saying, it's worth saying often, right?
>

Sorry, I am not sure what you mean?

Thanks,
Tamas



{Quote hidden}

>

2010\09\16@134302 by Michael Watterson

face picon face
 On 16/09/2010 18:29, Tamas Rudnai wrote:
> On Thu, Sep 16, 2010 at 3:47 PM, rolf<TakeThisOuTrolfspamspamtuis.net>  wrote:
>
>> I guess if something is worth saying, it's worth saying often, right?
>>
> Sorry, I am not sure what you mean?
>
> Thanks,
> Tamas
>
>
>

I got 9 or 12 identical copies of your mail too. I thought maybe my MTA had gone mad. But if rolf saw it too ..

2010\09\16@135043 by rolf

flavicon
face

I received the 'identical' message 9 times...
I just checked the headers, they all have the same message-id, which
basically means you did not send it 9 times, but, if I look in to the
headers, it seems that the mailman at MIT sent it 9 times (at least to me).
I have 9 distinct 'Received from:' headers for the same message from the
mit servers.

So, not your fault ... ;-)

Rolf

On Thu, 16 Sep 2010 18:29:28 +0100, Tamas Rudnai <tamas.rudnaiEraseMEspamgmail.com>
wrote:
{Quote hidden}

>

2010\09\16@140530 by Carl Denk

flavicon
face
I got 9 identical also. :(

On 9/16/2010 1:50 PM, rolf wrote:
{Quote hidden}

>>>

2010\09\16@154140 by Tamas Rudnai

face picon face
Sorry guys if I mixed up something - I used gmail (web interface), hope I
have not click on the Send button that many times :-)

Sorry again!

Tamas


On Thu, Sep 16, 2010 at 7:05 PM, Carl Denk <@spam@cdenkspam_OUTspam.....windstream.net> wrote:

{Quote hidden}

>


'[PIC] Bit-banging in C'
2010\11\07@185342 by Dario Greggio
face picon face
Il 13/09/2010 8.42, PICdude ha scritto:
> Not the answer I wanted to hear.  I was expecting some way to switch
> off optimizations perhaps, and a way (such as a profiler) to figure
> out how many instructions or clock-cycles a particular code sequence
> takes.


Using inline (asm/endasm blocks) assembler has the advantage to ALSO drop off optimization for that block of code (depending upon the compiler, C18 disables for the whole function, other may do somewhat differently) so it's a good choice.

Dari

2010\11\07@194106 by Carl Denk

flavicon
face
Have you looked at the Software UART library routines in C18. In Mplab, Help > Topics > MPLAB C18 Libraries > Index >Uart, software will get you close. It is necessary to program 3 delays in "C" using the delay functions, but there is a good explanation there, a little calculation, and add the delay functions. Using an 18F1320 @ 8M chrystal, and 9600 baud it looks like this: (Caution, I have the transmit delay working good, using this same method, just haven't needed the receive function yet. If someone wants to critique this, that's OK.


DelayTXBitUART
     
       
Delay for:
((((2*Fosc) / (4*baud)) + 1) / 2) - 12 cycles


the numbers look like:
((((2 * 8,000,000)/(4 * 9600)) + 1) / 2 ) - 12 = 196.83 say 197

and the code:

 void DelayTXBitUART (void)
{
Delay10TCYx(19);
Delay1TCY();
Delay1TCY();
Delay1TCY();
Delay1TCY();
Delay1TCY();
Delay1TCY();
Delay1TCY();
}

On 11/7/2010 6:53 PM, Dario Greggio wrote:
{Quote hidden}

>

2010\11\07@222626 by John Gardner

picon face
> ... Prop Rocks....

Concur

2010\11\07@222956 by John Gardner

picon face
> Concur...

Sorry, James :

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