Pic mcu alternatives???

[cv007]

using all space for lookuptables can only be done with ASM for PICs, i only can code in C.

For the 16F, I do something like the following (if needed), I never used a dspic so maybe does not apply but usually there is a way to make the c compiler do what you want. In this case it works good for 14bit data or less.

Code: [Select]

void ascii_lookup_14seg(){
  //make known this 'function' used with 'global'
  //prepend '_' to asm name
  asm("global _ascii_lookup_14seg");
  //as much data as needed (14bit or less)
  asm("dw 0,6,544,4814,4845,3108,9053,1024");
  //return added here, is ok
}

uint16_t rom_read(uint16_t waddr)
{
  PMADR = waddr; //set address
  CFGS = 0; //flash space
  RD = 1; //start read
  NOP(); //next 2 instructions ignored
  NOP();
  return PMDAT;
}

uint8_t n = 3;
uint16_t val = rom_read( (uint16_t)ascii_lookup_14seg + n );
A normal 'const' would place the data in flash as retlw instructions (14bits flash = 8bits data), where this is 14bits flash = 14bits data. If one is trying to squeeze some more code in available space, this could help. I was using just less than half of a 4Kword pic, and decided I wanted a bootloader so I could upload a newer 'app' to page1 (but page0 code cannot change and always runs on reset). I had a couple 'const' tables that were 14bit data, so I used the code above to save about 300words which enabled me to fit everything in page0. I also wrote the reset/irq jump code needed also in C (with 'asm' keyword), so you can do most things without leaving 'c' if wanted. In the end, I gave up the bootloader idea as its really not worth the trouble and am now back to using 35% of a 4Kword part, using normal 'const', although I also have plenty of extra ram so don't even need to use 'const'.

Although I have previously used gcc with other micros (avr, arm) and have been familiar enough with the many gcc/gas options so can usually find/get what I want done, my only guide was the xc8 user manual. It had all the info I needed to move the page0 app up to make room for the reset/irq jump code, and to build an app that resided in page1.

The free version of xc8 is fine for most users and the few extra instructions will not make any difference. If you feel you can't make it without the last bit of optimizations, I believe you can spend $30 on a one month subscription to xc8 pro.

There are always different parts for different applications, but in defense of 8bitters- find me a 32bit part that can source/sink 20ma per pin with 250-350ma total, find me a 32bit part that can sleep with 100na or less, find me a 32bit part that can run from 1.8v-5.5v, find me a 32bit part that can be had in dip/soic/ssop/qfn, find me a 32bit part that comes in 6pins when I only need a few pins to do something simple, find me a 32bit part... I'll quit while I think I'm ahead

[JanJansen]

Hi, thanks for sharing.
normally i have nothing to do with pages in C, i have no clue, exept that it has to fit in 1 page.
I use lookuptables with 16 or 32 bit data.

Now i have my sinus lookup-table in DSPIC like this :
const unsigned short sinus4096[ 4096 ] = {
0,
};

i better want to have this :

const unsigned short sinus65536[ 65536 ] = {
0,
};

Or even better if it fits the ROM, then i can use more partials ( harmonix ).

[technix]

const unsigned short sinus65536[ 65536 ] = {
0,
};

This is huge - 256kB for a 64k-entry 32-bit LUT. Usually for this big an array I would compress the data in some way - either leveraging the mathematical properties (like for sine and cosine you only need 1/4 of one cycle of one waveform to store both) or using plain old compression algorithms (unlzma an array of data in ROM into external RAM)

[JPortici]

I do not see the problem with putting stuff in ROM in C. Something like

Code: [Select]

static const uint8_t[0x20000] = { 1, 4, 6, ... };
Should end up in ROM.

I wish that would work for my DSPIC33FJGP802
it can only be done in ASM they say, i need that without learning ASM.
Someone posted some ASM code, i dont wanto copy it without knowing what it is, unreadable stuff.
Then i wanto mix it together with C code, maybe that can mess things up also ?

I use rom constants on dspics all the time, i just need to declare them as const.
There should also be a flash/rom qualifier for __attribute but const should be enough. What does the compiler manual say? I'm away so i can't check

I remember you have to tick a checkbox in compiler settigs for arrays bigger than 64k (elements?)

[JanJansen]

Thank you JPortici, i will take a look.

When compiling there is a limit shown in the log for text, const data etc.
Using more data then this size gives error.

Especially when using LCD displays with a big menu, the text is always to much data to have, while my chip is around 50% full programmed.

edit : i,m reading this now : http://microchipdeveloper.com/faq:75
might solve things ?, gonna add codes i dont understand : __eds__  and __attribute__((space(psv))) or __attribute__((space(prog)))  whatever that is for.
I have the same attribute stuff in the interrupt code i copyd from the manual, i just ignore it.

[JPortici]

Read the compiler manual.
Also, the dspic programmer manual to have a better understanding of the architecturez psv etc

[krho]

Does the pic compiler really suck that much.. that's unable to calculate the size of array itself?
e.g does static const uint8_t[] = { 1, 4, 6, ... }; fail?

[JPortici]

How is it that 'you already know the size but you don't want to put it in declaration so the compiler sucks'?
I really don't get it

But i think you can, i do delcare functions with const uint8_t message[] and put "this phrase" as an input variable

[hans]

It's called C99. Make sure to enable it explicitly.

And like the name suggests, it's an industry standard that's already 18 years old.
XC8 does not support it. XC16 and XC32 do.

C89 is the horror where this is not allowed:

Code: [Select]

void someFunction(uint8_t* data) {
  if (write8bits) {
    for (int i = 0; i < 8; i++) {}
  }
}
Because deceleration of variables must be at start of function.

I'm working with other compilers, including ARM and FPGA softcores, that support C++11 and C++14 very well. XC32 does do C++11 as well, because it's GCC 4.8.x last time I checked.

[cv007]

e.g does static const uint8_t[] = { 1, 4, 6, ... }; fail?

No, that works fine.

where this is not allowed

It works just fine. If you want to declare (or decelerate) variables in that for loop, go right ahead.

[JanJansen]

YEEESSS!, it works, adding __eds__  and __attribute__((space(prog))) works, together with the allow arrays bigger then 32K option,
i have a sinus from 32768 positions now, it fills about 75% of the whole chip, i,m happy, gonna program/build a hammond organ emulation without interpolation now.
thanks all, sorry for the topic hijack.
greetings

btw : i did not test, it does compile, should work.

[JPortici]

Test it!

And at some point i'd move everything from uint16 to int16 and then to fract and use the dsp. Granted you can use it anyway with int types, but fract is more appropriate (with the dsp accumulators the result goes up to +/- 256.0 to handle overflows... i'd use one for summing the tonewheels)

Actually, i'd use fewer points and put the table in ram. Dspic33e is very skow at fetching data from flash (5 instructions cycles IIRC, whereas it needs 2 to fetch from ram. Also, with the dsp instructions you have multiple data fetches in a single instructions, so you can remove the lag from memory access time) and interpolate to get intermediate values if you really need more resolution. There is the thread on hot to calculate sine tables here that lists several interpolation methods with error, thd etc

[JanJansen]

What is a fract to be exact ?, i always like improvements.

And yes some data i use in RAM, simple things, for the sinus i had problems,
the integer version gives -32768 to +32767, while i use -32767 to +32767 for multiplying & symmetric audio,
when using sinf( x ); i get some noise, i dont know why, i generate the LUTs in some software, then copy paste the code from the edit window.

[JPortici]

Fixed point fractional numbers. The difference from int is in how multiplications are handled. Standard type is 1Q15 which means it goes from -1.0 to 1.0 in 1/32768 steps.. multiplications results are always between -1.0 and 1.0

The dsp however can treat the 40bit accumulators as 9Q31, from -256.0 to 256.0 in 1/2^31 steps... this is to help you avoid overflow in sums without saturating arithmetic

Then to go back to 1Q31, 32 bit, you just (saturate and) discard the upper byte

To convert from - to int is istantaneous, the data doesn't change at all, it's just a matter of how it is displayed and how you handle multiplications/divisions

Why is it better for some tasks: your sine is from -1 to +1 at full volume. Your drawbar is set at 7. Instead of multiplying by 7 and dividing by 9* you just multiply by 0.77778

*you can also use a table of multipliers so that you multiply by it and just take the higher word of the result (e.g.: 65535×7/9) to avoid any other division, but using fract is more readable... and if you move to a dsp with an FPU you just change the data type from q15 to float

[FrankBuss]

That's why I really like a modern 32 bit CPU. Just buy a STM32F4, and you'll have integrated hardware floating point support, runs at 168 MHz and can do sin/cos calculation in realtime with 48 kHz samplerate and normal floats (4 byte single precision, I'v tested this, no problem). Nearly the same price as a dsPIC. And no crippled or non-standard compiler, the full power of GCC for ARM.

[technix]

That's why I really like a modern 32 bit CPU. Just buy a STM32F4, and you'll have integrated hardware floating point support, runs at 168 MHz and can do sin/cos calculation in realtime with 48 kHz samplerate and normal floats (4 byte single precision, I'v tested this, no problem). Nearly the same price as a dsPIC. And no crippled or non-standard compiler, the full power of GCC for ARM.

If you need even more speed (increased sample rate, channel count or complicated algorithm) you can step up to Allwinner V3s or Raspberry Pi Zero W. The former is much faster (Cortex-A7 @1.2GHz) but have a lot less RAM (64MB) and lacked a GPU. The latter is still fast (ARM1176JZF-S @1GHz,) have a lot more RAM (512MB for your LUTs) and have a GPU for your highly parallel math (like FFT.)

Since both have connectivity options (wired Ethernet for V3s, Wi-Fi for Raspberry Pi Zero W,) you can use it as a gateway streaming the data to another system for computing (e.g. a workstation with a dual Intel Xeon and dual GeForce GTX 1080 Ti, or a virtual machine on Amazon EC2 or DigitalOcean.)

[JanJansen]

JPortici i still dont get it : my sine is from -32767 to +32767, nothing with float,
for multiply i do : unsigned long l = i; l *= volume; l >>= SHIFT; nothing special.

[NorthGuy]

Just buy a STM32F4 ... Nearly the same price as a dsPIC.

Of course, if you buy one, the difference between $3 and $10 is not important. If you buy dev boards instead of chips, there may be no difference whatsoever. However, just $20 more will buy you much better processor, and for just $100 more you can buy Zynq which leaves the STM32F4 in the dust. Why do you settle for STM32F4?

[Scrts]

That's why I really like a modern 32 bit CPU. Just buy a STM32F4, and you'll have integrated hardware floating point support, runs at 168 MHz and can do sin/cos calculation in realtime with 48 kHz samplerate and normal floats (4 byte single precision, I'v tested this, no problem). Nearly the same price as a dsPIC. And no crippled or non-standard compiler, the full power of GCC for ARM.

If you need even more speed (increased sample rate, channel count or complicated algorithm) you can step up to Allwinner V3s or Raspberry Pi Zero W. The former is much faster (Cortex-A7 @1.2GHz) but have a lot less RAM (64MB) and lacked a GPU. The latter is still fast (ARM1176JZF-S @1GHz,) have a lot more RAM (512MB for your LUTs) and have a GPU for your highly parallel math (like FFT.)

Since both have connectivity options (wired Ethernet for V3s, Wi-Fi for Raspberry Pi Zero W,) you can use it as a gateway streaming the data to another system for computing (e.g. a workstation with a dual Intel Xeon and dual GeForce GTX 1080 Ti, or a virtual machine on Amazon EC2 or DigitalOcean.)

Did you try to write application that would do FFT on GPU on RaspberryPi?

[technix]

That's why I really like a modern 32 bit CPU. Just buy a STM32F4, and you'll have integrated hardware floating point support, runs at 168 MHz and can do sin/cos calculation in realtime with 48 kHz samplerate and normal floats (4 byte single precision, I'v tested this, no problem). Nearly the same price as a dsPIC. And no crippled or non-standard compiler, the full power of GCC for ARM.

If you need even more speed (increased sample rate, channel count or complicated algorithm) you can step up to Allwinner V3s or Raspberry Pi Zero W. The former is much faster (Cortex-A7 @1.2GHz) but have a lot less RAM (64MB) and lacked a GPU. The latter is still fast (ARM1176JZF-S @1GHz,) have a lot more RAM (512MB for your LUTs) and have a GPU for your highly parallel math (like FFT.)

Since both have connectivity options (wired Ethernet for V3s, Wi-Fi for Raspberry Pi Zero W,) you can use it as a gateway streaming the data to another system for computing (e.g. a workstation with a dual Intel Xeon and dual GeForce GTX 1080 Ti, or a virtual machine on Amazon EC2 or DigitalOcean.)

Did you try to write application that would do FFT on GPU on RaspberryPi?

Raspberry Pi Foundation and Broadcom have released a GPU computing library, and FFT is one of the algorithms implemented in GPU. And there is a demo program that performs FFT in command line.

[Scrts]

Ok so you didn't. What about Allwinner stuff?

[technix]

Ok so you didn't. What about Allwinner stuff?

Allwinner chip does not have an built-in GPU so all computation have to be handled using the Cortex-A7 core. You just pick your favorite, fastest ARM implementation of whatever algorithm you are using. Or just stream the data off to another computer that have more beefy processors.

[FrankBuss]

Of course, if you buy one, the difference between $3 and $10 is not important. If you buy dev boards instead of chips, there may be no difference whatsoever. However, just $20 more will buy you much better processor, and for just $100 more you can buy Zynq which leaves the STM32F4 in the dust. Why do you settle for STM32F4?

Maybe because I just used the STM32L433 for a project and I really like it Costs only EUR 5.21 in single quantities, and I tested it, needs only about 10 mA at 3.3V and when running with 48 MHz. And this chip has the same floating point hardware support than the STM32F4 series. BTW, the STM32F401 costs only EUR 5.42 in single quantities and runs up to 84 MHz.

If you use a Zynq, probably with Linux, or a Raspberry Pi with Linux, it can be more difficult to implement hard realtime or low latency applications. With a microcontroller it is easier to program more low-level.

[JPortici]

A pic32MZ can be about as cheap as that stm and run up to 250 MHz! Even faster.

The endless debate...

[Scrts]

Ok so you didn't. What about Allwinner stuff?

Allwinner chip does not have an built-in GPU so all computation have to be handled using the Cortex-A7 core. You just pick your favorite, fastest ARM implementation of whatever algorithm you are using. Or just stream the data off to another computer that have more beefy processors.

It's just pain to use those Allwinner or Broadcom processors. External RAM, etc... You can't run them bare metal. I am all the way of using simple ARM F-series where possible.