Reply by ●September 14, 20182018-09-14
>An RTOS invariably requires code that cannot be written in C - those 
>bits must be in assembly. 


And then there are compiler back ends. ;)

Cheers

Phil Hobbs
Reply by David Brown ●September 14, 20182018-09-14
On 13/09/18 20:37, Bill Martin wrote:

> On 09/04/2018 12:28 AM, David Brown wrote:
>>
> < SNIP >
>>>>> So it'd be difficult to just say whip up some asm by
>>>>> hand and drop the binary on it and have it actually do anything.
>>
>> No one sane uses assembly on an ARM.
>>
> 
> I beg your pardon...have you ever looked at the source for ThreadX?
> 


No - and I have no reason to assume the authors of it are sane!

However, I should have qualified by statement better:

No one sane uses assembly on an ARM when the same functionality could be
written in C, C++ or another high-level language.


An RTOS invariably requires code that cannot be written in C - those
bits must be in assembly.
Reply by Bill Martin ●September 13, 20182018-09-13
On 09/04/2018 12:28 AM, David Brown wrote:

> 

< SNIP >

>>>> So it'd be difficult to just say whip up some asm by
>>>> hand and drop the binary on it and have it actually do anything.
> 
> No one sane uses assembly on an ARM.
> 


I beg your pardon...have you ever looked at the source for ThreadX?


>>>
>>> that is almost never in the datasheet for MCUs, you need the usermanual
>>>
>>> https://www.nxp.com/docs/en/user-guide/UM11065.pdf
>>>
>>
>> I can see why one might want to pay for the macros.
> 
> No one sane pays for the microcontroller headers.
> 
>
Reply by Ivan Shmakov ●September 8, 20182018-09-08
>>>>> Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:


[...]

 > Sounds as though STM may have got their support act together.
 > Five years or so ago when I last looked at a STM32 MCU, the library
 > headers were a complete nightmare.  Unorganized, duplicated, horrible.

	Five years or so ago, when I first became interested in ARM
	Cortex M3 MCUs, I've stumbled upon http://libopencm3.org/.

	Now, I'm hardly involved in embedded development to any
	considerable degree, but I don't think I even as much as really
	looked at the ST's own libraries.

[...]

-- 
FSF associate member #7257  http://softwarefreedomday.org/  15 September 2018
Reply by Phil Hobbs ●September 8, 20182018-09-08
On 9/8/18 7:57 AM, Klaus Kragelund wrote:

> ST recently released SPL code, which is HW close effective libraries
> 


Any idea how it compares to the NXP (or other vendors') libraries?

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com
Reply by ●September 8, 20182018-09-08
buecherk@gmail.com wrote

>Can someone report experience about PICs?
>Many thanks  Klaus 


I have used several, 16F.. now everything is 18F14K22
 http://panteltje.com/panteltje/pic/index.html

Depends what you want to do.
I program all in asm (gpsasm Linux) and do not use the Microchip tools.
Debug or whatever you want to call it via serial port.

Good stuff, 18F14K22 has internal PLL and runs at 64 MHz with internal clock.
Reply by ●September 8, 20182018-09-08
Can someone report experience about PICs?
Many thanks  Klaus
Reply by Klaus Kragelund ●September 8, 20182018-09-08
ST recently released SPL code, which is HW close effective libraries
Reply by Tauno Voipio ●September 8, 20182018-09-08
On 8.9.18 04:10, Phil Hobbs wrote:

> On 09/07/2018 08:59 PM, Lasse Langwadt Christensen wrote:
>> l&oslash;rdag den 8. september 2018 kl. 02.49.34 UTC+2 skrev Phil Hobbs:
>>> On 09/07/2018 06:08 PM, jrwalliker@gmail.com wrote:
>>>> On Friday, 7 September 2018 14:36:12 UTC+1, Phil Hobbs&nbsp; wrote:
>>>>
>>>> The single cycle multiplier and single-cycle access to i/o pins
>>>> are nice features too.
>>>>
>>>> It looks as if the dev board can be adapted with the right
>>>> removal of jumpers to act as a debug interface to one's own
>>>> hardware.
>>>>
>>>> John
>>>>
>>>
>>> All the LPCxpresso boards can do that.&nbsp; You can separate the programmer
>>> (LPClink) from the target and use it on your own hardware.&nbsp; That's often
>>> very useful.
>>>
>>
>> same for STM, the STM Nucleo boards are in the same form factor and 
>> pinout as arduino and cost ~$10
>>
>>
> 
> Sounds as though STM may have got their support act together.&nbsp; Five 
> years or so ago when I last looked at a STM32 MCU, the library headers 
> were a complete nightmare.&nbsp; Unorganized, duplicated, horrible.
> 
> I'll have a squint at their newer stuff when I have half a minute to 
> myself.
> 
> Cheers
> 
> Phil Hobbs



The library code is still a sorry mess. I had to end up writing
all the low-level code for a STM32L4xx myself.

-- 

-TV
Reply by bitrex ●September 7, 20182018-09-07
On 09/07/2018 09:58 PM, bitrex wrote:

> On 09/07/2018 09:36 AM, Phil Hobbs wrote:
>> On 09/03/2018 01:25 PM, Phil Hobbs wrote:
>>> LPC804: 15 MHz Cortex M0+, 32kB flash, 4k RAM, 12-bit 2 us ADC with 1
>>> LSB DNL, 10-bit DAC, the usual serial stuff, 20-TSSOP:&nbsp; 67 cents in
>>> reels, dev board $27.
>>>
>>> We're using it for a super-quiet diode laser controller where it will
>>> run the temperature control and automatic power control loops.&nbsp; I'll
>>> never use another ATmega. ;)
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>>
>>
>> The dev boards came in, and they're pretty slick.&nbsp; For the $27 you get
>> not only the MCU and so on, but two shields, one for capacitive touch
>> and one full of buttons and switches and jumpers and stuff, for use with
>> the programmable logic unit.&nbsp; The PLU is a small CPLD with 26 5-input
>> LUTs that you can program in Verilog.&nbsp; Super handy where hardware timing
>> is needed, which it usually is in instruments.
>>
>> The other thing I really like about the LPC804 is that it has this giant
>> pin multiplexer, so that you can put just about any peripheral function
>> on any GPIO pin, which is a huge time saver compared to the assing
>> around you have to do on other MCUs to try to get the best possible
>> combination of limited pinout choices.&nbsp; You can mix and match inputs and
>> outputs, e.g. you can put a capture input and a UART TXD on the same pin
>> if you like.&nbsp; Some combinations are silly, but some are potentially
>> useful, and it&nbsp; Probably the big MUX works a lot better at 15 MHz than 
>> 200.
>>
>> They basically give the dev board away, but (I imagine) charge just
>> enough that hobbyists aren't so tempted to use it instead of an Arduino
>> or RasPi.
>>
>> Fun.
>>
>> Cheers
>>
>> Phil Hobbs
>>
> 
> I'm going to get my hands on some to test, only thing that seems a bit 
> of a downer with the 3.3V arm parts is it looks like most of the I/O has 
> wimpy drive. AVRs at 5 volts can sink and source big currents out all 
> their pins, 30-40mA. If I wanted to drive some 7-segment LED display I'd 
> probably need another chip. Not the end of the world I guess


Not simultaneously, rather, but limited by package dissipation of course