Common abstract Driver for AVR, PIC, MSP430..

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

Does anyone know a common/abstract IO (driver) library for various MCUs (AVR, PIC, MSP430..)?
e.g. setting:

#define MCU_TYPE     AVR     /* or PIC, MSP430... */

Then:

IO_Lib_Set_Pin( COMMON_PORT1, PIN1, HIGH);

The driver should be in ANSI C (gcc) compatible and small as possible (lot of compiler switches).

As you know the goal is platform independence, so time to market can be reduced.

Thanks,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
As you know the goal is platform independence

How do you imagine a timer API compatible with PIC, AVR and MSP430?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's not a big deal, TMR_Set_Div, start, stop, get..
This how big companies do it.
I'm looking for an open source equivalent.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An arduino style compiler is your best bet I think , I have seen both AVR and pic boards that can be programmed with the same code

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice concept, but arduino is not for industrial apps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Nice concept, but arduino is not for industrial apps.

A comment like that suggests you really don't know about arduino. The reality is that it does what you ask. It is basically a set of libraries for a number of platforms and the magic is covered up. MBED is basically the same thing.

The only criteria these fall down is that they are c++

so tell me why you couldn't write an "industrial" app with Arduino?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, no one can convince me that c++ is ok for 8bit MCU with 8k flash. Overhead, speed etc.

I look into the arduino library, if that has various platform implementations, but I will have to convert it to C.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Convince yourself - write the code in c and compare. A lot of the arduino code is just c with a wrapper anyway. There are things you can do in c++ that are truly horrendous for a little cpu but for the most part you're using c++ to make things a little simpler vs c in terms of the syntax. The generated code may be the same in many instances.

If you have an existing piece of code in c, try converting it to arduino and see the differences. Look at the map file to find the generated size for each of your functions. Then decide. If there is apremium to be paid for using c++, you can then decide if the advantages are worth the cost. Similar arguments for asm vs c.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the heads up, I was looking for an EC++ solution,
but I will keep the driver level in C for portability, and maybe use arduino for upper layers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Overhead, speed etc.

here we go again...

What specific constructs in C++ have these deficiences? What overhead are we talking about? What speed problem.

Look around. Search the net just a wee bit. C++ has no inherent thing that makes if less efficient than plain old C. A feature not used in C++ will cost you nothing. A feature used in C++ will have similar "costs" as if you where to do it in plain old C. All this is re the language C++.

Any compiler constructor can screw up. If you know of a specific compiler which has a bad implementation of code generation etc for C++ then please tell us which one it is.

I fear your statement reveals an ignorance re C++ more than anything else.

We've had this discussion here many times before. I am prepared to have it once more, but it would be easier if you just searched out the previous threads.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

This how big companies do it.

Err no. No it isn't.

(not sure if the company I worked for worth $3bn and with a typical product run of 2m..3m units per product counts as "big"?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Err no. No it isn't.

Can you tell us what concept are you using?
I guess you don't rewrite the whole platform layer when you switch MCU brands.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We target a product to a particular architecture and write efficient code for that CPU. HALs generally waste efficiency.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If we're talking about a 8k part, then the effort needed to create the code isn't too high. Depending on the app, the hardware dependent stuff isn't too big. The cost in this instance would be doing a new board spin, re-verification and re- certifying it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Nice concept, but arduino is not for industrial apps.

Hmm. A "common abstract library" may not be suitable for industrial apps, either. I mean, that is what Arduino *is*; you may disagree with the way that they've abstracted things, or complain about the speed or performance of a particular abstraction implementation, but it IS an example of what you're asking for.

(Frankly, the other attempts that I've seen (ASF, CMSIS) seem to have quite similar "problems", despite their "professional" origins. Too much abstraction for not enough benefit. Maybe.)

You might check out one of the big multi-platform compiler vendors (IAR, Keil?) and see whether they provide common peripheral apis...

Maybe what we need is for some C++ wizard to do a template-level abstraction of common things... The whole uart configuration abstraction like:

 const sam_usart_opt_t usart_console_settings = {
USART_SERIAL_BAUDRATE,
USART_SERIAL_CHAR_LENGTH,
USART_SERIAL_PARITY,
USART_SERIAL_STOP_BIT,
US_MR_CHMODE_NORMAL
};

usart_init_rs232(USART_SERIAL, &usart_console_settings);

seems important, but ends up being making for horrible code. If I understand things, I ought to be able to do some template metaprogamming and have

uart_begin(&USART1, "9600,N,8,1");

and have it produce the same inline set of load/stores I'd do in assembly language. Doing this for AVR would be pretty pointless, but if you could get enough agreement on how it should look, and implement it on a significant SET of processors...

OTOH, features bite you. I'm not even sure there is enough commonality between the various types of timers available in AVRs to implement a useful abstraction. By the time you try to make the "TIMERB with 3 or 7 CCRs" on an MSP430 behave like an 8bit timer by using up one of the CCRs, you might as well give up. (ARM had the right idea by separating out the "systick" timer and making it part of the core specification.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
uart_begin(&USART1, "9600,N,8,1");

I looked into this a bit further. Apparently "Template Metaprogramming" doesn't handle strings very well, but i didn't have much trouble getting this:

Disassembly of section .text.startup.main:

int main()
{
    uart_init<9600, EVEN, 8, 1>::init();
    return 0;
}

    static inline void init(void) {
	UBRR0H = baudreg >> 8;
   0:	10 92 c5 00 	sts	0x00C5, r1
	UBRR0L = baudreg;
   4:	8f ec       	ldi	r24, 0xCF	; 207
   6:	80 93 c4 00 	sts	0x00C4, r24
	UCSR0A = 1<<U2X0;
   a:	82 e0       	ldi	r24, 0x02	; 2
   c:	80 93 c0 00 	sts	0x00C0, r24
	UCSR0B = (1<<RXEN0) | (1<<TXEN0) | datbits2;
  10:	8c e1       	ldi	r24, 0x1C	; 28
  12:	80 93 c1 00 	sts	0x00C1, r24
	UCSR0C = parbits | sbits;
  16:	80 e2       	ldi	r24, 0x20	; 32
  18:	80 93 c2 00 	sts	0x00C2, r24

  1c:	80 e0       	ldi	r24, 0x00	; 0
  1e:	90 e0       	ldi	r25, 0x00	; 0
  20:	08 95       	ret

Surely this has already been done?
How about https://github.com/pfalcon/Perip...
I guess there's a problem in that not many people are interested in maintaining such a thing across multiple architectures (and testing would be annoying.)