89C51ED2
in [Design]
|
From: TT_Man on 6 Sep 2008 06:15 >> >> >> 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. > > I think you need to look very carefully at the interrupt code to make > sure that it doesn't forget to save part of the context. This sounds > like it is either timing related or an uninitialized flag. No. The code runs perfectly in old date code devices and has been in production world wide for 15 odd years in one form or another.
From: TT_Man on 6 Sep 2008 06:18 "> > 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 AMEN to nice source code :)
From: TT_Man on 6 Sep 2008 06:22 >> > 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. >> >> I do it all the time. It takes less time to write the code than to >> design it. Any competent engineer can maintain it. > > I'll send you some code shall I ? > > ASM is for twits, the clueless, poor and morons mainly AFAICS. > > I don't mind checking the asm output of PL/M to see how it's done it > though. Never been > unsatisfied. > > Graham Try writing a USB front end in C or any other HLL and see if you can get it to work........ :)
From: Eeyore on 6 Sep 2008 11:14 TT_Man wrote: > > LOL ! > > > > All too easy by half and don't forget you have only 4 register banks to > > play with, meaning only only 3 simultaneous interrupts. of various > priorities. > > > > Graham > > > Not true, with careful innovative Int. structures Bloody careful I should think. Graham
From: Eeyore on 6 Sep 2008 11:17
TT_Man 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. > >> > >> I do it all the time. It takes less time to write the code than to > >> design it. Any competent engineer can maintain it. > > > > I'll send you some code shall I ? > > > > ASM is for twits, the clueless, poor and morons mainly AFAICS. > > > > I don't mind checking the asm output of PL/M to see how it's done it > > though. Never been unsatisfied. > > Try writing a USB front end in C or any other HLL and see if you can get it > to work........ :) Never been tempted by C. Doubt it would be a prob in PL/M. Graham |