headers
Ray Newman | 1 Jul 01:28

[PIC] assembly directives

I forgot the difference in meaning of "=" and "==" in assembly directives
for MPLAB

or "=" is not used in IF THEN ELSE ENDIF ???

I used "==" for conditional assembly base on current program memory address

But I can't recall ever using just "="

I have two pieces of hardware that are 90% identical in I/O for the same MCU
So instead of writing two different programs, which I did, I need to combine
and do the if/the/else for the slight differences but everything else works the same
and if I do some software updates, it will be the exact same for both.
That way I do not have to edit both programs.

Thanks,
Ray

--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 2 comments |
headers
Tamas Rudnai | 1 Jul 01:53
Picon

Re: [PIC] assembly directives

hi Ray,

"=" is for set a variable, "==" is for conditionals.

Example:

variable size = $ - label;

if size == 18
...
endif

Regards,
Tamas

On 7/1/07, Ray Newman <list <at> microdesigns.biz> wrote:
>
> I forgot the difference in meaning of "=" and "==" in assembly directives
> for MPLAB
>
> or "=" is not used in IF THEN ELSE ENDIF ???
>
> I used "==" for conditional assembly base on current program memory
> address
>
> But I can't recall ever using just "="
>
> I have two pieces of hardware that are 90% identical in I/O for the same
> MCU
> So instead of writing two different programs, which I did, I need to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ray Newman | 1 Jul 02:28

Re: [PIC] assembly directives

Tamas,

Thanks!
Mind went blank for a little bit.

Ray

On Sun, 1 Jul 2007 00:53:36 +0100, Tamas Rudnai wrote:
> hi Ray,
>
> "=" is for set a variable, "==" is for conditionals.
>
> Example:
>
> variable size = $ - label;
>
> if size == 18
> ..
> endif
>
>
> Regards,
> Tamas
>
>
> On 7/1/07, Ray Newman <list <at> microdesigns.biz> wrote:
>
>> I forgot the difference in meaning of "=" and "==" in assembly
>> directives for MPLAB
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olin Lathrop | 1 Jul 01:49

Re: [PIC]: USB: Reading serial number descriptor from data EEPROM?

Philip Pemberton wrote:
> A bit of both, actually. I'm hacking together a homebrew 'mood light'
> out of a couple of RGB LEDs, and I thought it would be a decent project
> to get back into the 'swing of things' - it's been a good few months
> since I've written any code for LibUSB, or the Microchip USB framework,
> and I wanted to do something simple first.

If your interested in the code I described, I can make it available in its
present form.  Like I said, it's free for personal projects, and I think
you'll find the source a lot better documented than Microchip's.

> Of course, it's not simple
> when you've got three LEDs and only two PWM channels.

Sure it is.  No need to use hardware PWM just to adjust the brightness of
LEDs for human display.  A USB PIC can run at 12MHz instruction rate.  Let's
say you set up a periodic 100 cycle interrupt to update all the PWM outputs,
then you can have 8 bit brightness resolution at 471Hz update rate for as
many channels as you have output pins.  471Hz is fast enough for your eyes
to percieve average brightness, and a PWM update interrupt should only take
a small part of the 100 cycles leaving most of the processor to other tasks.

> The other project is a low-volume device that reads floppy discs at the
> flux transition level. It's basically meant to allow 'odd format' discs
> to be read, analysed and (where required) copied. There are a lot of
> 'vintage' computers out there and not a lot of copies of install discs
> and the like. Problem being that PC floppy controllers can't generally
> copy these discs. So the obvious solution is a box that can read and
> write discs at the lowest level possible. This is the 'big thing' that
> I REALLY don't want to screw up. The HDL code is all done, I just need
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jake Anderson | 1 Jul 11:34

Re: [PIC]: USB: Reading serial number descriptor from data EEPROM?


> The other project is a low-volume device that reads floppy discs at the flux 
> transition level. It's basically meant to allow 'odd format' discs to be read, 
> analysed and (where required) copied. There are a lot of 'vintage' computers 
> out there and not a lot of copies of install discs and the like. Problem being 
> that PC floppy controllers can't generally copy these discs. So the obvious 
> solution is a box that can read and write discs at the lowest level possible. 
> This is the 'big thing' that I REALLY don't want to screw up. The HDL code is 
> all done, I just need to build up a prototype, write the software and squash 
> the inevitable bugs.
>   
Sounds like you might be well served to "re-engineer" the reading 
mechanism for the disk itself if your going to all that effort anyway. I 
imagine that modern amps and D/A converters and the like would be loads 
better than something your going to find in an 8.5" fdd drive. Perhaps 
even to the point of making up a magnetic scanner based on a cd drive or 
some such. You should be able to get lots more information about what a 
particular bit is sposed to be then?
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 2 comments |
headers
Jake Anderson | 1 Jul 11:49

Re: [OT] Units rant

Russell McMahon wrote:
>>> Have you ever tried to send messages from a PC which thinks that 
>>> you
>>> want to converse in Chinese and is utterly dedicated to ensuring 
>>> that
>>> you do so ? :-). When sending emails from Taiwan I have been forced 
>>> on
>>> occasion to use Alt-nnn combinations to obtain "English" text or 
>>> even
>>> to cutting and pasting letters from other messages. I'm certain 
>>> that
>>> there would have been easy ways to convince said PCs that I wanted 
>>> to
>>> actually produce the characters shown on the keyboards that I was
>>> using, but I could not at the time find anyone who could both
>>> understand my question and answer it.
>>>       
>
>   
>> If its running windows and you see a blue square with a language 
>> code in
>> the system tray try clicking on it. You may well find an english 
>> option
>> in the list that pops up.
>>     
>
> In the above paragraph the normal meanings of "forced", "utterly 
> dedicated", "could not at the time" and "Chinese" apply :-). Resorting 
> to Alt-nnn for plain text entry is often a reliable sign that one has 
> come to the end of one's other resources.
(Continue reading)

Permalink | Reply | 1 comment |
headers
wouter van ooijen | 1 Jul 12:42
Picon
Favicon
Gravatar

RE: [PIC]/[EE] Small microcontroller with GCC support?

> I think that the throw mechanism uses the error handler and
> any unwinding done to reach it in flat mode, like longjmp() 
> in C.

Which error handler are you talking about and what is 'flat mode'? ARe
you referring to a specific implementation of exception handling? If so,
remeber: the existence of a bad or broken implementation of a concept is
no proff against that conecpt!

> longjmp() is one of the things one is expressly warned 
> not to use in an interrupted environment. As you know, it 
> uses a static data structure (or several).

No, I don't know, because I never usef setjmp/longjmp. 

> There is no way to 
> know whether the time between when throw occurs and when the 
> handler is executed affords any protection to the variables 
> and to the stack involved.

Sorry, his makes no sense at all.

> If an interrupt occurs in the same 
> thread and the interrupt thread does anything related to the 
> throw context (such as, initializing the throw data block 
> upon entry into the try segment),

An interrupt executes on its own stack or on an extension of the
interrupted stack. the exception throwing/hndling/catching mechanism can
(and should) be implemented fully reentrant, so there will be no problem
(Continue reading)

Permalink | Reply | 44 comments |
headers
Peter Bindels | 1 Jul 12:51
Picon

Re: [PIC]/[EE] Small microcontroller with GCC support?

On 30/06/07, Peter P. <plpeter2006 <at> yahoo.com> wrote:
> Gerhard Fiedler <lists <at> connectionbrazil.com> writes:
> > Maybe his thought was that this is more hidden. I don't know.
>
> I think that the throw mechanism uses the error handler and any unwinding done
> to reach it in flat mode, like longjmp() in C. longjmp() is one of the things
> one is expressly warned not to use in an interrupted environment. As you know,
> it uses a static data structure (or several). The C++ throw mechanism very
> likely uses the same paradigm but in addition to longjmp the structure is hidden
> from the programmer so he cannot guard it against a concurrent task.

The structure is the one that stores where to longjmp to; exceptions
most certainly don't have a longjmp-style target but rather have
exception handler frames (.ehframe) sections in the executable that
contain this information on a per-function basis, in a non-modifiable
and hence reentrant way.

Regards,
Peter
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 0 comments |
headers
Peter Bindels | 1 Jul 12:59
Picon

Re: [PIC]/[EE] Small microcontroller with GCC support?

On 30/06/07, Peter P. <plpeter2006 <at> yahoo.com> wrote:
> #include <CRIT.h>
> #include <kbd.h.>
> #include <rs232.h>
> #include <timer.h>
>
> volatile int errors = 0;
> volatile int keycode = 0;
>
> void Rs232txd {
>   CRITA
>   if((rs232->status & RS232_TXEMPTY) && keycode) {
>     rs232->txd = keycode;
>     keycode = 0;
>   }
>   CRITZ
> }
>
> void ButtonsToSerial(void) {
>     CRITA
>     if(keycode) { // overrun
>       errors |= TXD_OVERRUN; // NOT throw(), oops
>       CRITZ // !!!
>       return;
>     }
>     keycode = kbd->keycode;
>     kbd->status & ~KEY_DOWN;
>     CRITZ
>     Rs232txd;
> }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Todd | 1 Jul 05:00
Picon

Re: [TECHO] [EE] Harvesting energy from noise


On Sun, Jul 01, 2007 at 03:01:38AM +1200, Russell McMahon wrote:
> This is essentially a  micro scale version of eg mechanical automatic 
> watches which have been around for many decades. Different "vibration" 
> source- essentially same principle. Could be useful but that's an 
> extremely low power level (40 uW).

If I've got my units right, that's still a little more than 10x more
power than you can get out of a usual, 10 year, 1uA lithium battery,
3.3uW.

Of course, I'm holding out for widely available radioisotope cells... Or
those fancy direct conversion tritium decay based cells that I've read
about. Directly converting the alpha partical decay into electroncs and
capturing them. Tritium is remarkably non-toxic stuff for a nuclear
material. It dissipates into the environment very quickly, has a very
short biological half-life, and is naturally present in quantities far
higher than we can produce, so the "solution to pollution is dilution"
thing actually works out...

I wonder how much power is my little tritium glowlight dissipating
anyway?

--

-- 
http://petertodd.org
Permalink | Reply | 0 comments |

Gmane