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

0 Members and 1 Guest are viewing this topic.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17986
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #75 on: August 06, 2014, 12:03:18 am »
transmission" - you'll get a callback to your registered event function when the transmission is complete.  nctnico's example doesn't include the implementation of the callback function,
With SPI and I2C (master) I usually wait for the transaction to finish. The software can't go further without the result anyway at that point. I run high priority processes from interrupts so it is no problem the slow housekeeping process is waiting for some relais to be set or an ADC to be read. With SPI set to 10MHz reading 16 bits takes 1.6us. With the interrupt latency typically at 0.3us there is not much to gain by setting up an interrupt and initialising/testing semaphores.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #76 on: August 06, 2014, 02:33:21 am »
I run high priority processes from interrupts so it is no problem the slow housekeeping process is waiting for some relais to be set or an ADC to be read. With SPI set to 10MHz reading 16 bits takes 1.6us. With the interrupt latency typically at 0.3us there is not much to gain by setting up an interrupt and initialising/testing semaphores.


You do polling in an ISR?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3069
  • Country: us
Re: STM uC Vs Microchip uC
« Reply #77 on: August 06, 2014, 04:37:31 am »
Quote
I usually wait for the transaction to finish.
You mean like this (copying a function from ArduinoISP):
Code: [Select]
uint8_t avrisp_transaction(uint8_t a, uint8_t b, uint8_t c, uint8_t d) {
   uint8_t outdatat[4];
   uint8_t indata[4];
   outdata[0] = a;
   outdata[1] = b;
   outdata[2] = c;
   outdata[3] = d;
   spiDRV->ARM_SPI_Transfer(outdata, indata, 4);
   while (spiDRV->ARM_SPI_GetDataCount() < 4)
     {  /* spin */ }
   return indata[3];  // Last byte input is result.
}
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2175
  • Country: gb
Re: STM uC Vs Microchip uC
« Reply #78 on: August 06, 2014, 08:35:46 am »
With SPI and I2C (master) I usually wait for the transaction to finish. The software can't go further without the result anyway at that point.

That is only true for extremely simple applications where you have just one task to execute.  Many/most embedded systems have multiple tasks and the blocking of one does not have to (and usually should not) prevent execution of the others.  Note that I'm using the word "task" in a non-RTOS sense here, because you don't need an RTOS to continue execution of other tasks when one is blocked.
 

Offline NANDBlog

  • Super Contributor
  • ***
  • Posts: 4479
  • Country: nl
Re: STM uC Vs Microchip uC
« Reply #79 on: August 06, 2014, 09:59:03 am »
Quote
the 32-bit version of the PIC mcu,

There is no hope for PIC32.

Quote
Everything was done using the STM's libraries and i didn't had a single problem.

I have no problem with the ST libraries (i2c being the exception) as well.

Quote
I tried the NXP's LPC1769 with LPCXpresso, but the absence of proper libraries made the experience much more unpleasant

It is not that difficult to code those chips, even without a library. LPCOpen is a different story. The library distributed with CoIDE is robust.

Looks like there is more information for the PIC32MZ than the last time I checked. I wouldn't say that PIC32 is a dead architecture. I actually think it is really decent, not because of the core, but because the peripherals microcip adds to its MCU.
Look at the smallest MZ datasheet. 4 SPI, 6 UART (25 megabit) USB and ethernet in a LQFP64 package, and a 32 bit core running at 200 Mhz. SQI memory interface. I think it is impressive. I'm actually looking forward to try these. Thank for reminding.
According to farnell, they will be at stock in mid October.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17986
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #80 on: August 06, 2014, 10:17:13 am »
With SPI and I2C (master) I usually wait for the transaction to finish. The software can't go further without the result anyway at that point.

That is only true for extremely simple applications where you have just one task to execute.  Many/most embedded systems have multiple tasks and the blocking of one does not have to (and usually should not) prevent execution of the others.  Note that I'm using the word "task" in a non-RTOS sense here, because you don't need an RTOS to continue execution of other tasks when one is blocked.
That is overthinking the whole situation. It is no problem to wait for a few us here & there. It is much less hassle than trying to build everything non blocking or event driven. In the end waiting a few us is probably more efficient than implementing the overhead for not having to wait.

@andyturk: no polling inside the ISR!
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: STM uC Vs Microchip uC
« Reply #81 on: August 06, 2014, 11:19:34 am »
Quote
you can only set the PWM duty cycle once per period on LPC1768, otherwise the PWM output will stick to '1' for that period.

That's the nature of the counter and true for all chips.

To avoid it, use center-aligned pwm. or being careful in changing pwm -> test the counter value first.
================================
https://dannyelectronics.wordpress.com/
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1063
  • Country: fi
Re: STM uC Vs Microchip uC
« Reply #82 on: August 06, 2014, 11:44:30 am »
Looks like there is more information for the PIC32MZ than the last time I checked. I wouldn't say that PIC32 is a dead architecture. I actually think it is really decent, not because of the core, but because the peripherals microcip adds to its MCU.
Look at the smallest MZ datasheet. 4 SPI, 6 UART (25 megabit) USB and ethernet in a LQFP64 package, and a 32 bit core running at 200 Mhz. SQI memory interface. I think it is impressive. I'm actually looking forward to try these. Thank for reminding.
According to farnell, they will be at stock in mid October.
The PIC32MZ is really, really buggy. Even by Microchip standards. Study the errata carefully, and remember that the part was originally launched in late 2013 (with silicon revision 3!) and is still not generally available. Scuttlebutt is that they're doing a full redesign which will be out in about one year's time. On the plus side, that version supposedly will add an FPU.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17986
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #83 on: August 06, 2014, 12:15:23 pm »
Quote
you can only set the PWM duty cycle once per period on LPC1768, otherwise the PWM output will stick to '1' for that period.

That's the nature of the counter and true for all chips.

To avoid it, use center-aligned pwm. or being careful in changing pwm -> test the counter value first.
The easiest way is to enable an interrupt for the counter value which needs to be changed and make the change in the interrupt. Shadow registers which get read at the end of the PWM cycle would have been nicer though.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline NANDBlog

  • Super Contributor
  • ***
  • Posts: 4479
  • Country: nl
Re: STM uC Vs Microchip uC
« Reply #84 on: August 06, 2014, 01:43:34 pm »
The PIC32MZ is really, really buggy. Even by Microchip standards. Study the errata carefully, and remember that the part was originally launched in late 2013 (with silicon revision 3!) and is still not generally available. Scuttlebutt is that they're doing a full redesign which will be out in about one year's time. On the plus side, that version supposedly will add an FPU.
You should know, that the PCB designer never reads errata  :-DD
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 617
  • Country: tn
Re: STM uC Vs Microchip uC
« Reply #85 on: August 06, 2014, 02:17:38 pm »
You should know, that the PCB designer never reads errata  :-DD

damn right  :D
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2175
  • Country: gb
Re: STM uC Vs Microchip uC
« Reply #86 on: August 06, 2014, 05:43:10 pm »
With SPI and I2C (master) I usually wait for the transaction to finish. The software can't go further without the result anyway at that point.

That is only true for extremely simple applications where you have just one task to execute.  Many/most embedded systems have multiple tasks and the blocking of one does not have to (and usually should not) prevent execution of the others.  Note that I'm using the word "task" in a non-RTOS sense here, because you don't need an RTOS to continue execution of other tasks when one is blocked.
That is overthinking the whole situation. It is no problem to wait for a few us here & there. It is much less hassle than trying to build everything non blocking or event driven. In the end waiting a few us is probably more efficient than implementing the overhead for not having to wait.

If it's literally a few microseconds then I'd agree, but an I2C transaction of say 16 bytes at 100kbit/s would mean you are tied up for over a millisecond.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17986
  • Country: nl
    • NCT Developments
Re: STM uC Vs Microchip uC
« Reply #87 on: August 06, 2014, 07:02:40 pm »
If waiting a millisecond doesn't hurt then it is not a problem. The whole dogma 'don't poll and exit interrupts immediately' just makes no sense. It is just a matter of planning on where to spend the CPU time and that differs with each project.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf