Author Topic: STM uC Vs Microchip uC  (Read 10585 times)

0 Members and 2 Guests are viewing this topic.

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 544
  • Country: tn
STM uC Vs Microchip uC
« on: August 03, 2014, 11:33:10 PM »
Hi everyone,
i been using microchip for a long time , all family included, most of my project didn't much of processing so 18F family is what i used most. A year ago i started using STM32F0 and god how frustrating that thing is :o i was like  |O the thing need thousand line to set the input/output configuration only And i had a hard time to understand how to manually program  every register and get clear idea how this think really work from a low level electronic point of view and not with all that C++ fashion programming crap, So i drop it, and after doing one project with it i forgot about it. Now i have more to do with STM32 again. i thought why not ask everyone here what they think about it, since am not really objective concerning those STM ┬ÁC.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 2671
  • Country: gb
  • Will design for cookies
Re: STM uC Vs Microchip uC
« Reply #1 on: August 03, 2014, 11:52:03 PM »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #2 on: August 04, 2014, 12:45:11 AM »
Your experience is not atypical, nor unexpected.

A more complex chip means more things to configure, which in turn means more complexity for the programmer.

That's not to say that such complexity cannot be managed, through good programming practices.

For example, the following sets out a pin to output and then set / clear it.

Code: [Select]
#include <gpio.h>  //our gpio related routines

#define LED_PORT  GPIOA
#define LED_DDR    GPIOA
#define LED           ((1<<2) | (1<<3)) //led on pin2 and pin3

  PIN_OUT(LED_DDR, LED); //set led as output

  PIN_SET(LED_PORT, LED); //set led
  PIN_CLR(LED_PORT, LED); //clear led

For me, I can compile that piece of code, unmodified, on PIC, AVR, STM8, various flavors of ARM and it will produce identical behaviors. All I need to do is to link in the right gpio.h/.c files.

The same principle applies to other peripherals - if you structure your code right and write code with some pre-planning, you will accumulate a large body of code that can greatly reduce your difficulties in porting and implementing code on different mcus.
================================
https://dannyelectronics.wordpress.com/
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 2671
  • Country: gb
  • Will design for cookies
Re: STM uC Vs Microchip uC
« Reply #3 on: August 04, 2014, 01:37:13 AM »
It's probably also fair to point out that GPIO access is something which is particularly easy on a PIC, and particularly difficult by comparison on an STM32 if you're using ST's libraries. Don't let that put you off; once you've written your code to initialise the hardware, and you have your own function to set or clear I/O pins, then your application development will start to become much more familiar again.

Don't be afraid to ignore ST's libraries and just go ahead and write to BSRR. It's quite liberating.
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 544
  • Country: tn
Re: STM uC Vs Microchip uC
« Reply #4 on: August 04, 2014, 02:29:31 AM »
thanks,
@andy i just read what you wrote on the other post it's almost the same experience, i started to make a progress when i wrote directly to concerned register and not through supplied function.
I used Cube for schematics, when i generated the code same thing those HAL function are not compatible with IDE library am using (IAR) and again to trash i wrote my own code.
I share every single opinion you wrote there, concerning lack of documentation and how much supplied function and tools are
efficient.

"I'll address the issue of portability between families if and when it becomes an issue, which I strongly suspect will be "never"."
My target uC is a F1 device but for now am using an F0 to test functionality of my prototype ( waiting for the F1 chip to be delivered ) if i understand your sentence right , i will have no issue of portability between both device. So my code can be almost the same. Did you make same test with different family ?

i think the answer to my question is there is no easy way to do it, i will eventually chose to either write directly registers or use the supplied function according to my project needs.

@dannyf
i like the way you wrote that example however it does not solve the main problem, of going through the configuration of all those registers and what is the best way to do it, your gpio file will be filled with those infinite line just to tell the damn compiler you need PA0 to be an output  :P
i will remember this method when i write a code that need to be portable on many uC  ;)

So in general, since many ppl here had experience with multiple type of uC, when choosing a specific uC what family you prefer by putting in mind processing capability , cost , and time to market.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #5 on: August 04, 2014, 02:50:57 AM »
Quote
it does not solve the main problem,

You didn't get the approach. It is about hiding the details away from the user so that the user application is equally "simple" as in the 8-bit world.

Quote
of going through the configuration of all those registers and what is the best way to do it

That depends on your toolchain, your chip and more importantly your approach.

For example, the PIN_SET() implementation can be as simple as this:

Code: [Select]
#define PIN_SET(gpio, pins)  gpio->BSRR |= (pins)

or this:

Code: [Select]
#define PIN_SET(port, pins) port->ODR |= (pins)

or this:

Code: [Select]
#define PIN_SET(port, pins)         MAP_GPIOPinWrite(port, (pins), (pins))

or this:

Code: [Select]
#define PIN_SET(port, pins) HWREG(port + (GPIO_O_DATA + ((pins) << 2))) = (pins)

or this:

Code: [Select]
#define PIN_SET(port, bits) port |= (bits) //set bits on port

or any other implementation on your toolchain and for your chip.

But that's irrelevant, as long as you can achieve the goal of simplifying coding in the user space.

The issue you are encountering isn't unique to ST chips, or even ARM. It is fundamentally caused by the powerfulness of the chips. You just need to come up with a way to manage it in a way that is acceptable to you.
« Last Edit: August 04, 2014, 02:52:37 AM by dannyf »
================================
https://dannyelectronics.wordpress.com/
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 10777
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #6 on: August 04, 2014, 02:54:28 AM »
Hi everyone,
i been using microchip for a long time , all family included, most of my project didn't much of processing so 18F family is what i used most. A year ago i started using STM32F0 and god how frustrating that thing is :o i was like  |O the thing need thousand line to set the input/output
Look at the ARM devices from NXP. Simple to use and they keep the same peripherals in future versions.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 633
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #7 on: August 04, 2014, 07:48:29 AM »
[...] however it does not solve the main problem, of going through the configuration of all those registers and what is the best way to do it, your gpio file will be filled with those infinite line just to tell the damn compiler you need PA0 to be an output  :P

Are you talking about how to initialize all the GPIO ports after reset? Here's how I do it:

pins.h:
Code: [Select]
#pragma once

#include "stm32f4xx.h"
#include <cstdint>


#define ALL_PORTS \
  PORT(A)         \
  PORT(B)         \
  PORT(C)         \
  PORT(D)         \
  PORT(E)         \
  PORT(F)         \
  PORT(G)         \
  PORT(H)         \
  PORT(I)

/*
 * The ALL_PINS macro, defined below, contains the I/O pin architecture-
 * specific GPIO configuration for the application.
 *
 *  port: GPIOA .. GPIOI
 *   pin: 0 .. 15
 *  name: any identifier
 *  mode: IN | OUT | AN "analog" | AF "alternate function"
 *  type: PP "push pull" | OD "open drain"
 * pupdr: NOPULL | UP | DOWN
 *   odr: 0 | 1
 *    af: 0 .. 15
 */

//  port, pin, name,         mode,      type, speed,  pupdr,  odr, af
#define ALL_PINS                                                           \
PIN(GPIOA,  1, DBG_EN,       OUT,        PP,   Low,    NOPULL,  0, NONE)   \
PIN(GPIOA,  2, FLASH_HOLD,   OUT,        PP,  High,    NOPULL,  1, NONE)   \
PIN(GPIOA,  3, FLASH_WP,     OUT,        PP,  High,    NOPULL,  1, NONE)   \
PIN(GPIOA,  4, SPI1_CS,      OUT,        PP,  High,    NOPULL,  1, NONE)   \
PIN(GPIOA,  5, SPI1_SCK,     AF,         PP,  High,    NOPULL,  0, SPI1)   \
PIN(GPIOA,  6, SPI1_MISO,    AF,         PP,  High,    NOPULL,  0, SPI1)   \
PIN(GPIOA,  7, SPI1_MOSI,    AF,         PP,  High,    NOPULL,  0, SPI1)   \
PIN(GPIOA,  9, USB_VBUS,     IN,         PP,   Low,    NOPULL,  0, NONE)   \
PIN(GPIOA, 11, USB_N,        AF,         PP,   Low,    NOPULL,  0, OTG_FS) \
PIN(GPIOA, 12, USB_P,        AF,         PP,   Low,    NOPULL,  0, OTG_FS) \
PIN(GPIOA, 13, SWDIO,        AF,         PP,  High,    NOPULL,  0, SWJ)    \
PIN(GPIOA, 14, SWCLK,        AF,         PP,  High,    NOPULL,  0, SWJ)    \
                                                                           \
PIN(GPIOB,  0, DISP_RES,     OUT,        PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOB,  1, DISP_CS,      OUT,        PP,  High,    NOPULL,  1, NONE)   \
PIN(GPIOB,  2, BOOT1,        IN,         PP,   Low,    NOPULL,  0, NONE)   \
PIN(GPIOB,  3, DISP_SCK,     AF,         PP,  High,    NOPULL,  0, SPI3)   \
PIN(GPIOB,  4, DISP_DC,      OUT,        PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOB,  5, DISP_MOSI,    AF,         PP,  High,    NOPULL,  0, SPI3)   \
PIN(GPIOB, 10, DBG_TDI,      IN,         PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOB, 11, DBG_TRST,     IN,         PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOB, 12, DBG_SWDIO,    IN,         PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOB, 13, DBG_SWCLK,    IN,         PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOB, 14, DBG_SWO,      IN,         PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOB, 15, DBG_NRST,     IN,         PP,  High,    NOPULL,  0, NONE)   \
                                                                           \
PIN(GPIOC,  0, SW3,          IN,         PP,   Low,        UP,  0, NONE)   \
PIN(GPIOC,  1, SW4,          IN,         PP,   Low,        UP,  0, NONE)   \
PIN(GPIOC,  2, VCC_SENSE,    AN,         PP,   Low,    NOPULL,  0, NONE)   \
PIN(GPIOC,  3, SW5,          IN,         PP,   Low,        UP,  0, NONE)   \
PIN(GPIOC,  7, EN_VCC_USB,   OUT,        PP,  High,    NOPULL,  1, NONE)   \
PIN(GPIOC,  8, EN_VCC_3V3,   OUT,        PP,  High,    NOPULL,  1, NONE)   \
PIN(GPIOC,  9, LED1,         OUT,        PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOC, 10, DBG_TX,       IN,         PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOC, 11, DBG_RX,       IN,         PP,  High,    NOPULL,  0, NONE)   \
PIN(GPIOC, 13, LED2,         OUT,        PP,  High,    NOPULL,  1, NONE)   \

enum all_pins_defs {
#define PIN(port,pin,name,mode,ppod,speed,pull,value,altfn) name = pin,
ALL_PINS
#undef PIN
};

pins.cc:
Code: [Select]
#include "pins.h"
#include "stm32f4xx.h"
#include <cstdint>


struct pin_config_t {
  uint32_t periph;
  GPIO_TypeDef *port;
  GPIO_InitTypeDef init;
  uint8_t alternate_fn;
  BitAction odr;
};

enum {
  GPIO_AF_NONE = 0xff
};

static const pin_config_t pin_config[] = {
#define PIN(port,pin,name,mode,ppod,speed,pull,value,altfn) \
  {RCC_AHB1Periph_ ## port, port, {1 << (pin), GPIO_Mode_ ## mode, GPIO_ ## speed ## _Speed, GPIO_OType_ ## ppod, GPIO_PuPd_ ## pull}, GPIO_AF_ ## altfn, (BitAction) value },
  ALL_PINS
#undef PIN
};

void configure_gpio_pins() {
  GPIO_InitTypeDef unused;

  // fill in ST's idea of a default pin
  // Note: this may not be correct for lowest power consumption
  GPIO_StructInit(&unused);

  // Call GPIO_Init() to initialize each port
#define PORT(name) GPIO_Init(GPIO ## name, &unused);
  ALL_PORTS
#undef PORT

  for(unsigned i=0; i < sizeof(pin_config)/sizeof(pin_config_t); ++i) {
    const pin_config_t &config(pin_config[i]);

    // enable the port for the pin. OK to do this more than once.
    RCC_AHB1PeriphClockCmd(config.periph, ENABLE);

    // initialize the pin
    GPIO_Init(config.port, (GPIO_InitTypeDef *) &config.init);

    // set the altfn
    if (config.alternate_fn != GPIO_AF_NONE) {
      GPIO_PinAFConfig(config.port, config.init.GPIO_Pin, config.alternate_fn);
    }

    if (config.init.GPIO_Mode == GPIO_Mode_OUT) {
      GPIO_WriteBit(config.port, config.init.GPIO_Pin, config.odr);
    }
  }
}
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 544
  • Country: tn
Re: STM uC Vs Microchip uC
« Reply #8 on: August 04, 2014, 08:22:12 AM »
@dannyf , thank for explaining i get your approach now, total agree.
Look at the ARM devices from NXP. Simple to use and they keep the same peripherals in future versions.
i will  at first possible occasion ;)

@andyturk
i will certainty try this code, it's not the "how to" that am asking about really, i just put the gpio as an example of how i find programming STM32 long and annoying, i wanted to see how other developer feel about it, and if anyone have a better approach than the one i use.

the thing is am more in electronic than in coding, i do software certainly for ages, i will not claim that my code is perfect it may look like shit for a trained IT engineer eyes but it work  :P when code is much oriented for ppl that are familiar with C++  developer and such it kind of bores me, and in a way this is what happening here. for the same reason i agree with AndyC about writing your own function that address BSRR directly.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 633
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #9 on: August 04, 2014, 08:38:13 AM »
@andyturk
i will certainty try this code, it's not the "how to" that am asking about really, i just put the gpio as an example of how i find programming STM32 long and annoying, i wanted to see how other developer feel about it, and if anyone have a better approach than the one i use.

the thing is am more in electronic than in coding, i do software certainly for ages, i will not claim that my code is perfect it may look like shit for a trained IT engineer eyes but it work  :P when code is much oriented for ppl that are familiar with C++  developer and such it kind of bores me, and in a way this is what happening here. for the same reason i agree with AndyC about writing your own function that address BSRR directly.
Well, I come from an "IT" background and most of the firmware I've seen written in C horrible, so it's not just you! :-) The stuff you get from OEMs is especially bad with code that's clearly a copy-and-paste from somewhere else, uses #defines rather than more modern constructs, is chocked full of global variables and generally looks like it was written by underpaid interns in the mid 90s. Blech.
</rant>

Hitting BSRR directly is just fine. I like to do that in a C++ template, but an inline function will work too and helps hide the details without adding any overhead.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8237
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #10 on: August 04, 2014, 10:43:10 AM »
Quote
i wanted to see how other developer feel about it, and if anyone have a better approach than the one i use.

The approach is really to "box it": put the respective functions into layers so that invocation for such functions is as simple and intuitive as on an 8-bit machine. The fact that the mcu has to go through many lines / instructions to do get it done is not as critical from the programmer's perspective, for most applications.
================================
https://dannyelectronics.wordpress.com/
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 10777
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #11 on: August 04, 2014, 08:54:00 PM »
Just adding layers (boxing stuff) doesn't make a program more readable. Actually it makes it harder to maintain because the next programmer must read through all the layers to find out what the program actually does in case something needs to be changed or fixed.

If I add a layer in a piece of software I ask myself: does this 'layer' add functionality to the program? If the answer is NO (the layer just moves data around) then I leave it out. It often means that the layers above (application) and below (hardware control) need more work to make them more compatible which eachother.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 3231
  • Country: nl
Re: STM uC Vs Microchip uC
« Reply #12 on: August 04, 2014, 09:03:30 PM »
All depends on what you call a layer. I think you would hardly disagree that a HAL is neccesary.
The nice thing about layering is that the programmer in case of changes/problems does not have to be bothered by the lower (tested) layers and can concentrate on the stuff above.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: STM uC Vs Microchip uC
« Reply #13 on: August 04, 2014, 09:57:38 PM »
Just adding layers (boxing stuff) doesn't make a program more readable.
It's something that's happening many times between transistor and your high-level language code. Of course it can be done badly, but when done by someone who understands the machine and macros you get something useful. When done by someone who understands the machine and language design, you get something really useful.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 4772
Re: STM uC Vs Microchip uC
« Reply #14 on: August 04, 2014, 10:35:19 PM »
The nice thing about layering is that the programmer in case of changes/problems does not have to be bothered by the lower (tested) layers and can concentrate on the stuff above.
In theory, yes.

In practice... not really.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: STM uC Vs Microchip uC
« Reply #15 on: August 04, 2014, 11:10:37 PM »
The nice thing about layering is that the programmer in case of changes/problems does not have to be bothered by the lower (tested) layers and can concentrate on the stuff above.
In theory, yes.

In practice... not really.
Then maybe you should be looking at your practice because this is all we've got ;)

With regards to hardware design, I can't remember the last time something had been abstracted and tested then went on to fail for me and this failure wasn't down to either:
i) misuse, or
ii) it wasn't properly tested.  (copy/paste error in the ALU circuit for an AND operation so bit N of an operand was used instead of bit M (M=/=N) and my insufficient tests missed it).

As far as software is concerned, again I can't remember the last time something broke that had been deemed working. A good chunk my design involves the writing of proofs by induction or equational reasoning.

There is a large class of systems that are working 24 hours a day, 7 days week. They are so reliable we don't even think expect failure just like we always expect water out of the tap and electricity from the socket. It can be done.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 10777
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #16 on: August 04, 2014, 11:59:35 PM »
The nice thing about layering is that the programmer in case of changes/problems does not have to be bothered by the lower (tested) layers and can concentrate on the stuff above.
In theory, yes.

In practice... not really.
Then maybe you should be looking at your practice because this is all we've got ;)

With regards to hardware design, I can't remember the last time something had been abstracted and tested then went on to fail for me and this failure wasn't down to either:
i) misuse, or
ii) it wasn't properly tested.  (copy/paste error in the ALU circuit for an AND operation so bit N of an operand was used instead of bit M (M=/=N) and my insufficient tests missed it).
These are minor issues. The biggest problem usually is proper documentation. Without documentation it is much easier to analyse what 2 layers of abstraction are actually supposed to do than to analyse 10 layers of abstration where a lot of layers don't really add anything to the software. Also: with proper documentation it becomes easier to re-use software and less layers means less work on documentation.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online NANDBlog

  • Super Contributor
  • ***
  • Posts: 2625
  • Country: be
Re: STM uC Vs Microchip uC
« Reply #17 on: August 05, 2014, 12:10:56 AM »
The problem is obvious. You changed the architecture of the hardware, without changing how you write code. If you take 20 years advance there, you should advance here also. I mean ARM is not meant to be programmed with magic numbers to registers. It has CMSIS, and a help file, which is the first place to look at, if you need to configure something. Help file, not the datasheet.
I agree that setting up the develpoment tools is much harder with ARM, and the learning curve is much steeper, but I suspect that it will wash away every 8 bit development in the very near future.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 10777
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #18 on: August 05, 2014, 12:39:12 AM »
Sigh  :palm:
There are two kinds of peripherals on an ARM controller:
1) The simples ones (UART, SPI, timers) where using a library is total overkill and not worth it because of the numerous ways a peripheral can be used.
2) The complex ones (ethernet, USB) where using a library is mandatory and easy because the number of uses for such peripherals is very limited.

Just pouring software layers on top of hardware is like pouring Sate sauce over all your food hoping it tastes better.

The simple peripherals have not changed much between ancient 8 bit controllers and ARM controllers. They don't have to. The basics of I/O pins, UART, SPI, timers, I2C, etc have been the same for over 30 years. Why try to make programming these hard to do? Like you have to be a software engineer to work with ARM? I'm almost starting to get the feeling some people feel they belong to some elitist group who know how to program ARM controllers and try to keep others out by spreading nonsense about how hard ARM controllers are to work with.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 544
  • Country: tn
Re: STM uC Vs Microchip uC
« Reply #19 on: August 05, 2014, 12:57:23 AM »
@nctnico, can't explain what i need to say better than what you did, why i feel the need that i have to be a software engineer to make it work.

I'm almost starting to get the feeling some people feel they belong to some elitist group who know how to program ARM controllers and try to keep others out by spreading nonsense about how hard ARM controllers are to work with.

I tried to get a job as a firmware developer once in some big developing firm specialized in EE ( so they say), my application was automatically disqualified, they ONLY accept ppl from a local elite IT university here... now i can see why  :P
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 2671
  • Country: gb
  • Will design for cookies
Re: STM uC Vs Microchip uC
« Reply #20 on: August 05, 2014, 02:19:13 AM »
The problem is obvious. You changed the architecture of the hardware, without changing how you write code. If you take 20 years advance there, you should advance here also. I mean ARM is not meant to be programmed with magic numbers to registers. It has CMSIS, and a help file, which is the first place to look at, if you need to configure something. Help file, not the datasheet.
I agree that setting up the develpoment tools is much harder with ARM, and the learning curve is much steeper, but I suspect that it will wash away every 8 bit development in the very near future.
Sorry, can't agree with this at all.

From my experience with trying to develop a new application on an STM32 a couple of weeks ago, two things became painfully obvious:

- despite the fact that it's apparently frowned upon in some circles, poking hardware registers to drive the standard peripherals such as timers and UARTs was by far the clearest, fastest and most space efficient way to do it. Allowing for the fact the peripherals themselves are more complex and capable than their counterparts in 8-bit micros, accessing them directly is really no more difficult. If you don't want to use the extra features, set the bits that control those features to zero.

- by complete contrast, trying to work out what the ST library functions were actually doing (and not doing!), and which function calls are actually needed to configure and use a device in a particular way, was a pain. Adding a layer of poorly documented obfuscation is absolutely NOT a way to make code easier to write, read, or port across platforms.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: STM uC Vs Microchip uC
« Reply #21 on: August 05, 2014, 02:48:33 AM »
my application was automatically disqualified, they ONLY accept ppl from a local elite IT university here... now i can see why  :P
A couple of points:
1) You may have dodged a bullet not getting that job.
2) It seems like you're an EE struggling with complexity with regards to software design. Just so you know, everybody struggles with complexity in software design. It takes a lot of time building a system with a good structure.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: STM uC Vs Microchip uC
« Reply #22 on: August 05, 2014, 03:06:59 AM »
The biggest problem usually is proper documentation. Without documentation it is much easier to analyse what 2 layers of abstraction are actually supposed to do than to analyse 10 layers of abstration where a lot of layers don't really add anything to the software. Also: with proper documentation it becomes easier to re-use software and less layers means less work on documentation.

If you're analysing abstractions then it's probably the case that they were not meant for you.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 10777
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #23 on: August 05, 2014, 03:17:49 AM »
If analysing the source of a poorly documented non-working library (=abstraction layer) is the wrong way to move ahead then I'm very curious about your approach in such a situation.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline bwat

  • Frequent Contributor
  • **
  • Posts: 278
  • Country: se
    • My website
Re: STM uC Vs Microchip uC
« Reply #24 on: August 05, 2014, 03:41:07 AM »
If analysing the source of a poorly documented non-working library (=abstraction layer) is the wrong way to move ahead then I'm very curious about your approach in such a situation.
I'll repeat in slightly different terms but with the same meaning: you shouldn't need to look at the internals of an abstraction. In your case your abstraction doesn't work - something that 99% of the time could be determined without looking at the internals - so drop it and find something that does or create your own.

Also a library by definition is not an abstraction layer. To abstract is to determine those properties of the universe of objects which are essential and those which are nonessential, then identify of  those objects that differ only in the nonessential. A layer is a step in a hierarchical design. A library is a collection of abstractions but these need not form a layer.
"Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind?" - Christophe Thibaut

"People who are really serious about software should make their own hardware." - Alan Kay
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf