microchip or atmel ARM's

[newbrain]

ahem, just plugged a second nucleo board in and it's all lights a blazing. I'm thinking the first one might be a dud, or something is up with the computer.

Reading through the whole thread I'm quite puzzled by the amount of problems you found.
I've been using Nucleos and Discos for some time, 99% in Windows (and 1440p) and with System Workbench and VisualGDB without running into any real issue.

For this last thing, it's very strange that you have a dead board: I've managed to half-kill one, but that took some effort in sloppiness and >20V.

Did you check that all the jumpers are in the correct position?
All the following must be in place:

• Two on CN2 on the ST-link side of the board to connect the target to the programmer/debugger
• The jumper on JP5 must be on U5V side, if you power the board through USB
• The IDD jumper (JP6) must be in place

If enumeration is a problem (underpowered Hub, maybe?) you can try putting a jumper on JP1 too (not in general advisable).

The board should appear as several USB devices, namely (going form memory):

• The ST-link debugger
• A mass storage device (handy for programming: just drop the .bin in the disk!)
• A serial port COMx

[Simon]

It turns out to be a duff cable, plugged the "dead" one into the laptop with the cable i used before and still nothing, changed the cable and voila!

As to the other problems it's basically as Dave said in his video where he went through a similar exercise. There is nothing to download and just get going with, you have to be quite knowledgeable about the tool-chain as well.

Unfortunately there are several things i need to learn at the moment apart from spending most of my time in a full time job: a HNC course in electrical engineering, packed with maths I am unlikely to ever use and struggling badly to understand, Circuit studio having wasted time with another software, and attempting to enter into the ARM world. So yes it is frustrating when I also have to become a tool-chain expert. ST do not provide a ready to go tool-chain like for example Atmel have or Microchip do. Once again today when I repeated the whole process of setting up for the Nucleo on my laptop it took several minute just to log into the ST website, and I do literally mean some minutes, this is a constant experience and not very inspiring.

Although not diagnosed it is extremely likely that I have attention deficit that just makes all of the above feel like it is 3 times harder than it should be and probably is 3 times harder for me than it is for most people. This was part of my reason for looking at ARM, in the hope that things like STCubeMX or whatever it is called help take care of stuff that I don't have to get too down and dirty with so that I can spend 3 times the time it may take others to develop my application. typically my application amounts to less than 10 lines, it's all the register setting up that takes a long, long time and I am trying to avoid a bit.

[rstofer]

yes I looked at ST, looked like real hard work to work out how to fire up the software and get anything done.

Did you expect it to be easy?

I expect them to talk in easy to understand language for the new comer, we all have to start somewhere. I already have new chips to learn, the software need not be made unnecessarily hard.

Everybody is going to jump in with the favorite board so I'll do the same.  Have you considered the LPC1768 version of the 'mbed'?  Not only is the toolchain free, it is reachable via your favorite browser, you don't need to install or configure anything.  Thus you are always using the latest version...  And don't overlook how cool it is to be system independent.  You can reach your code from any browser, anywhere in the world.

In my opinion, you start out closer to the chip with the mbed approach.  You don't get all wrapped up in a HAL that just increases the slope of the learning curve.

I like the 'stamp' format because I can plug it into a prototype board.  I can also build permanent projects on a motherboard and plug in the CPU.

https://developer.mbed.org/platforms/mbed-LPC1768/

Since the PHY is on the underside of the board, adding Ethernet is as simple as wiring up a MagJack.  There is a full TCP/IP stack if that is required.

The MBED libraries provide a lot of code if you want to use them but there is no real requirement to do so.  You can easily get right down to the peripheral registers and work right at the bottom layer of code.

My very first real project required interrupt driven SPI reception at about 10 MHz clock rate.  It was amazingly easy to do.

If you toss out the copyright and the unused #defiines, it took about 50 lines of code to initialize the SPI device and hook it up to the NVIC.  As bytes are received, the device raises an interrupt and the interrupt code (spi_slave_handler) grabs the value before calling enqueue to place it in a circular buffer.

Code: [Select]

/*
Copyright (c) 2012 Richard T Stofer

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/

#include "LPC17xx.h"
#include "spi_slave.h"
#include "queue.h"
#include "cmsis_nvic.h"

// P0.15 SCK    MBED p13
// P0.16 SSEL   MBED p14
// P0.17 MISO   MBED p12
// P0.18 MOSI   MBED p11

// bit positions within the various registers
#define PCSPI       ( 8)    // power control bit
#define PCLK_SPI    (16)    // clock select bits 17..16
#define BIT_ENABLE  ( 2)    // enable width other than 8 bits
#define CPHA        ( 3)    // clock phase control
#define CPOL        ( 4)    // clock polarity
#define MSTR        ( 5)    // enable master mode
#define LSBF        ( 6)    // LSB first
#define SPIE        ( 7)    // enable SPI interrupt
#define BITS        ( 8)    // set transfer width (not used)
#define SPIF        ( 0)    // SPI interrupt flag bit

#define stABRT      ( 3)    // status bits
#define stMODF      ( 4)
#define stROVR      ( 5)
#define stWCOL      ( 6)
#define stSPIF      ( 7)
#define stERROR     ((1 << stABRT) | (1 << stMODF) | (1 << stROVR) | (1 << stWCOL))

spiStatsStruct spiStats;

spiStatsStruct * spiGetStruct(void) {
    return &spiStats;
}

void spi_slave_handler(void) {
    unsigned char status;
    unsigned char value;
   
    status = LPC_SPI->SPSR;         // get status register
    if ( (status & stERROR) != 0) {
       
        spiStats.totalErrors++;
        if (status & (1 << stABRT))
            spiStats.errABRT++;
        if (status & (1 << stMODF))
            spiStats.errMODF++;
        if (status & (1 << stROVR))
            spiStats.errROVR++;
        if (status & (1 << stWCOL))
            spiStats.errWCOL++;
    }
    value  = LPC_SPI->SPDR;         // get the data byte
    spiStats.bytesReceived++;
    enqueue(value);
    LPC_SPI->SPINT = (1 << SPIF);   // clear interrupt flag
}

void spi_slave_init(void) {
    volatile int junk;

    LPC_SC->PCONP           |=  (1 << PCSPI);    // pedantic, should already be powered up
    LPC_SC->PCLKSEL0        &= ~(3 << PCLK_SPI); // reset clock select bits for PCLK_SPI
    LPC_SC->PCLKSEL0        |=  (1 << PCLK_SPI); // set SPI clock to CCLK
    LPC_PINCON->PINSEL0     |= 0xC0000000;       // set up SCK in PINSEL0
    LPC_PINCON->PINSEL1     |=  (3 << 0);        // set up SSEL in PINSEL1
    LPC_PINCON->PINSEL1     |=  (3 << 2);        // set up MISO in PINSEL1
    LPC_PINCON->PINSEL1     |=  (3 << 4);        // set up MOSI in PINSEL1
    LPC_SPI->SPCR            = (1 << SPIE);      // set up control register
    junk                     = LPC_SPI->SPSR;    // clear status register
    junk                     = LPC_SPI->SPDR;    // clear data register
    LPC_SPI->SPDR            = 0x00;             // initial return value
    LPC_SPI->SPINT           = (1 << SPIF);      // clear interrupt flag
                           
    NVIC_SetVector(SPI_IRQn, (uint32_t) &spi_slave_handler);
    NVIC_SetPriority(SPI_IRQn, 1);
    NVIC_EnableIRQ(SPI_IRQn);
}

Pretty easy.

[rstofer]

Although not diagnosed it is extremely likely that I have attention deficit that just makes all of the above feel like it is 3 times harder than it should be and probably is 3 times harder for me than it is for most people. This was part of my reason for looking at ARM, in the hope that things like STCubeMX or whatever it is called help take care of stuff that I don't have to get too down and dirty with so that I can spend 3 times the time it may take others to develop my application. typically my application amounts to less than 10 lines, it's all the register setting up that takes a long, long time and I am trying to avoid a bit.

I don't think ADHD is all that rare among engineers.  Other social ineptitudes also accompany the major.

I have been playing with ST boards using STCubeMX and I really don't enjoy the experience.  Instead of just stuffing values in registers and watching the pretty LEDs blink, I have to try to decipher somebody else's code.  I really think the HAL obscures more than it illuminates.  Give me a datasheet and I'll write my own drivers, thank you very much!  Oh, and copying is allowed.

Allowing STCubeMx to create a basic framework may be a good path for others.  I haven't gotten to the point where I enjoy it.  Obviously, opinions vary...

I started my ARM adventures with a couple of simple but very complete chips, the NXP LPC2106 and the LPC2148.  These are a small subset of the more modern chips but they were pretty easy to understand and provided decent performance.  The LPC2148 has a full USB peripheral so things like VCOM and mass storage were easy to implement by grabbing NXPs sample code.

If you think you might be interested in an older chip, just to get started, consider the LPC2148 and the magnificent code at http://www.jcwren.com/arm/  This is really nice code!

This is the board I used.  I see it is terribly overpriced based on costs today:

https://www.olimex.com/Products/ARM/NXP/LPC-P2148/

All in, I prefer the LPC1768 mbed.

[Simon]

The STM32F091RCT featured on the Nucleo-F091RC is pretty much what I need. It's not too expensive, supports USB, nice fast ADC, and has a CAN channel I'd like to use one day.

[Kjelt]

lpc2148

I would not recommend it for new designs or for starters, that chip is the past and probably also almost obsolete.
For Arm the Cortex M0,3,4,7 is the present.
Sorry probably my allergy from college where we always got outdated stuff because the teacher knew that stuff and was too lazy to update/upgrade his knowledge and tools, books.

[nctnico]

lpc2148

I would not recommend it for new designs or for starters, that chip is the past and probably also almost obsolete.
For Arm the Cortex M0,3,4,7 is the present.

When it comes to NXP it doesn't really matter since the peripherals you'll find in the LPC2148 are also used in their newer chips so many things you'll learn and code you write can be re-used across NXP's entire ARM controller portfolio. IMHO that is a strong point compared to ST's offerings which are not consistent at all.

[Kjelt]

I am not saying it should be ST but then get a modern NXP Cortex M0,3,4 chip.
Some of the even older arm7tdi chips are becoming unobtanium, for new designs a no go.

[technix]

Some of the even older arm7tdi chips are becoming unobtanium

LPC2103? I still have, like, 10 of them. The support circuitry is a bit crazy for me to set up on breadboards so I don't use it that often.

[technix]

For me personally I don't like any vendor toolset for ARM. I have been using vanilla Eclipse CDT + GNU ARM Embedded + J-Link or CMSIS-DAP for my projects.

Does anyone know how to get AMD R9 380 working under macOS Sierra? Ubuntu 17.04 is great but macOS works better. (And no please PLEASE do not suggest Windows to me - it does not work for my purposes.

[newbrain]

The STM32F091RCT featured on the Nucleo-F091RC is pretty much what I need. It's not too expensive, supports USB, nice fast ADC, and has a CAN channel I'd like to use one day.

If you intend to continue with ST, there is a number of online courses that explain the use of CubeMX and the HAL, e.g.:

• STM32F0/L0 MOOC with hands-on exercises
• STM32Cube basics MOOC with hands-on exercises

If you don't like System Workbench (I'm not fond of Eclipse based tools either), specifically for ST F0 and L0 MCUs, the Keil development environment is free without code size limitation.
CubeMX can directly generate Keil MDK projects.
I happen to like Visual Studio Community (free as in beer) + VisualGDB (not free, but not expensive): it just works for me, VS is an excellent development environment and VGBD also supports a number of other vendors' MCUs (ST is one of the better supported). Plenty of tutorials, including importing CubeMX generated projects.

In the Cube, in addition to the HAL, CMSIS and other drivers/middlewares, there are tons of example code for the Nucleo, Disco and Eval boards, providing a good insight on HAL use.

On a completely different note, danadak, ebclr and dgtl have suggested Cypress PSoC, which is a really interesting alternative.
Cheap boards, decent IDE (but one is 100% bound to it for the HW definition part) and great fun.
The peripheral library API is simple and clear, and one can design their own specialized HW: e.g. I recently used it for a reciprocal frequency meter (a couple of evenings), and to make a test harness for a simple ATtiny based project (a couple of hours).

All of the above IMHO, YMMV etc. etc.: this is an hobby for me, though I work with SW.

[Simon]

The cypress website actually seems quite good, no need to log in and wait over a minute for it to log in and download the IDE, I'm yet to grab a part number and find out how much it is and how available. As they do a seperate range on auto ARM chips that don't seem cheap I'm wondering if the cheaper ones will feature CAN.

[ebclr]

I assure you, as soon you have proficiency on Psoc you will forget everything else, that family and concept are unique and amazing

Regarding Can

http://www.cypress.com/documentation/application-notes/an52701-psoc-3-and-psoc-5lp-getting-started-controller-area-network

[Gibson486]

Just pick one and go. No matter which platform you choose, you are going to hit a roadblock somewhere. It is part of the learning process.

[Simon]

true but I often deal in low volumes so I would rather be in a position of having an easy initialisation process even if the chip cost more rather than send weeks on programming as in low volume it's cheaper in the long run. The Cypress setup does indeed look interesting.

[ebclr]

That's is a perfect scenario for a cypress stick,

[Simon]

Well I would ultimately like to be using CAN as well so depends on what is available, the €4 sticks do indeed look very attractive