Post by thread:[PIC] Success (Was:- Very Newbie -Progress!)

Exact match. Not showing close matches.
PICList Thread
'[PIC] Success (Was:- Very Newbie -Progress!)'
2005\10\12@085936 by Ed Edmondson

Thanks guys. I have the program compiled and linked which gave me a nice little .hex file. I programmed theF877 and connected it to an LED (in series with a 470 Ohm resistor) and it is blinking at approximately 1 Hz. I used a 4.00 MHz crystal instead of the 10.00MHz crystal because it was handy. I also ordered some F877(A) and F876(A) parts. Should be here this week. The question is what would be a nice second step? Maarten's game would be nice to study but I don't have a PicKit2. If I had a schematic I could build one, I suppose? I have lots of parts and love to build electronic projects. Thanks, Ed

2005\10\12@092218 by Jan-Erik Soderholm

Ed Edmondson wrote : > Maarten's game would be nice to study but I don't > have a PicKit2. It's just as bunch of LEDs and a couple of switches, not ? > If I had a schematic I could build one, I suppose? Build a Pikit2 ? Why ? You just have to connect a few leds and switches according the Maarten's application. But have you searched the Microchip site ? The schematics is in the "PICkitTM 2 Microcontroller Programmer USER?S GUIDE"... Jan-Erik.

2005\10\12@104445 by Wouter van Ooijen

> The question is what would be a nice second step? - let the LED fade on and off (software PWM) - connect 8 LEDs and have them blink knight-rider (kitt) style - connect a potmeter to an A/D input and show the 8-bit value on the 8 LEDs - get a few seven-segment displays and show a value on them - get a LSP (the PC type will do) and make a beep - beep a melody - there used to be a list of 'stupid PIC tricks' but I can't google it any more Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2005\10\12@115011 by Kevin

> The question is what would be a nice second step? > > - let the LED fade on and off (software PWM) > - connect 8 LEDs and have them blink knight-rider (kitt) style > - connect a potmeter to an A/D input and show the 8-bit value on the 8 > LEDs > - get a few seven-segment displays and show a value on them > - get a LSP (the PC type will do) and make a beep > - beep a melody > - there used to be a list of 'stupid PIC tricks' but I can't google it > any more > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > You could try this page http://www.piclist.com/techref/piclist/begin.htm Which has a led flasher for an F877 http://www.piclist.com/techref/microchip/16F877/flashled.htm Little late for that one now ;)

2005\10\12@174724 by Jinx

Congratulations on finally seeing the LED blink > used a 4.00 MHz crystal instead of the 10.00MHz You should change the config oscillator setting __CONFIG _CP_OFF & _WRT_ENABLE_ON & _HS_OSC & ..... etc Replace _HS_OSC with _XT_OSC. See Section 12.2 of the manual > I have lots of parts and love to build electronic projects What kind of parts ? Do you have any test equipment like meters or an oscilloscope ? Are you keen to go dumpster diving to get more parts ? ;-))) Feel game enough for an LCD ? The reason I ask is because although it's a big ask for a beginner, an LCD can be a very useful debugging tool Perhaps try out a 32kHz "watch" crystal on TMR1 and make some sort of clock. Would be a simple and useful introduction to timers and interrupts

2005\10\12@183244 by Ed Edmondson

From: "Jinx" <spam_OUTjoecolquittTakeThisOuTclear.net.nz> > Congratulations on finally seeing the LED blink. Yes, I found it quite rewarding. >> used a 4.00 MHz crystal instead of the 10.00MHz . You should change the >> config oscillator setting > > __CONFIG _CP_OFF & _WRT_ENABLE_ON & _HS_OSC & ..... etc > > Replace _HS_OSC with _XT_OSC. See Section 12.2 of the manual I had already changed it when I programmed the config bits. > >> I have lots of parts and love to build electronic projects > What kind of parts ? Just about anything one would want.to have when > working with controllers. I even have an Atmel STK200 (?) and really don't > know what to do with it. I figure PICs will keep me occupied for some > time. Anyone do Atmel? Do you have any test equipment like meters or an oscilloscope ? I have a 100MHz tek scope in great condition. It's a 2235 I believe. I have an HP 80MHz frequency counter. I have a nice linear power supply I designed from regulator datd sheets. Are you keen to go dumpster diving to get more parts ? ;-))) I come from a long line of dumpster divers. I worked at Collins/Rockwell, Texas Instruments, Boeing Electronics to name just a few. I had access to all kinds of items which were scrapped or deleted from inventory. I have collected a lot along the way. I finally retired at 55 and want to do some of the things I always wanted. > > Feel game enough for an LCD ? The reason I ask is because although it's a > big ask for a beginner, an LCD an be a very useful debugging tool. An LCD would be great. Just point the way. Sounds like a good way to debug something. > > Perhaps try out a 32kHz "watch" crystal on TMR1 and make some sort of > clock. Would be a simple and useful introduction to timers and > interrupts. Great! I am looking for something else to do. > > --

2005\10\12@191001 by Tim N9PUZ

Ed Edmondson wrote: > Great! I am looking for something else to do. Other nice begginer to intermediate projects that'll help you think and learn to program: - Write programs that use multiple PIC pins to emulate various types of gates like OR, NOR, AND, NAND. - Use the timer interrupt, increment some counters, and set bits at various intervals such as 10mS, 50mS, 100mS, etc. or longer. Then in your main program loop watch for those bits to be set and do something like toggle the state of an LED the clear the bit. Your program can perform these little multiple "tasks" all at the same time. Have it do something differently based on the position of a switch. - The LCD mentioned is a great idea. - Does your PIC have a serial port? Send messages to Hyperterminal instead of an LCD. - Once your clock display is figured out make a stopwatch instead.

2005\10\12@194711 by James Newtons Massmind

> > Feel game enough for an LCD ? The reason I ask is because although > > it's a big ask for a beginner, an LCD an be a very useful > debugging tool. > > An LCD would be great. Just point the way. Sounds like a good > way to debug something. An LCD panel with a few switches, leds, and a nice pin header to connect it would be even better! http://www.piclist.com/techref/io/lcd/panel1.htm Especially if it only cost $8 and supported the piclist.com web site. --- (somebody named) James.

2005\10\12@203839 by Jinx

> > Perhaps try out a 32kHz "watch" crystal on TMR1 and make > > some sort of clock. Would be a simple and useful introduction > > to timers and interrupts. > > Great! I am looking for something else to do. It's fairly simple (compared to setting up an LCD) and shouldn't take you too much time. Well, probably it'll keep you out of mischief all weekend The relevant things to know are (I'm sure I'll leave something out and others will have things to add - I could have kept on writing all afternoon but that would make at least one person decidedly grumpy) : Refer to Section 6.0 "Timer1 Module" Pins 15/16 of the 877 are able to have a LF crystal across them, (with suitable capacitors, see Table 6-1). When TMR1 oscillator is enabled, TMR1 increments at the crystal frequency. There's a pre-scaler on the front end of TMR1 which can be used to slow down the incrementing, see the manual text When any timer increments from FFFF (or FF for 8-bit timers) to 0000 (or 00), its interrupt flag is set. See Table 6-2. In the case of TMR1, this would be the bit TMR1IF in register PIR1 In the register INTCON is the Global Interrupt Enable bit, GIE, and in PIE1 is the Timer1 Interrupt Enable bit, TMRIE. If these are set, TMR1 interrupts will occur When the hardware detects that TMR1IF has been or is set, the current value of the Program Counter is stored and then PC is loaded with the vector at 0x04 (REMmed out in the program I posted) **IF** GIE and TMR1IE were set previously or are set when TMR1IF is set. In other words, if, and only if, all three are set, will an interrupt will occur. Once the PC has been loaded with this vector, execution of the ISR (Interrupt Service Routine) code begins. At this point GIE is cleared so that no other interrupts can occur. This is to prevent what is known as a "race" condition, in which the s/w keeps trying to enter the ISR An ISR is simply a routine that does what you want to happen after an interrupt. It's basically no different from any other routine. At the end of the ISR routine, the stored PC value is retrieved (with RETFIE, which is the same as a RETURN except it also turns GIE back on) and the program continues on from where it was interrupted. From Looking at Section 12.10, you'll see that the hardware logic is a collection of AND (and an OR for the final stage of a path) gates. If any condition is not met to allow a "1" bit to get from one end to the other, the logic fails and a "0" bit results = no interrupt TMR1IF & TMRIE & GIE = interrupt Section 12.10.1 - Context storing W and STATUS should be preserved on entering the ISR, as they are the two most-used registers and the values in them are more than likely important to the code that was executing before the interrupt Use the first 4 lines of Example 12-1 to save W and STATUS and the final 4 lines to restore them on exiting OK, that's interrupts roughly dealt with, now to apply one With T1OSC enabled, and the pre-scaler set to 1:8, this should happen - If a 32.768kHz crystal is on TMR1 OSC pins, TMR1 will increment at (32768 / 8) = 4096Hz Timer1 is 16-bits ( = h10000 = d65536) wide so it will "roll over" from FFFF to 0000 (65536 / 4096) = 16 times per second Now, what you can do with these roll overs is increment or decrement a RAM counter. The little program below will, with interrupts and TMR1 set up, toggle an LED every 0.5s, ie 1Hz flash rate, as accurate as the crystal At the start of the program you'll need org 0x04 goto isr For reference, look at this read-modify-write page for the reasoning behind using a shadow register http://www.piclist.com/techref/readmodwrite.htm and general timer tips http://www.piclist.com/techref/microchip/time.htm In your program (view with fixed-pitch font eg Notepad) #define led portb,7 ;any I/O pin will do for LED w_temp ;you need these variables in the list status_temp counter shadowb movlw 0x08 ;or use .8 for a decimal value, see MPLAB Help movwf counter tmr_loop nop ;wait here for a TMR1 interrupt goto tmr_loop isr bcf pir1,tmr1if ;very very important to clear TMR1IF movwf w_temp ;save W and STATUS swapf status,w clrf status ;only if you want to be in bank0 movwf status_temp decfsz counter ;decrement the counter, skip the next ;instruction (goto exit) if it = 0 goto exit ;therefore counter is not 0, exit toggle movf portb,w ;PortB register is in bank0 movwf shadowb ;copy it to a RAM variable movlw b'10000000' ;exclusive-OR the LED pin bit (portb,7) xorwf shadowb,w ;which toggles it movwf portb ;and write it back to PortB movlw 0x08 ;reload the counter movwf counter exit swapf status_temp,w movwf status swapf w_temp,f ;",f" is optional, default is ,f swapf w_temp,w retfie ;leave ISR. Goes back to tmr_loop ;with GIE on, ready for next IRQ

2005\10\12@211333 by Jinx

> If a 32.768kHz crystal is on TMR1 OSC pins, TMR1 will > increment at (32768 / 8) = 4096Hz > > Timer1 is 16-bits ( = h10000 = d65536) wide so it will "roll > over" from FFFF to 0000 (65536 / 4096) = 16 times per > second My apology Ed, I got the division A-over-T TMR1 will roll over once per 16 seconds. With the ISR counter set to 8, the LED will toggle every 8 x 16 = 128 seconds. If I hadn't spotted that you may have thought the code was not working, being so long between state changes Oh fudge, what to do, what to do Amend the ISR as below. By reloading TMR1H with 0xF8 it will increment from 0xF800 ( = - 2048) to 0x0000 before rolling over. This will give you a 1Hz flash rate (= 2Hz update). That's with pre-scaler = 1:8. If pre-scaler is changed to 1:1 (ie 32768Hz count rate), then you'd re-load TMR1H with 0xC0, so that the count starts at 0xC000 ( = -16384) As TMR1 keeps incrementing in hardware, driven by the crystal, the low byte will have advanced whilst you're executing code before the rre-load, but because only the high byte is being re-loaded this shouldn't be a problem BTW, using a shadow register is not strictly necessary in this simple example as there is such a long time between changes on the pin, but I thought it worth introducing ==================== isr bcf pir1,tmr1if ;very very important to clear TMR1IF movwf w_temp ;save W and STATUS swapf status,w clrf status ;only if you want to be in bank0 movwf status_temp movlw 0xF8 ;re-load TMR1 high byte with -0x08 movwf tmr1h ;so it increments 0x0800 before roll over toggle movf portb,w ;PortB register is in bank0 movwf shadowb ;copy it to a RAM variable movlw b'10000000' ;exclusive-OR the LED pin bit (portb,7) xorwf shadowb,w ;which toggles it movwf portb ;and write it back to PortB exit swapf status_temp,w movwf status swapf w_temp,f ;",f" is optional, default is ,f swapf w_temp,w retfie ;leave ISR. Goes back to tmr_loop ;with GIE on, ready for next IRQ

2005\10\13@042154 by Alan B. Pearce

>The question is what would be a nice second step? >Maarten's game would be nice to study but I don't >have a PicKit2. If I had a schematic I could build >one, I suppose? I have lots of parts and love to >build electronic projects. Have a look at http://dt.prohosting.com/pic/pong.html and convert it to 877 code (I think it is 16F84 at the moment. Also check out the link at the bottom, to another classic version.

2005\10\13@080248 by olin piclist

Jinx wrote: > If a 32.768kHz crystal is on TMR1 OSC pins, TMR1 will > increment at (32768 / 8) = 4096Hz > > Timer1 is 16-bits ( = h10000 = d65536) wide so it will "roll > over" from FFFF to 0000 (65536 / 4096) = 16 times per > second No. This is exactly why units should always be carried thru any calculations. (65536 increments/rollover) / (4096 increments/second) = 16 seconds/rollover. With a 1:1 prescaler you can get 2 seconds/rollover. If you want 1Hz = 1 second/rollover, then you have to diddle the timer value each interrupt. The easiest way is to write 80h to TMR1H upon interrupt. That effectively pre-loads the timer with 32768 so that there are only 32768 increments left until the next rollover. You can safely write to TMR1H if it is done soon after the interrupt because it will be 256 oscillator cycles before the first carry from TMR1L into TMR1H. > #define led portb,7 ;any I/O pin will do for LED > > w_temp ;you need these variables in the list > status_temp > counter > shadowb I don't know what you're trying to do here, but you can't just use a variable name as an opcode. What would you want it to do anyway? > movlw 0x08 ;or use .8 for a decimal value, see MPLAB > Help Please don't use the .<decimal number> syntax. For a while it was removed from the documentation. I think Microchip would like to get rid of it and keeps it for compatibility with ancient code. If the assembler ever support fixed or floating point formats natively, this could lead to lots of confusion, not to mention the confusion others will have that are not that familiar with this obscure corner of MPASM syntax. Personally I always set decimal as the default radix. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\10\13@081249 by olin piclist

Jinx wrote: > If pre-scaler is changed to 1:1 (ie > 32768Hz count rate), then you'd re-load TMR1H with 0xC0, > so that the count starts at 0xC000 ( = -16384) It doesn't seem to be your day, Jinx. I think it's easier to think of timer 1 as an unsigned 16 bit number that counts from 0 to 65535 then wraps back to 0 for a total of 65536 counts per interrupt. If you want 32768 counts/interrupt, then the timer must be pre-loaded to skip 65536 - 32768 = 32768 counts = 8000h. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\10\13@084603 by Jinx

> From: "Olin Lathrop" > (65536 increments/rollover) / (4096 increments/second) = 16 I made a second post very shortly after the first as I soon spotted the division being the wrong way around and made the corrections > > w_temp ;you need these variables in the list > > status_temp > > counter > > shadowb > > I don't know what you're trying to do here, but you can't just > use a variable name as an opcode Theey aren't being used as opcodes. I don't know how Ed is declaring his variables, whether with cblock, res, whatever, so simply said in the comment that these variable names are used > > movlw 0x08 ;or use .8 for a decimal value, > Please don't use the .<decimal number> syntax I don't see anything inherently wrong with it > I think Microchip would like to get rid of it and keeps it for > compatibility with ancient code Do you have any evidence for that ? I can't see any easy way for them to get rid of even if they did want to, apart from just dropping it from future MPLAB. Any old code would then have to be processed with an old version of MPLAB. Given that 7.x is quite advanced and still allows various number systems it wouldn't necessarily be that onerous to do so if 8.x or later had only hex and binary (not that I can see it ever happening)

2005\10\13@085615 by olin piclist

Jinx wrote: >> I think Microchip would like to get rid of it and keeps it for >> compatibility with ancient code > > Do you have any evidence for that ? I've heard grumblings about it from Microchip people. A few years ago the <number> syntax was dropped from the documentation but not from MPASM. I know because I found some old code and couldn't figure out what .xxx was supposed to mean. I had to ask Microchip. Meanwhile I think they got some complaints and put .xxx back in the documentation. So I agree, it probably won't go away. I didn't say it would, only that Microchip would like it to, but I think they have resigned themselves that they can't take it away. I still think it's a bad syntax to use, whether it will disappear from future versions or not. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

2005\10\13@092445 by Jan-Erik Soderholm

Jinx wrote : > Olin wrote : > > > > Please don't use the .<decimal number> syntax > > > > I think Microchip would like to get rid of it and keeps it for > > compatibility with ancient code > > Do you have any evidence for that ? I can't see any easy way > for them to get rid of even if they did want to, apart from just > dropping it from future MPLAB. Any old code would then have > to be processed with an old version of MPLAB. Given that 7.x > is quite advanced and still allows various number systems it > wouldn't necessarily be that onerous to do so if 8.x or later > had only hex and binary (not that I can see it ever happening) I don't think Olin ment decimal *as such*, just *that* specific way of coding it... Jan-Erik.

2005\10\13@092808 by Jinx

> <number> syntax > I still think it's a bad syntax to use, whether it will disappear > from future versions or not Bottom line for me always is not how my or anyone's code is more or less regarded, but how well it works in the PIC (that's not to say you can leave source code incomprehensible). One way of getting what you intend into a hex file works for some, another way for others For example a routine like this, in a hex radix environment, is probably an anathema to some, but there's an understandable logicallity about it l_loop1 movfw indf0 addlw .255-"Z" ;test if UC letter addlw ("Z"-"A")+1 bnc num0d ;not letter movff postinc0,postinc1 incf cnt1 bra l_loop1

2005\10\13@093838 by Jinx

> > If pre-scaler is changed to 1:1 (ie > > 32768Hz count rate), then you'd re-load TMR1H with 0xC0, > > so that the count starts at 0xC000 ( = -16384) > > It doesn't seem to be your day, Jinx It must be Thursday......... (well, it was, 3 hours ago, yawn) > I think it's easier to think of timer 1 as an unsigned 16 bit number > that counts from 0 to 65535 then wraps back to 0 for a total of > 65536 counts per interrupt. If you want 32768 counts/interrupt, > then the timer must be pre-loaded to skip 65536 - 32768 = > 32768 counts = 8000h. Just to clarify, mostly for Ed's benefit - I'd been suggesting that the LED could be made to flash at 1Hz, 0.5s on, 0.5s off, which meant a 2Hz update rate. A pretty good rate to flash at, as it has a real-world application So with a 32768Hz crystal, 16384 increments (1:1 p/s) of TMR1 would take 0.5s, hence loading it with 0xC000

2005\10\13@094022 by Michael Rigby-Jones

{Quote hidden}>-----Original Message----- >From: .....piclist-bouncesKILLspam@spam@mit.edu [piclist-bouncesKILLspammit.edu] >Sent: 13 October 2005 13:46 >To: Microcontroller discussion list - Public. >Subject: Re: [PIC] Success (Was:- Very Newbie -Progress!) > > >> From: "Olin Lathrop" > >> (65536 increments/rollover) / (4096 increments/second) = 16 > >I made a second post very shortly after the first as I soon >spotted the division being the wrong way around and made the >corrections > >> > w_temp ;you need these variables >in the list >> > status_temp >> > counter >> > shadowb >> >> I don't know what you're trying to do here, but you can't just use a >> variable name as an opcode > >Theey aren't being used as opcodes. I don't know how Ed is >declaring his variables, whether with cblock, res, whatever, >so simply said in the comment that these variable names are used > >> > movlw 0x08 ;or use .8 for a decimal value, > >> Please don't use the .<decimal number> syntax > >I don't see anything inherently wrong with it > >> I think Microchip would like to get rid of it and keeps it for >> compatibility with ancient code > >Do you have any evidence for that ? I can't see any easy way >for them to get rid of even if they did want to, apart from >just dropping it from future MPLAB. Any old code would then >have to be processed with an old version of MPLAB. Given that >7.x is quite advanced and still allows various number systems >it wouldn't necessarily be that onerous to do so if 8.x or >later had only hex and binary (not that I can see it ever happening) I think you are misinterpreting Olins comments. He dosen't wan't to abolish the use of decimal bases in MPASM, but rather always make decimal the default radix, so the dot is never required. I agree with him, the dot notation is an annoyance. It's easily forgotten and easily missed when reading the code. As decimal and hex are by far the most widely used bases, and MPASM supports the use of the common C style hex notation (e.g. 0x1234), it's seem just neater and more obvious to do things this way. 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. =======================================================================

2005\10\13@094733 by Jinx

> I don't think Olin ment decimal *as such*, just *that* specific > way of coding it... For a long maths routine it would be probably preferable to use radix decimal, but I don't see the harm in using the odd .<xxx> here and there in radix hex for convenience / readability For example re-loading TOD clock registers (as Ed's program could grow into). The ISR structure is based around a hex crystal and hex counting. It makes more sense to me to use .60 to re-load second and minute variables rather than 0x3C, when the rest of the routine is in hexadecimal The option is still there to d<xxx> and also MPLAB can be colour-coded to highlight numbers of any system in various colurs. I keep hex in dark blue, decimal in light blue

2005\10\13@095030 by Alan B. Pearce

>I don't think Olin ment decimal *as such*, >just *that* specific way of coding it... Also no one has given the other syntaxes (syntaxii?) and why they prefer it. Personally I think the syntax using the decimal point is bad, as it is all too easy to miss seeing the decimal point in a listing. Now this does not matter for numbers in the range of 0-9, but once larger than that, if the default radix is hexadecimal (hint - guess another way of setting decimal, that Olin prefers) then it is all too easy to figure that .10 is 10 hex - and such a mistake is all too easy to make in the pressure of attempting to get something debugged in a hurry..

2005\10\13@095312 by Jinx

> but rather always make decimal the default radix, so the dot is > never required. I agree with him, the dot notation is an annoyance. > It's easily forgotten and easily missed when reading the code I could agree with that, especially in monochrome or in printed material (see my reply to J-E about MPLAB colours). I would have no strong objection to . being dropped in favour of d for example. It's along the lines of Alan Pearce's comment in [OT] International Standards "Now you know why components use the multiplier letter as the decimal position in Europe - saves lots of confusion over what symbol is used for the decimal point, - i.e. 1k5 for a 1 point 5 kohm resistor"

2005\10\13@095806 by Jinx

> then it is all too easy to figure that .10 is 10 hex - and such a > mistake is all too easy to make in the pressure of attempting to > get something debugged in a hurry.... Personally I'm careful to always use just 0X<xx>, 0X<xxxx> and .<xxx> For some reason though, just habit I guess, I use d<xxx> when coding for Motorolas. Maybe it's something I should have a look at and use d<xxx> for MPLAB too (no, I haven't forgotten about radix)

2005\10\13@100228 by Jan-Erik Soderholm

Michael Rigby-Jones wrote : > I think you are misinterpreting Olins comments. He dosen't > wan't to abolish the use of decimal bases in MPASM, but > rather always make decimal the default radix,... Yes, you can, but I don't think that was the point. Jinx wrote : > For a long maths routine it would be probably preferable to > use radix decimal, but I don't see the harm in using the odd > .<xxx> here and there in radix hex for convenience / readability Again, it wasn't about default radix, realy, I read it such as the prefered formats are d'xx', h'xx', o'xxx', b'xxxxxxxx' and a'x'. Well, at least Olin's prefered formats, and I agree. And to not use .12 or 0x12, as those differ from the general format above. And this has nothing to do with "default radix" as such... (And not about dropping decimal all together, of course :-) ) Jan-Erik. >

2005\10\13@113952 by Michael Rigby-Jones

{Quote hidden}>-----Original Message----- >From: .....piclist-bouncesKILLspam.....mit.edu [EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu] >Sent: 13 October 2005 15:02 >To: piclistspam_OUTmit.edu >Subject: RE: [PIC] Success (Was:- Very Newbie -Progress!) > > >Michael Rigby-Jones wrote : > >> I think you are misinterpreting Olins comments. He dosen't >> wan't to abolish the use of decimal bases in MPASM, but >> rather always make decimal the default radix,... > >Yes, you can, but I don't think that was the point. > >Jinx wrote : > >> For a long maths routine it would be probably preferable to >use radix >> decimal, but I don't see the harm in using the odd .<xxx> here and >> there in radix hex for convenience / readability > >Again, it wasn't about default radix, realy, I read it such as >the prefered formats are d'xx', h'xx', o'xxx', b'xxxxxxxx' and a'x'. > That was never explicitly mentioned that I can see, just the dot notation for decimal. I personally think they are horribly clunky formats, though they are at least consistent for all bases. Perhaps because I primarily use C and therefore am more familiar with 1234 and 0x1234 (shame MPASM dosen't use 0bxxxxxxxx for binary). Does anyone actually use octal base? I can't remember ever writing anything that would have required it. 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. =======================================================================

2005\10\13@115342 by Robert Young

> I personally think they are horribly clunky formats, though > they are at least consistent for all bases. Perhaps because > I primarily use C and therefore am more familiar with 1234 > and 0x1234 (shame MPASM dosen't use 0bxxxxxxxx for binary). > Does anyone actually use octal base? I can't remember ever > writing anything that would have required it. > I used octal for the first time in years in some VHDL code that needed to build a look-up table style decoder six bits wide. Made it easy to write some extra VHDL code that could regenerate the synthesizable VHDL if the look-up table changed. Rob

2005\10\13@124552 by olin piclist

Jinx wrote: > It makes more sense to me to use .60 > to re-load second and minute variables rather than 0x3C, when > the rest of the routine is in hexadecimal I'm not against decimal constants, in fact I use decimal as the default radix in my PIC development environment. I don't like the .<number> syntax to specify decimal. It looks too much like it's meant to be a fractional value. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

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