C vs. asm question for a project

Thread Starter

rockrockmcrock

Joined Jan 6, 2012
19
Guys - do you have any advice on the best way forward, should I use c or asm?

Basically I'm a beginner with real-time / microcontrollers, but have loads of HL programming experience and some asm for x86 (and BBC Micros from back in the day!).

I figure the best way to learn is to mess about with someone else's project code. The code is well commented mpasm and will need to be ported from Pic 16F to 18F either now (big ask for a newbie like me?) or later to give me the memory space / libraries.

So from what I know of x86 asm, I'm tempted to learn C and port the mpasm to that - readability, debug time and portability are things I usually value in HL code. There are IRQ's in the mpasm code and I know C used to struggle to implement these way back, but I presume things have changed. Hence I'm tempted to go with porting to C, before porting to the 18F.

I've read loads of stuff on the web about C vs. asm, but am still none the clearer - some say C some say asm! I don't want to start another C/asm war - but what's the recommendation from someone with experience? I should pick up both languages fairly fast and will need to learn both anyway at some point.
 

ErnieM

Joined Apr 24, 2011
8,377
I've read loads of stuff on the web about C vs. asm, but am still none the clearer - some say C some say asm! I don't want to start another C/asm war - but what's the recommendation from someone with experience? I should pick up both languages fairly fast and will need to learn both anyway at some point.
Yeah asking to use either C or asm will start a war. I know both, far prefer C for the infinite increase in productivity for large projects... though I do occasionally have the small project where only hand optimized asm can run fast enough.

When I started doing PICs asm was the only choice. There may have been a compiler but they were rare and very expensive. Now you can download free versions, and although they skip all the cleanup steps (so they make larger code) and don't optimize anything they are good tools.

Microchip gives away the Microchip Applications Library (MAL) and since it is C it needs no conversion from '16 to '18 (which is a big jump anyway).

My thoughts on development boards & programmers are here:
http://forum.allaboutcircuits.com/showpost.php?p=503555&postcount=33
 

takao21203

Joined Apr 28, 2012
3,702
ASM is the stuff nobody is using for quite a long while now.
Except "at home", beginners, education and the like.

Thinking of a need to optimize with assembler is the wrong approach.
Choosing a more powerful chip is the solution.

Do you think a digital camera is using assembler? Or a modern computer game? Wrong. They use specialized hardware, and special instruction sets like MMX. And a digital camera has a controller with some 50 to 200 MHz to deal with the data flow.

Assembler takes 10x to 15x the efforts. Programmers are even proud of these efforts and treat their work as art. It is not meant to be art. Programming is an ordinary trade. C programming for the most of it is quite mechanical. The compiler and preprocessor can do a lot of primitive things for you.

Assembler is no longer used professionally since the early 1980s.

Microchip (as for PICs) used it for their early 16F chips, but it does no longer play an important role.

If experienced programmers use a few short pieces of ASM in larger programs, it is totally different compared to beginners wriiting the complete program in assembler.

You would experience anything larger than 4K is a nightmare to maintain, and to read and understand it again even yourself.
 

Thread Starter

rockrockmcrock

Joined Jan 6, 2012
19
Thanks guys!

The conclusion I came to was that the only reason to use asm was if speed of execution or memory limits required it - your comments kind of confirm this!

Is the 18F suited to C? Not knowing about PICs, I had figured out 18F was kind of on that "memory limit" borderline between C and asm if you wanted to write reasonably complex programmes (e.g. SD card access, basic LCD graphics). I'm kind of limited to 8-bit for my area of interest while I learn.

I'm also assuming porting asm to C and getting it to work on the 16F, before porting the C code to the 18F is the way I should go, rather than porting 16F asm to 18F asm and then into C. Trouble is I'm basing this on reverse engineering HL programmng experience so I may be way off base! Any suggestions welcomed :)

Also how difficult is it to include library's written in asm in C programmes - I'm presuming it's very simple (#INCLUDE type simple), but is there something I don't know?

Sorry for all the stupid newbie Q's and cheers guys, great comments and pointers - much appreciated!
 
Last edited:

John P

Joined Oct 14, 2008
2,025
Microchip says about the 18F processors, "optimized for C programming". But most people would say you'd be crazy not to use C on the smaller processors too. Assembly might be more efficient for the processor, but it's a lot less efficient for the human who has to deal with the processor, and typically it's the human who costs more.

If you really must do it, yes it ought to be fairly easy to use ASM routines in C code, though ASM for the 16F series would have to be rewritten for the 18F series and once you contemplate doing that--why not do it right?
 

takao21203

Joined Apr 28, 2012
3,702
I have done a LED matrix displaying the data from I2C sensor- scrolling it through actually as text. Though it takes 90% of the 2K memory the 16F59 provides. XC8 compiler, not optimized.

I have also written a LED matrix text message scroller in assembler. It is ridiculous. Even if I use a 16f1824 which has 2 file registers.

Dispose off any assembler you can.

16F or 18F makes no difference for most people, of course 18F is faster and has larger memories.

Most of the original 16F PIC controllers I consider as museum stuff. Except the 16f5x because their easy configuration + low cost.

The other 16Fs with pheripherals have enhanced midrange 16F replacements. Always take care to use enhanced midrange unless you specifically know that original 16F PIC and have reasons to use it.

16F is not vintage- there are brand new 16F USB PICs- believe it or not. I have a few here but have not yet tried them.

Or use 18F makes no difference for most people (except many of them are 3.3V)

The enhanced midrange has so many advantages it is worth to download the brochures from Microchip and have a look at the information.
 

ErnieM

Joined Apr 24, 2011
8,377
Funny you mention SD cards and graphics as your intent. I wrote(in C) some nice code for a B&W graphics screen but the cost of a color screen became comparable... So I ditched all that work andjust use the graphics library Microchip provides. Same with SD cards.

SD card code is about 30k long so it needs a big PIC18 to handle it. For graphics I jumped over to a PIC32.

I can see no reason to port asm to C.
 

MrChips

Joined Oct 2, 2009
30,618
If you want to interface with SD cards, graphics, camera, USB, TCP/IP etc. then the raspberry pi is the way to go.
 

takao21203

Joined Apr 28, 2012
3,702
If you want to interface with SD cards, graphics, camera, USB, TCP/IP etc. then the raspberry pi is the way to go.
For instance. It has 700 Mhz. Which is quite a lot and needs to be powered. There are also interesting dev. boards from Freescale and ST.

I think the new STM32 board has some 170 MHz (from a 4 MHz crystal via PLL).

Embedded technology is not the same thing as single board computers (which the PI is accounted for).

It is more kind of battery powered circuits which can be very small, and don't neccessarily deal with high resolution graphics.

If you are unsure, take a good look at the product brochures, and get some dev. boards

The PI is more kind of a allround single board computer aimed at modern students. You would not always want to bury it into an embedded solution, even if they are economically priced. You could not really run a PI from a button cell. If you just want a LED message scroll, yes you can use a PI, you could use a SD card- but both are way overdimensioned.

Have all sorts of dev. boards around but then scale exactly to the solution you need. I mean be able to do that!

Porting asm to C is an exceptional case. It will often be more appreciate to code it from zero in C. And it will take less effort all together.
 

Thread Starter

rockrockmcrock

Joined Jan 6, 2012
19
Porting asm to C is an exceptional case. It will often be more appreciate to code it from zero in C. And it will take less effort all together.
Yeah this is usually the case of HL code as well - porting Delphi to C~ pr VB to C++ usually just means rewriting the software once you've understood he functions.

Funny you mention SD cards and graphics <snip>

I can see no reason to port asm to C.
The reason for a port, is that I have kindly been provided with some original commented mpasm code for a bespoke protocol I2C slave using a 16F chip. I now understand 99% of the protocol, but the original code uses EEPROM for storage and I figure SD card flash is the better modern solution. The temptation is to port the slave part and rewrite the EEPROM read/write routines to use SD. It's starting to look to me like this approach is a false economy though! Fear of the black art of real-time programming is probably at the heart of it - I should know better, but I was hoping I could use this project as an easy start into more complex pic programming....

If you want to interface with SD cards, graphics, camera, USB, TCP/IP etc. then the raspberry pi is the way to go.
Strange you should say that....had my eye on one for a future unrelated project. For this one it's overkill and too large for the physical size constraints. I'm into hacking stuff to make my life easier in my other hobbies. This is a hack for memory in UAV setup transmitter side the only visual output will be a 7 segment LED or couple of LEDs. I'm figuring something like a pic18F26k22 or similar has enough grunt to handle SD + I2C slave + visual LED output - I'm only thinking of PIC because there seems so much info out there for a beginner.

The future graphics stuff is likely to be a v small screen with some data readouts for telemetry backed by a graph or two - seems I'll need to move on from 18F for this though. Another reason to move to C then :)
 
Last edited:

takao21203

Joined Apr 28, 2012
3,702
Yeah this is usually the case of HL code as well - porting Delphi to C~ pr VB to C++ usually just means rewriting the software once you've understood he functions.



The reason for a port, is that I have kindly been provided with some original commented mpasm code for a bespoke protocol I2C slave using a 16F chip. I now understand 99% of the protocol, but the original code uses EEPROM for storage and I figure SD card flash is the better modern solution. The temptation is to port the slave part and rewrite the EEPROM read/write routines to use SD. It's starting to look to me like this approach is a false economy though! Fear of the black art of real-time programming is probably at the heart of it - I should know better, but I was hoping I could use this project as an easy start into more complex pic programming....



Strange you should say that....had my eye on one for a future unrelated project. For this one it's overkill and too large for the physical size constraints. I'm into hacking stuff to make my life easier in my other hobbies. This is a hack for memory in UAV setup transmitter side the only visual output will be a 7 segment LED or couple of LEDs.

The future graphics stuff is likely to be a v small screen with some data readouts for telemetry backed by a graph or two - seems I'll need to move on from 18F for this though. Another reason to move to C then :)
I don't think SD cards are a good match for small controllers. The GBytes are never used. OK the capability is there to read them via a PC. And the software does exist as well?

Use serial FLASH chips, make your own small card/plugable module. These chips from SST have 16 Megabit for instance, and cost less than $1.

Build a small USB writer for them, using these new 16F USB PICs. Smart in my opinion. SD sockets are not foolproof, they can fail and corrupt your card.
 

Thread Starter

rockrockmcrock

Joined Jan 6, 2012
19
I don't think SD cards are a good match for small controllers. The GBytes are never used. OK the capability is there to read them via a PC. And the software does exist as well?

Use serial FLASH chips, make your own small card/plugable module. These chips from SST have 16 Megabit for instance, and cost less than $1.

Build a small USB writer for them, using these new 16F USB PICs. Smart in my opinion. SD sockets are not foolproof, they can fail and corrupt your card.
Couldn't agree more mate - at least with my limited knowledge. Could you comment on the plan below please - you've got me wondering if SD is the way to go with your last statement.

In my 'plan' the SD card is mainly there to allow backup/restore of memory to a PC or when mobile to a portable smart device (that's assuming I can get the FAT32 system to work). It seriously sucks when you lose the memory settings on existing memory modules.

I could do this I guess with a USB interface, but I'm nervous about this - perhaps wrongly - both because of the programming and the addition potential power source in the circuit. SD card seemed simpler and cleaner.

The EEPROM of the original memory stays as per the original circuit, just at a smaller capacity and now partly within the PIC. The plan is to use this for real-time read/write and then (when required) write it to the SD for backup purposes or read another memory block from SD to the EEPROM when you want alternative settings. Both the EPPROM to SD read/write functions take place when the UAV is not 'live' - i.e. it's on the ground, it's only EEPROM to I2C transmitter interface that takes place on a 'live mission' basis. The downside of using SD is that the memory for missions is only 64kb (not 64kB as I orginally supposed due to Farnell spec sheets - doesn't any company use the correct uppercase/lowercase 'b' conventions anymore to differentiate bytes and bits? Grrr....) so that's 1/8 of a sector and a lot of garbage to write to get FAT compatible files.
 
Last edited:

thatoneguy

Joined Feb 19, 2009
6,359
I don't think SD cards are a good match for small controllers. The GBytes are never used. OK the capability is there to read them via a PC. And the software does exist as well?
They are excellent for loading animations, or saving logged data that can be read or written by a PC. Don't really need a 16GB one, but 256MB of text data is a long time logging. Simply swap in a new one, and read the old one while it continues to log.

There are several applications where an SD card is useful, but I wouldn't put it in my "Top 10" of uC accessories.

The power of 8 bit uCs is impressive, very few are fully utilized, most are clocked well below their rated speed for power considerations. Smallest(Cheapest) uC that can run the code, at the slowest clock that can run it. For non-embedded applications, such as a computer, that changes entirely.
 

ErnieM

Joined Apr 24, 2011
8,377
It never bothered me to waste gigabytes, I just call it "reserve capacity." I've mixed USB and SD cards a few times, initially for data logging, later for boot code storage where the app was intended to change.

While large the Microchip libraries do full FAT support. PetiteFS seems much smaller but I've never invest the time to get that code working.
 

John P

Joined Oct 14, 2008
2,025
Another thing SD cards are good for is storing sounds (WAV files or the like). If you have a replaceable card, the non-technical user can install a choice of them, maybe with files loaded from a PC. It makes products like this possible (though this doesn't actually have a PIC):
https://www.sparkfun.com/products/11125
 
Top