next topic »

[Reply #30 on:]

Personally I never use DIPs these days, but people still like them for prototyping.

Surprising. Does that mean you don't do any hand assembly yourself these days, or do you do all your hand assembly with SMD?

My experience is that life's just too short to hand assemble SMD. (But I've never claimed to be the quickest person with a soldering iron.)

[Reply #31 on:]

Truth is I hate prototyping so I put my faith in data sheets and go straight to a PCB.

That said I don't actually make a lot these days but my current project is a dual processor board, I see no reason the design shouldn't be 99% correct as most hardware is quite simple these days. 99% is close enough and at $65 for 10 PCBs it's cheaper than the SMD breakout boards I'd have to buy as many of the components aren't available in PTH.

I'm not that experienced with soldering SMDs but with a hot-air station I haven't found it that hard so far.

______
Rob

[Reply #32 on:]

possible that nxp has studied the market and come to the conclusion that this ... "hobbyist" niche is not where they can make sufficient profit to float their boat.

Oh, certainly.  Just like most of the major chip vendors.  But if they had decided to ignore it entirely, I don't think you'd see products like the 28-pin DIP, or even the more-recently announced 20-pin SOIC.  They seem to be aiming at some non-traditional customers of SOME kind.

I think it's because "real engineers" of the mega-profit sort don't actually get to spend a lot of time "evaluating" new CPUs.  You get handed a decision, or pick your old favorite, or base a decision on non-interesting criteria like raw speed, supplier reliability, or price.  An professional engineer who is actually "evaluating" a chip on more artistic technical merits is closer to a hobbyist than most of them will care to admit (admittedly, of the techno-hobbyist type, rather than the less-technical arduino user. But it still sucks to struggle through that first "blink" attempt...)

[Reply #33 on:]

I am seeing that MikroElektronika site has: C, Basic and Pascal compilers for ARM, PIC, PIC32, AVR, 8051.
see: http://www.mikroe.com/forum/
The question is, are these people serious? They seem to have all major compilers possible for all major microcontrollers on the market.

Example:
Code written for mikroBasic ARM compiler

Code:

' * Project name:
'     Pwm_Demo (Demo on using mikroE's PWM library functions)
' * Copyright:
'     (c) Mikroelektronika, 2011.
' * Revision History:
'     20110105:
'       - initial release;
' * Description:
'     This is a simple demonstration of PWM library, which is being used for
'     control of the ARM's PWM module. The module is initialized and started,
'     after which the PWM's Duty Ratios can be adjusted by means of 4 buttons
'     connected to pins PA0, PA1, PA2 and PA3. The changes can be monitored on the PWM
'     output pins (PB0 and PB2).
' * Test configuration:
'     MCU:             LM3S9B95
'                      http://www.ti.com/lit/ds/symlink/lm3s9b95.pdf
'     Dev.Board:       EasyMx v7 for STELLARIS(R) ARM(R)
'                      http://www.mikroe.com/eng/products/view/792/easymx-pro-v7-for-stellaris-arm/
'     Oscillator:      XT-PLL, 80.000MHz
'     Ext. Modules:    None.
'     SW:              mikroBasic PRO for ARM
'                      http://www.mikroe.com/eng/products/view/753/mikrobasic-pro-for-arm/
' * NOTES:
'   - Turn off all PORT LEDs except PORTB at SW15. (board specific)
'   - Pull-down PORTA at SW1, and put SW16.1 in VCC position (board specific)

program Pwm_Demo
dim current_duty, old_duty, current_duty1, old_duty1 as word
    pwm_period1, pwm_period2 as word

sub procedure InitMain()
  GPIO_Digital_Input (@GPIO_PORTA, _GPIO_PINMASK_ALL) ' configure PORTA pins as input
end sub

main:
  InitMain()
  current_duty  = 100                         ' initial value for current_duty
  current_duty1 = 100                         ' initial value for current_duty1

  pwm_period1 = PWM_CCP0_Init(5000, @_GPIO_MODULE_CCP0_B0)
  pwm_period2 = PWM_CCP3_Init(5000, @_GPIO_MODULE_CCP3_B2)

  PWM_CCP0_Start()
  PWM_CCP3_Start()

  PWM_CCP0_Set_Duty(current_duty,  _PWM_INVERTED_DISABLE)  ' Set current duty for PWM_CCP0
  PWM_CCP3_Set_Duty(current_duty1, _PWM_INVERTED_DISABLE)  ' Set current duty for PWM_CCP3

  while (TRUE)                               ' endless loop
    if GPIO_PORTA_DATA.B0 = 1 then           ' button on RA0 pressed
      Delay_ms(1)
      current_duty = current_duty + 5        ' increment current_duty
      if (current_duty > pwm_period1) then   ' if we increase current_duty greater then possible pwm_period1 value
        current_duty = 0                     ' reset current_duty value to zero
      end if
      PWM_CCP0_Set_Duty(current_duty,  _PWM_INVERTED_DISABLE) ' set newly acquired duty ratio
    end if

    if GPIO_PORTA_DATA.B1 = 1 then           ' button on RA1 pressed
      Delay_ms(1)
      current_duty = current_duty - 5        ' decrement current_duty
      if (current_duty > pwm_period1) then   ' if we decrease current_duty greater then possible pwm_period1 value (overflow)
        current_duty = pwm_period1           ' set current_duty to max possible value
      end if
      PWM_CCP0_Set_Duty(current_duty,  _PWM_INVERTED_DISABLE) ' set newly acquired duty ratio
    end if

    if GPIO_PORTA_DATA.B2 = 1 then           ' button on RA2 pressed
      Delay_ms(1)
      current_duty1 = current_duty1 + 5      ' increment current_duty1
      if (current_duty1 > pwm_period2) then  ' if we increase current_duty1 greater then possible pwm_period2 value
        current_duty1 = 0                    ' reset current_duty1 value to zero
      end if
      PWM_CCP3_Set_Duty(current_duty1, _PWM_INVERTED_DISABLE)       ' set newly acquired duty ratio
    end if

    if GPIO_PORTA_DATA.B3 = 1 then           ' button on RA3 pressed
      Delay_ms(1)
      current_duty1 = current_duty1 - 5      ' decrement current_duty1
      if (current_duty1 > pwm_period2) then  ' if we decrease current_duty1 greater then possible pwm_period1 value (overflow)
        current_duty1 = pwm_period2          ' set current_duty to max possible value
      end if
      PWM_CCP3_Set_Duty(current_duty1, _PWM_INVERTED_DISABLE)
    end if

    Delay_ms(1)                              ' slow down change pace a little
  wend
end.

[Reply #34 on:]

non-interesting criteria like raw speed, supplier reliability, or price.

Call me non-interesting, but I think supplier reliability and price actually tend to concentrate the mind over and above other more "artistic" features, at least when when a "real" product is involved. Particularly supplier reliability.

[Reply #35 on:]

Truth is I hate prototyping so I put my faith in data sheets and go straight to a PCB.

Fair enough, but PCBs don't assemble themselves!

Even with a hot-air station, are you putting all your boards together by hand, or are you sending them out to a service for assembly? I'm wondering at what volume this becomes economical these days...

[Reply #36 on:]

They've been around for a long time. $249 for a C compiler is not cheap these days, but maybe it's worth it if you get a stack of working libraries for the hardware that port between platforms.

Are those function calls the same in the C version?

Does the same code work on an LPC if you just change the target or something simple?

______
Rob

[Reply #37 on:]

are you putting all your boards together by hand,

I've only done a few in this life as an EE. Previously I worked for a company that had a production line and in those days there was no SMDs anyway. I had to load 1 maybe 2 prototype boards but after that I got the assembly people to do them.

In this life I'm retired and only do a few boards for myself every year or so. However my current project may get serious and require a lot of boards. I do have an associate in the US that is happy to load boards but I would think after 10 or 20 he'd rather get a life as well.

So if it gets that far I'll have to find an assembling company.

I'm wondering at what volume this becomes economical these days...

A friend of mine in NZ did a run of about 10 large boards with a lot of SMDs. Is was worth getting a local firm to load the SMDs for him and he finished off. I can't remember the prices though.

I have also in the past talked with both US and Chinese companies that sell boards. They are often prepared to make and sell them on a royalty basis. For that matter Sparkfun will do that. But this of course means that they have to buy into you product and you in turn lose a lot of control.

That's not necessarily a bad thing though, in fact to me that would be a good thing, I can think of nothing worse than making and testing 100 boards.

______
Rob

[Reply #38 on:]

A different question,
Can a source code (including the libraries) written in LPC Xpresso be ported, preferably in an easy manner, to Keil uVision4 for ARM?
Reason: LPC Xpresso does not have a simulator while Keil has so the code can be debugged without using the real hardware.

[Reply #39 on:]

Can a source code (including the libraries) written in LPC Xpresso be ported, preferably in an easy manner, to Keil uVision4 for ARM?

The answer is a little bit difficult.

An ide (uVision or EWARM or Code Red / eclipse) can have different compilers, particularly for an open source ide like eclipse: you can hang actually mdk or iar arm compilers now to eclipse.

IDE is simply an interface to integrate all little pieces together for better productivity.

Libraries are compiler-specific, as a result, not ide-aware.

So if the libraries in question are written for a compiler to be ported to, your code utilizing that library can be easily ported, short of your usual struggle with some syntax issues.

Now, most of the oem libraries on the arm are written for gcc, mdk and iar. The issue is likely cmsis: they may have been built on different versions of cmsis that your target platform may not support. In those cases, you can either sort it out or migrate with the host cmsis.

[Reply #40 on:]

They are more powerful than AVRs but these ARM Cortex-M micro-controllers do not seem easy to work with. See this discussion: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=127016
Too many vendors, too many types of ARMs, too many different peripherals, too many ways to set them.
The huge diversity of ARMs seems to be their main enemy.

[Reply #41 on:]

There is such a thing as too much choice that's for sure and I reckon that must put people off.

However once you decide on a family (in my case LPC) the chips are actually very easy to use, well the smaller ones anyway. The ability to MUX functions on pins is good and bad, I find that with a large chip (144 or 217 pins) I need a spread sheet to keep track of what function I have on what pin, that can quickly get to be a nightmare.

But as I say the smaller chips are pretty easy to work with, I downloaded LPCXpresso and had a working test program running in minutes.

Once you get your head around a particular family you are right, but if you flit from vendor to vendor you will go nuts.

Truth is the fact that there's an ARM core is irrelevant to most people, it's the peripherals that you deal with and unfortunately they are all different.

FWIW I think the SAM used in the Due is about the best chip in that size, it has some neat features that the Due does not use. But I prefer LPCs because they have a larger range so that what I learn will be largely portable from 8 pins to 217 pins. If I get a Due that will mean learning a whole new set of peripherals (or keeping to high-level code).

______
Rob

[Reply #42 on:]

However once you decide on a family (in my case LPC) the chips are actually very easy to use, well the smaller ones anyway. The ability to MUX functions on pins is good and bad, I find that with a large chip (144 or 217 pins) I need a spread sheet to keep track of what function I have on what pin, that can quickly get to be a nightmare.

Have you tried ARMwizard?
If not (because I am seeing that you have experience with LPC family from NXP) can you try it, when you have time, and tell if this tool for setting ARM peripherals really simplify the work of programmers.

[Reply #43 on:]

Yes I have, very useful program I think.

I used it when it first came out but at the time it didn't support the 12xx chips and that's what I'm using.

I know it now does but I've since written a HAL framework so don't need it so much however I haven't written drivers for many of the peripherals yet so I think I'll be revisiting ARMwizard to help with that.

_____
Rob

[Reply #44 on:]

The huge diversity of ARMs seems to be their main enemy.

That's the part many people don't understand. As most people write code for those chips with C/C++, the arm core is actually transparent to them. The tasks of working with the peripherals remain the same.

As such, I firmly believe this whole transition to arm is more marketing driven.