89C51ED2
in [Design]
|
From: Gordon S. Hlavenka on 6 Sep 2008 00:27 Eeyore wrote: > I can't even begin to imagine coding some of the fairly complex (for microcontrollers) > stuff that we did with 8051s in asm. The mind boggles. Never mind code maintenance. If your ASM code isn't maintainable, you're not doing it right. I dunno who started the rumor that ASM is difficult but I'll bet it wasn't someone who coded ASM :-) Me, all the hand-waving that precedes useful work in a C project gives me the vapors. Sure I have "*.h"-like stuff at the top of my ASM source too, but it's perfectly understandable. Here's a little cut-and-paste from "live" code: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; ; Program Constants ; ; ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; s0mode equ 01010000b ; s1mode equ 01010000b ; spi_mode equ 11011101b ; CCLK/128, data leading edge, ; CLK idle high, MASTER mode, ; MSB first, Enable SPI, ; ignore /SS baud_low equ 0f0h ; 9600 bps baud_high equ 002h ; Assumes internal osc and ; SMOD=0 sentinel equ 13 ; End Sentinel character (CR) size_of_buffer equ 48 ; Serial RX buffer length (...) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; ; Data RAM allocation ; ; ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; DSEG AT 030h ; This allows use of all 4 ; Register banks and the entire ; Bit Segment head0: ds 1 ; Ring buffer pointers tail0: ds 1 ; . head1: ds 1 ; . tail1: ds 1 ; . buflen: ds 1 ; Length of received message state: ds 1 ; State variable old_state: ds 1 ; (...) IF ($>060h) ; Reserve at least 32 bytes for ; stack. END Out of Direct RAM! ; WARNING! Stack can grow up ; into the IDATA buffers! 32 ENDIF ; bytes should be plenty, ; though. STACK_BASE equ $ ; ; DSEG AT 080h ; IDATA, indirect access only buffer: ds size_of_buffer ; Command receive buffer ringbuf0: ds size_of_ring0 ; ringbuf1: ds size_of_ring1 ; IF ($>0ffh) END Out of Indirect RAM! ENDIF ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; ; Bit variables ; ; ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; BSEG AT 0 ; new_state: dbit 1 ; Flag to indicate state change keypressed: dbit 1 ; (...) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; ; Port pin assignments ; ; ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; LCD_RS equ acc.5 ; We operate in the LCD_E equ acc.6 ; accumulator because LCD_RW equ acc.7 ; P4 is not bit-addressable LCD_BF equ acc.7 ; Makes the code more readable ; RELAY equ P0 ; This allows stuff like ; 'SETB RELAY.0' and ; 'CLR RELAY.3' DRDY equ P0.7 ; SPI pacing from keypad IC ; PIEZO_PIN equ P1.7 ; Beeper output pin (...) (and here's a simple function) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; ; Test for End Sentinel ; ; ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; ; Checks whether the last character in ; ; the buffer is an ES. Returns with C ; ; cleared if the ES is there and set if ; ; it isn't. ; ; ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; test_ES: ; push acc ; push ar0 ; mov a,buflen ; dec a ; add a,#buffer ; mov r0,a ; mov a,@r0 ; Get last character in buffer cjne a,#sentinel,tES_error ; If not ES then error clr C ; Match jmp tES_done ; tES_error: ; setb C ; No match tES_done: ; Fall through pop ar0 ; pop acc ; ret ; This stuff is not so hard! Of course I'm not giving up complicated paying code here on the interwebs, but it's just as doable in ASM as it is in a HLL. The advantage of ASM coding is that it does _exactly_ what you say; you don't have to guess what the compiler has "optimized" for you. If something is hard to do in C it's probably going to be hard to do in ASM too. But not substantially harder. And maintainability is just a matter of organizational discipline and decent comments. You can be obtuse in any language; just look at the Obfuscated C Contest! PS - Hope I'm not in trouble for posting code to a hardware group :P -- Gordon S. Hlavenka Join the Revolution at http://www.ronpaul.com
From: Eeyore on 6 Sep 2008 00:36 Rich Grise wrote: > Eeyore wrote: > > Rich Grise wrote: > >> Eeyore wrote: > >> > Rich Grise wrote: > >> > > >> >> If I could get an 8051 equivalent but with Motorola's timer system (see > >> >> 68HC11, e.g.), I'd be in hog heaven. ;-) > >> > > >> > What's so great about Motorola's timers ? > >> > >> It's way, way, easier to use than the 8051's simple little counter. At > >> least I found it to be so. I've done 8051 (8035 + eprom, actually) and > >> 68HC11, and the 68HC11 makes the 8051 look like a boat anchor. ;-) > > > > Can you give an example of how it's easier ? > > I was kinda hoping you're familiar with the respective architectures. Never used Motorola I'm afraid. I'm an Intel ( actually Atmel and NXP man). I did do one job on a Z80 though. > The 8051 has one counter - set it, let it time out, and there's your > interval. ONE time interval per event; then you have to reset it for > the next one, and so on. Ummm, there's 2 counter timers even in the basic 8051 IIRC. > The HC11 (and others by Moto) have a free-running counter (sunc to the > clock, of course) and you set "timer compare" registers, which toggle > the output and trigger an interrupt when the counter reaches that value; > I'm not sure how many of these timer compare register it has, but there > are at least two that I know of, and with a little bit of cleverness, you > can manipulate the registers in the ISR, and have an almost arbitrary > number of events as long as your ISR is quick enough to not block other > interrupts. The "timer capture" input just responds to the timer input > by writing the current value to the timer capture register, which then > your ISR can use at its leisure. ;-) I can see having multiple compares would be nice. There's something similar IIRC in the enhanced 8051 family. But maybe only one of them. Graham
From: Eeyore on 6 Sep 2008 00:40 Rich Grise wrote: > How's the interrupt latency? Did it used to block other > interrupts, or could they be stepping on each other? No interrupt priority and multiple register banks for them to run in a la 8051 ? Oh it is an 8051. Check the priority settings and register banks used, there's 3 spare assuming you use 0 for MAIN. Graham
From: Eeyore on 6 Sep 2008 00:42 Joerg wrote: > Rich Grise wrote: > > On Fri, 05 Sep 2008 17:53:59 +0100, TT_Man wrote: > >> ">> > >>>>>> I think he said it was all written in asssembler <yuk>. > >>>>> On an 8051, asm is really the way to go. The OP was making comments > >>>>> about DPTR so I suspected asm but vagueness of his descriptions > >>>>> sounded like a C programmer who doesn't really know what is going on > >>>>> under the hood. Many C compilers overlay variables on the 8051 if he > >>>>> is doing interrupts in C code he may be running a routine in the > >>>>> interrupt code that overlays one of his variables. > >>>> Not a prayer in hell 100% assembler. :) > >>> Are you using interrupts? > >> Everything is interrupt driven. Processor spends 99% in sleep mode.Int > >> routines set flags and the background processes flags, then goes back to > >> sleep. Dual 3 of 5 uarts are processed with 125uS RTC. > > > > This raises a BIG red flag for me - how long does the uP take to come out > > of sleep mode? How's the interrupt latency? Did it used to block other > > interrupts, or could they be stepping on each other? > > This is done all the time. First time I used the PCON features on a > 88C51 was in the early 90's. You have to make sure it does a controlled > wake up (socks, shoes, brush teeth, etc.) and know the time it takes. > When you build analog/RF stuff where there needs to be radio silence > you've got no other choice. And IIRC, the recent iterations of 8051 variants have improved the sleep etc function. It used to be almost useless. Graham
From: JosephKK on 6 Sep 2008 01:29
On Fri, 05 Sep 2008 06:18:31 -0700, Joerg <notthisjoergsch(a)removethispacbell.net> wrote: >Eeyore wrote: >> >> Joerg wrote: >> >>> Eeyore wrote: >>>> Joerg wrote: >>>>> TT_Man wrote: >>>>>> Anyone using this part experiencing problems? we have used them for 4 years >>>>>> or so. Date codes up to 0705 work ok, 0814 misbehaves....same chip, same >>>>>> software, 0814 doesn't execute properly... >>>>> Did you check the POR situation? Maybe issue a nice long POR and see if >>>>> it'll run? >>>>> >>>>> The POR circuit on most 8051 is %^&#!! <tantrum censored> so I always >>>>> rolled my own. As for BOR, I think many uC designers don't know what >>>>> that means ... >>>> I think Atmel actually do an app note on that. >>> When it comes to POR/BOR I do not trust manufacturers much. Learned some >>> hard lesson in life. >> >> Care to share ? >> > >I don't remember all the gory details but until recently none of the uC >had a decent reset. Weird effects until I rolled my own. I have not had all that much trouble. But i only assumed the common guaranteed attributes of the various versions. It pretty much amounted to where is it going to start trying execute and a sane initial condition code / flag register / whatever and some known state for interrupt processing. |