Author Topic: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)  (Read 16127 times)

0 Members and 1 Guest are viewing this topic.

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #25 on: October 05, 2015, 10:44:15 am »
An example or many examples of badly written HAL API do not mean that all HAL API have to be bad  ;D

ST's API is very low level. Most of them boil down to instead of writing a line or two in C that modifies an I/O register, you get to write it as a function call! Oh Joy! Talk about pretty useless.

At least there are some useful ones such as the ones that calculate the baudrate etc.

And I am not a fan of creating "init" struct just so that a user gets to learn another struct, so that it can be used to initialize the low level I/O register "structure" - just make the API takes (sensible) arguments and be done with it.

CubeMX could be nice for initialization code but does nothing about writing code afterward.

   
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Online Karel

  • Super Contributor
  • ***
  • Posts: 1432
  • Country: 00
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #26 on: October 05, 2015, 02:52:30 pm »
Usually dev-time is more expensive than a bigger chip... YMMV.

In a professional environment, this is usually not the case. At least not in case your design is going to be produced in large quantities...

It's another story when you work in an academic or research environment.

 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #27 on: October 05, 2015, 08:10:51 pm »
These are some of the reasons we decided to use a C++ Style / "C with Classes" for our JumpStart API. The separate name space inherent with objects mean that we can use similar or same names for different objects, without arbitrarily adding a module prefix or suffix. It makes the program easier to read and maintain.

As for full C++, 10 years ago, C++ was suppose to "take over" the embedded world, however the reality is that most embedded engineers are hardware folks, even for the 32-bit chips with more memory. According to embedded.com survey, C users remain at more or less 50% of the embedded programmer population, and C++ users indeed has not increased after the initial ramp and in fact has dropped slightly in the last few years.

I am sure studies can be made to discover all the reasons why, but in this case, the users have spoken.

...

Also I think calling methods with good names is a LOT more readable than poking bits in and out of abstractly named memory locations. Details in the datasheet can be taken care of by the library (up to a certain level). The idea would be to create an API that is intuitive enough to get 80% of the code going in 20% of the effort.

Leave that C++ rubbish for PC bloatcode programmers.
Yes, I have come to realize that most coders of embedded systems are a little allergic to C++. For me it is the way I think about software problems - in objects. And it is true that adding layers of abstraction will induce extra cost on hardware resources - but it also *should* make development faster, easier and have less bugs. Usually dev-time is more expensive than a bigger chip... YMMV.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline targ2002

  • Contributor
  • Posts: 11
  • Country: gb
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #28 on: October 05, 2015, 08:51:35 pm »
These are some of the reasons we decided to use a C++ Style / "C with Classes" for our JumpStart API. The separate name space inherent with objects mean that we can use similar or same names for different objects, without arbitrarily adding a module prefix or suffix. It makes the program easier to read and maintain.

As for full C++, 10 years ago, C++ was suppose to "take over" the embedded world, however the reality is that most embedded engineers are hardware folks, even for the 32-bit chips with more memory. According to embedded.com survey, C users remain at more or less 50% of the embedded programmer population, and C++ users indeed has not increased after the initial ramp and in fact has dropped slightly in the last few years.

I am sure studies can be made to discover all the reasons why, but in this case, the users have spoken.

...

Also I think calling methods with good names is a LOT more readable than poking bits in and out of abstractly named memory locations. Details in the datasheet can be taken care of by the library (up to a certain level). The idea would be to create an API that is intuitive enough to get 80% of the code going in 20% of the effort.

Leave that C++ rubbish for PC bloatcode programmers.
Yes, I have come to realize that most coders of embedded systems are a little allergic to C++. For me it is the way I think about software problems - in objects. And it is true that adding layers of abstraction will induce extra cost on hardware resources - but it also *should* make development faster, easier and have less bugs. Usually dev-time is more expensive than a bigger chip... YMMV.
I think that the reason a lot embedded sw devs don't use c++ is that it is harder to prove that there are no software bugs. This is especially important where you are talking about safety critical code or where it is difficult to upgrade the sw on the device.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3123
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #29 on: October 06, 2015, 01:31:17 am »
Quote
As for UART vs. USART, if you are using only UART functions, no need to bring in USART.
IIRC, ST ARMs have two separate peripherals at the hardware level (UART and USART; they might require different APIs (although, glancing quickly at the STM32f1xx manual, they have identical register definitions, so perhaps it's just a pinmux difference?)


Quote
Leave that C++ rubbish for PC bloatcode programmers.
The thing is, there are some C++ features  that would REALLY HELP this sort of code, and they're NOT ones that cause bloat.  In particular:
1) Function Overloading
    Function overloading allows multiple functions to be defined with the same name, as long as they have different parameters.
    This means that instead of having a function "USART_init(struct uart_config_params *confg);", where uart_config_params contains all of the parameters needed to initialize the USART in any possible mode supported by the hardware (IRDA, LIN, RS485, synchronous, async, etc) and then having USART__init() have a giant case statement handling all those possible cases, a HAL library could define multiple smaller functions:
Code: [Select]
   USART_init(struct async_usart_config_params *config)
   USART_init(struct irda_usart_config_params *config)
   USART_init(struct lin_usart_config_params *config)
   USART_init(struct rs485_usart_config_params *config)
   USART_init(struct sync_usart_config_params *config)
Each one of those wouldn't have to contain code that implemented the others, and they could still share common code.  (Now, it turns out that the STM32 usart code isn't so bad, but the above example of lumped features is from Atmel's ASF, so it's still a real problem.)  Runtime cost: zero.

2) Templates and Template Meta Programming
As I understand it, this is essentially the pre-processing language that C should have had years ago, rather than sticking to the "all the preprocessor does is text substitution" crock that is what we have.  With a bit of effort, templates can give you the sort of "optimize away all these things because their values are constant an known at runtime" that would require a really ugly combination of C preprocessing and non-standard inlining features, without being ugly, or non-standard.  Runtime cost: zero (less than zero, really, since it will generally replace run-time decisions with compile-time decisions.)

Now, the big danger (IMO) is that C++ programmers DO come from a desktop/server environment, and don't tend to be very aware of when they are or are not introducing extra overhead.  You're likely to get "why wouldn't I use an STL container for my FIFO?" (because that implementation assumes and uses dynamic memory allocation!) and similar. 
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6616
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #30 on: October 06, 2015, 03:22:13 am »
2) Templates and Template Meta Programming
As I understand it, this is essentially the pre-processing language that C should have had years ago, rather than sticking to the "all the preprocessor does is text substitution" crock that is what we have.  With a bit of effort, templates can give you the sort of "optimize away all these things because their values are constant an known at runtime" that would require a really ugly combination of C preprocessing and non-standard inlining features, without being ugly, or non-standard.  Runtime cost: zero (less than zero, really, since it will generally replace run-time decisions with compile-time decisions.)
Actually, templates are a known bloater since they let you easily generate huge amounts of nearly-identical code very quickly.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3123
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #31 on: October 06, 2015, 05:56:00 am »
Quote
templates are a known bloater since they let you easily generate huge amounts of nearly-identical code very quickly.
Differently than the combination of macros and inlines that I was claiming it would replace?
yes, I supposed that you have to be careful how you use them; but they're not inherently bloaty...
 

Online Karel

  • Super Contributor
  • ***
  • Posts: 1432
  • Country: 00
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #32 on: October 06, 2015, 06:20:32 am »
A bit outdated but still (mostly) valid:

http://harmful.cat-v.org/software/c++/linus

 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #33 on: October 06, 2015, 06:54:18 am »
Ah, good ol' Mr. Torvalds

"*YOU* are full of bullshit..." ha ha, he holds no punches.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12084
  • Country: gb
    • Mike's Electric Stuff
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #34 on: October 06, 2015, 07:19:14 am »
I'm amazed at how many toolchains, don't, by default, omit any unused functions. It's a total no-brainer for producing efficient code
There are occasions where you need to force inclusion of apparently un-called functions, but this should be done explicitly, not by default.

For something as simple as a UART, it will usually be quicker and easier to code it form scratch rather than trying to learn, understand (and if you're unlucky, debug) a HAL library which will inevitably include functionality you don't need. 

The only time I've looked at CMSIS, it was on a NXP part, and it contained a ridiculous amount of code (including a big lookup table) to set up peripherals & clocks from compile-time constants using run-time calculations instead of compile-time as it should have been.
And it had a nasty PLL setup bug that made it sometimes hang on startup.
 
An issue that stands in the way of doing things optimally here is that C's preprocessor is rather limited in doing the sort of things you sometimes need to do this sort of thing properly, like loops.

HALs are useful for complex stuff like filesystems, USB, networking etc. but to use them by default for simple functionality like IO setup, UARTS etc. is often going to be a really bad idea. How often does anyone really port code to different processors? And on those occasions what are the chances that the HALs will still be compatible?

And consider who will be writing those HALs at a device manufacturer - probably one step up from the poor sucker/intern who's tasked with writing device-specific header files.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #35 on: October 06, 2015, 08:36:08 am »
I don't want to make it sound like a commercial, but this is how you initialize the UART using JumpStart API:

    usart2.SetPins(&porta, 2, 1, &porta, 3, 1);
    usart2.MakeUSART(9600, 8, 1, true);

    printf("\r\nImageCraft JumpStart MicroBox... System running at %dMhz\n", jsapi_clock.GetSysClkFreq() / 1000000);

...And printf works. "SetPins" specifies the pins and the ST alternate function codes. MakeUSART specifies the UART protocol parameters.

I will be adding ring buffer interrupt driven support in the next week or so.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 465
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #36 on: October 06, 2015, 02:44:13 pm »
I'm amazed at how many toolchains, don't, by default, omit any unused functions. It's a total no-brainer for producing efficient code
There are occasions where you need to force inclusion of apparently un-called functions, but this should be done explicitly, not by default.

For something as simple as a UART, it will usually be quicker and easier to code it form scratch rather than trying to learn, understand (and if you're unlucky, debug) a HAL library which will inevitably include functionality you don't need. 

The only time I've looked at CMSIS, it was on a NXP part, and it contained a ridiculous amount of code (including a big lookup table) to set up peripherals & clocks from compile-time constants using run-time calculations instead of compile-time as it should have been.
And it had a nasty PLL setup bug that made it sometimes hang on startup.
 
An issue that stands in the way of doing things optimally here is that C's preprocessor is rather limited in doing the sort of things you sometimes need to do this sort of thing properly, like loops.

HALs are useful for complex stuff like filesystems, USB, networking etc. but to use them by default for simple functionality like IO setup, UARTS etc. is often going to be a really bad idea. How often does anyone really port code to different processors? And on those occasions what are the chances that the HALs will still be compatible?

And consider who will be writing those HALs at a device manufacturer - probably one step up from the poor sucker/intern who's tasked with writing device-specific header files.

Good points and thank you for staying on topic!
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12084
  • Country: gb
    • Mike's Electric Stuff
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #37 on: October 06, 2015, 04:14:24 pm »
I don't want to make it sound like a commercial, but this is how you initialize the UART using JumpStart API:

    usart2.SetPins(&porta, 2, 1, &porta, 3, 1);
    usart2.MakeUSART(9600, 8, 1, true);

    printf("\r\nImageCraft JumpStart MicroBox... System running at %dMhz\n", jsapi_clock.GetSysClkFreq() / 1000000);

...And printf works. "SetPins" specifies the pins and the ST alternate function codes. MakeUSART specifies the UART protocol parameters.

I will be adding ring buffer interrupt driven support in the next week or so.
OK now make it run at 4Mbaud, do on-the-fly ID filtering, packet framing and receive double-buffering.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #38 on: October 06, 2015, 05:01:59 pm »
Ah, good ol' Mr. Torvalds

"*YOU* are full of bullshit..." ha ha, he holds no punches.

And he's completely correct about Boost, which remains shite.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #39 on: October 06, 2015, 06:54:04 pm »

OK now make it run at 4Mbaud, do on-the-fly ID filtering, packet framing and receive double-buffering.

Dear Mike, our goal for the design (of most of our tools) is mainly "what do 95% of the users need/want 95% of the time?" I will do some research and see which parts of your suggestions fall in those categories.

Thank you for your comments.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline ralphd

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: ca
    • Nerd Ralph
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #40 on: October 07, 2015, 04:08:52 am »
I agree with Bill that function overloading is a good thing.
I disagree on templates.  While some people can do some cool things with templates, you need to be a *really* good programmer to do it well given the complexity of templates.
As for compile time constant evaluation, I've said before that lto solves most of those problems.  Since gcc 4.9.2 lto works very well.  Adding -flto to your makefile is a *lot* simpler than writing a fancy constexpr template function...
Unthinking respect for authority is the greatest enemy of truth. Einstein
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #41 on: October 07, 2015, 05:30:25 am »
I agree with Bill that function overloading is a good thing.
I disagree on templates.  While some people can do some cool things with templates, you need to be a *really* good programmer to do it well given the complexity of templates.
As for compile time constant evaluation, I've said before that lto solves most of those problems.  Since gcc 4.9.2 lto works very well.  Adding -flto to your makefile is a *lot* simpler than writing a fancy constexpr template function...

I am leaning on adding function overloading to our compilers for the same reason that I think it's a good thing also. Last year we added interspersed declarations and statements, anonymous struct/union, and "C with Classes" and they are really useful, and I expect function overload is the same.

Templates...hmmm... if you really want a macro processor done right, look at BLISS, it's even better than the venerable m4. The code generators for the Digital GEM compilers for VAX-11, Alpha, MIPS are basically written in BLISS macros that are compiled 3 times. Remember that at that time (1992), the fastest workstation was the 66 MHz HP PA-RISC "Snake" and then the DEC Alpha EV4 came out at a mind boggling 200 MHz, and the compilers were a major factor in how they achieved the overall performance. (I happened to have worked on both the DEC GEM and HP PA-RISC compilers, not extensively as I came in late to both projects, but it's very interesting to see the differences in how the two teams interact and how they approach the problems).

Anyway, so yes, templates and boost give me a headache :-)

Lastly, link time optimization is a good thing. Good to see that got put into a production compiler.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3123
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #42 on: October 07, 2015, 05:53:50 am »
Quote
if you really want a macro processor done right, look at BLISS
Many assemblers have wonderful macro processing capabilities.  The gnu assembler isn't one of them :-(

I'm not sure that the sort of template programming that would be needed to clean up the HAL-like libraries would be that complex.
And presumably, the person WRITING the library would (or could, anyway) be pretty good.  (not that the current libraries give me a lot of confidence that that is currently true.  Sigh.)  It doesn't have to be fully optimal; just "much better" than the current code.   That wouldn't be very hard...

ONE of the things you notice when you delve into vendor libraries is that they're carefully written not to have a lot of compiler dependencies.  It's *necessary* that the same libraries work for Keil, IAR, GCC, and others.  Letting the source get sloppy and assuming that gcc link-time-optimization will fix everything up is NOT acceptable.  (Of course, this also ends up being a problem with using C++; you don't want to piss off compiler "partner" companies who don't have C++ compilers yet (or, for that matter, customers who don't want to pay for or deal with complexities of C++, just to write C programs.)

And I don't think lto can fix some of the poor APIs that vendors are using.  I mean, ASF at least is full of:
Code: [Select]
get_thing_defaults(&init_srtuct);
init_struct.somethingINeedToChange = WEIRDCONSTANT;
init_struct.somethingElse = OTHERCONSTANT;
thing_init(&init_struct);


 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #43 on: October 07, 2015, 06:23:49 am »
...
And I don't think lto can fix some of the poor APIs that vendors are using.  I mean, ASF at least is full of:
Code: [Select]
get_thing_defaults(&init_srtuct);
init_struct.somethingINeedToChange = WEIRDCONSTANT;
init_struct.somethingElse = OTHERCONSTANT;
thing_init(&init_struct);

ASF does that TOO? ST's lib is full of this.... *let me channel Linus Torvalds here* ah, inefficiency. WTF are these people thinking?! How could things like these considered good?
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6616
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #44 on: October 07, 2015, 07:52:54 am »
ASF does that TOO? ST's lib is full of this.... *let me channel Linus Torvalds here* ah, inefficiency. WTF are these people thinking?! How could things like these considered good?
Written by those whose only experience with "efficiency" is in academic theory and/or desktop/server environments where "buy more hardware" is the prevailing line of thought and being apathetic towards optimisation is considered a virtue. They're spoiled brats. :P
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3123
  • Country: us
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #45 on: October 07, 2015, 08:45:34 am »
Quote
init_struct.somethingINeedToChange = WEIRDCONSTANT;
Indeed.  I should also note that the size of the init_struct is typically significantly larger than the size of hardware peripheral registers actually involved with configuring "thing."  (eg sizeof(SERCOM0) == 52 (including ~20bytes of "reserved" space).   sizeof(struct usart_config) == 64.   Sigh.)  This is the sort of thing that gets one particularly enthusiastic about calculating things at compile-time.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3392
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #46 on: October 07, 2015, 08:56:34 am »
I actually like it. You just create a flash array of those structs to configure the pins.
Easy to read, easy to switch, easy to diff.
Yes it takes a bit flash. But it would take an equal (if not larger) amount of flash if you write all the register configure lines separate.
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1423
  • Country: dk
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #47 on: October 07, 2015, 08:32:29 pm »
I gave up on ST's libs, as i had to write more lines there, than i have to in VHDL
And a v3 example was absolutely NOT compatible with a v4 example.

So I switched to libopencm3, and i'm quite happy with it.
I have only just begun, but have a USB-CDC example up & running for a F103, only taking up 6k.

You need to dig around the examples, the API Doc (Doxygen ... sigh) , and examples from the web.
But it's easier to cope with , and generates efficient code.

/Bingo
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 465
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #48 on: October 07, 2015, 08:52:04 pm »
I gave up on ST's libs, as i had to write more lines there, than i have to in VHDL
And a v3 example was absolutely NOT compatible with a v4 example.

So I switched to libopencm3, and i'm quite happy with it.
I have only just begun, but have a USB-CDC example up & running for a F103, only taking up 6k.

You need to dig around the examples, the API Doc (Doxygen ... sigh) , and examples from the web.
But it's easier to cope with , and generates efficient code.

/Bingo

I was under the impression that project was entirely dead. I'm extremely reluctant to base a production design off of dead open source.
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1423
  • Country: dk
Re: STM32's HAL... Anything I can do to fix this outrageous bloat?! (pic)
« Reply #49 on: October 07, 2015, 08:58:12 pm »
I gave up on ST's libs, as i had to write more lines there, than i have to in VHDL
And a v3 example was absolutely NOT compatible with a v4 example.

So I switched to libopencm3, and i'm quite happy with it.
I have only just begun, but have a USB-CDC example up & running for a F103, only taking up 6k.

You need to dig around the examples, the API Doc (Doxygen ... sigh) , and examples from the web.
But it's easier to cope with , and generates efficient code.

/Bingo

I was under the impression that project was entirely dead. I'm extremely reluctant to base a production design off of dead open source.

Well there are recent commits
https://github.com/libopencm3/libopencm3

But i primarily see it as some "helper routines" for USB etc, the rest i'll prob do on the bare metal

/Bingo
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf