Hey, what is all this 'off topic' posting?

I've noticed an alarming trend towards posts that are about electronics, rather than politics or cooking.

Please, people, mark any electronics post with "OT", so we don't get confused and start flame wars about the best capacitor or something like that!

--
Regards,
 Bob Monsen

I've been grinding out assembly code all week. There's nothing much to say about that.

John

I wish the good people at Google would get off their arses and include that feature in their newsgroup reader.

Mark

Might I ask why you're using assembler and what the CPU is ?

When there's a reasonably priced high level language alternative I really don't see the point of using assembler.

Graham

p.s. I've used assembler where there was no alternative - audio DSP chip with support only for assembler from the manufacturer.

I wouldnt be worried, its just a passing fad ya know. Just killfile all the "electronics trolls" and they will go away.

--
Regards ......... Rheilly Phoull

Because it's fast, because I know exactly what's going on, and because I like it.

MC68332.

There isn't.

C sucks, and I can get way more performance from assembly. I don't think programming a deep-embedded, realtime thing in another language would save me programming time anyhow; I spend more time pooring over byzantine serial-ADC datasheets, and planning tables and data structures, than I do typing code.

We did have the thing doing basic stuff (configuring the FPGAs, running the basic control and IRQ loops, doing VMEbus dual-port memory accesses, blinking LEDs) about two hours after we got the prototype from manufacturing. Now I'm tracing my way through D-sized drawings of data structures, FPGA register maps, and flow diagrams trying to make it work. The customer called Friday and told me he would buy a bunch more if only I can make it four times as fast as we'd planned for.

John

Only if you've never heard of a macro.

Yep, and 'C' isn't any better than it was thirty years ago.

--
  Keith

On the 68K, I'd multiply by 8 then multiply by 0.5375:

ASL.W # 3, D0 MULU.W # 35226, D0 SWAP.W D0

which takes a microsecond or so, and seems better than linking a floating-point library.

But I'd probably lowpass filter the temperature data first, which would be a few more lines of code and might actually get 0.1 degree resolution, if the adc is noisy enough.

John

Suicide is always a viable option. Or murder.

Yup. It's always best to do both.

John

--
OK.

;Motorola 68HSC705C8A:

Here we go, another C versus ASM war.

I use AVR a lot and Atmel is forcing me into using C, all new ANs are using C.

Than again, the bootloader in C is writing all over the SRAM section of atmega screwing up my cunning memory backup plan in process, even when it just checks the pin and jumps to the reset vector. :(

With asm you always know what to expect, with C its a guessing game.

--
Siol
------------------------------------------------

"SioL" schreef in bericht news:eOCSe.66$ snipped-for-privacy@news.siol.net...

Rewrite them in ASM if you must.

With asm you know you will need 10 times more time to deliver 1/10th of the functionality. Use it for those two highly optimized loops you need, but for all other stuff, forget it. It's 2005.

--
Thanks, Frank.
(remove \'q\' and \'.invalid\' when replying by email)

Not at all. I'm no fan of C. I was actually offered a job coding in C back in

1984 - it was a publishing application - long before Adobe got into that stuff - maybe long before Adobe even existed ! It was an inhouse piece of software that took files from WordStar typically ! ;-)

I took one look at C code and syntax and 'ran away' - lol !

To this day I reckon that C / C+ / C++ is deliberately obscure so to as to impress the PHBs.

I like 8051s and their variants. I use PL/M 51. It's a lovely language to use but sadly Intel abandoned it. As easy as Basic to understand but with the ability to talk to registers ( and indeed any other hardware you like ) directly if you need to. Not to mention some damn useful commands that are assembler-like such as ROL.

PL/M code is never obscure. It's quite the reverse.

And then there's the PL/M compiler's skill in using available free RAM to its best wrt to lifetime dependent variables. I doubt any asm coder could match that !

Graham

I sometimes use the 'show code' function with PL/M to see what asm has been generated by the compiler.

Invariably it produces code that's very efficient and I don't have to worry about it.

Best example I've come across comes to mind. 8031 with 12MHz crystal. Interrupt service routine needs to compare 2 x *16* bit numbers and return a conditional result.

It took ~ 70 us including the vectoring in and out overhead.

Even better. I deliberately sent interrupts at greater than the interrupt service routine's period. You might expect a 'lock-up'. Not so. Reduce the interrupt rate and normal service is restored !

Now beat that hand coding in asm !

Graham

It's a 16-channel isolated DAC module, mainly intended to simulate thermocouples, but capable of up to +-12.5 volts out. We used a 16-MHz CPU running code out of a single 8-bit EPROM because we figured, how fast can a temperature change? So now the customer wants it to operate in voltage mode, fast.

So R. claims he can take over the DAC calibrations (one 16-bit signed fractional multiply and one add, per channel) and the dac-load state machine in the FPGA to save me lots of microseconds per channel and, sure as hell, it works. He even claims 1/8 LSB rounding accuracy. The

18x18 multiplier in the FPGA has a prop delay of 6 ns!

Next, after tweaking the code as much as is decent, I'm going to copy the critical loops from eprom into fast CPU-internal 16-bit RAM, and run it there. It's easy to write pic (position-independent code) on a

68K.

I've asked a couple guys if it's feasible to relocate C-compiled code like this, and they say it depends on the compiler but it's not really obvious. In assembly, it's easy.

John

In article , Pooh Bear wrote: [....]

No, I would not expect a "lock up" the nature of the 8031's interrupt hardware limits the nesting depth to 2. You only can get two if you set the priority register to make one have a higher priority than the other.

Using ASM code I have often had interrupts nested much deeper than this using a coding trick. The deepest I have happening on the current project is limited to 10. Beyond 10, the interrupts will be missed.

Now beat that in "C".

--
--
kensmith@rahul.net   forging knowledge

In article , keith wrote: [...]

You missed an obvious argument. I spend at least as much time on designing the system as typing in code. If coding in C was infinitely fast, it could only save me about half the time.

Example:

How do I store temperature?

The ADC input gives me an LSB of 0.43 degrees C.

I have to be able to display the value easily so I select, 0.1C increments.

The highest temperature I need to deal with is 100C. That is 1000, 0.1C increments.

I get zero from the ADC for all temperatures below 0C, so positive values are all I need.

As a result, a 16 bit unsigned will work for temperature.

Now given the ADC input, what is the fastest way to turn the raw number into my units?

the LSB from the converter is worth 4.3 in my numbering system.

The 4 part is easy. The 0.3 part is ging to take a little thinking.

.... etc ....

BTW: a table look up is the way to go if you've got the space.

--
--
kensmith@rahul.net   forging knowledge

The two measures of software speed:

1. How fast does it run?
2. When will you be done?

[snip]

Well, to be honest, that sounds quite easy.

--
Thanks, Frank.
(remove \'q\' and \'.invalid\' when replying by email)