A few API questions « LeafLabs Garden

LeafLabs Garden » Support » Maple IDE Support

A few API questions

(25 posts) (4 voices)

Started 4 years ago by Xavier
Latest reply from mbolivar

12 Next »

Xavier
Moderator

Hi,

First, congratulation for this great project : "Maple"...

I have a project in mind and look at the API while waiting for my board which should arrive soon.

Here are my technical questions :
1. why does Serial1/2::begin(baud) disable TIMER1/2 configuration ? I don't understand this conflict.
2. Reading the usart.c code i think i understand that USART*_IRQHandler() fill the ring buffer from the usart->dr register. But i cannot see when we say to the IRQ to use this handler.

I think there's an error page :
http://leaflabs.com/docs/external-interrupts.html
The attachInterupt(..) described seems to be the one of HardwareTimer::attachInterrupt(..)

Congratulations again and I really hope to see some more development in this project... (DMA API ? :-) ).

Xavier

Posted 4 years ago #
Xavier
Moderator

OK... I got the answer for my first question.
It only disables the channel that could send PWM on the same PIN.

(in HardwareSerial::HardwareSerial() the "compare_num" parameter could have "channel" in its name).

The other question is still valid, i really miss a point how those IRQ are initialized.

Cheers,

Xavier

Posted 4 years ago #
mbolivar
LeafLabs

Hi Xavier,

The attachInterrupt() and detachInterrupt() functions were in fact pulling their text from the wrong sources. This is now fixed. Thanks for the report!

As you discovered, The timer channels are disabled in Serial[1,2].begin() in order to avoid potential PWM conflicts.

The NVIC is initialized with the USART IRQs (among others) by the linker scripts (in support/ld and its subdirectories); see the file support/ld/names.inc for the function names the scripts expect. Simply defining a function with the proper name suffices (these were initially released into the public domain by ST forum user "lanchon").

Regarding the USART IRQs, these are sort of buggy (mainly due to errors in our ring_buffer implementation). These bugs are fixed in the nzmichaelh-master libmaple branch (the initial implementation of which was contributed by github user nzmichaelh, hence the name), which also provides C-level support for DMA, among other things (notably, backup registers and independent watchdog). Its contents will be merged into the next release.

Link: https://github.com/leaflabs/libmaple/tree/nzmichaelh-master

Thanks again for the feedback!

Posted 4 years ago #
mbolivar
LeafLabs

By the way, "git grep" is a nice way to poke around libmaple:

$ git grep USART3_IRQHandler
libmaple/usart.c:void USART3_IRQHandler(void) {
support/ld/names.inc:EXTERN (USART3_IRQHandler)
$ git grep names.inc
support/ld/maple/flash.ld:INCLUDE names.inc
support/ld/maple/jtag.ld:INCLUDE names.inc
support/ld/maple/ram.ld:INCLUDE names.inc
support/ld/maple_mini/flash.ld:INCLUDE names.inc
support/ld/maple_mini/jtag.ld:INCLUDE names.inc
support/ld/maple_mini/ram.ld:INCLUDE names.inc
support/ld/maple_native/flash.ld:INCLUDE names.inc
support/ld/maple_native/jtag.ld:INCLUDE names.inc
support/ld/maple_native/ram.ld:INCLUDE names.inc
support/scripts/copy-to-ide: ./support/ld/names.inc"

Posted 4 years ago #
Xavier
Moderator

Thanks a lot for all these answers.

nzmichaelh branch is fantastic.
The work on usart (putc), ring_buffer and dma is really interesting.
The current ring_buffer should really be replaced in the main branch.

The IRQ handlers loaded in the very low adresses by the linker is much clearer now.

Now i'm waiting even more for my maple to arrive.
I cannot wait to know how many FM sound synthesis voices it will handle in real time.

Any information about the maple_audio i could see in a git branch ?

Cheers,

Xavier

Posted 4 years ago #
poslathian
LeafLabs

maple audio is a side project here. Its a stm32f103ret6 processor with stereo ~16bit audio at 50KHz. We get 16 bits in by decimating the 1MHz 12 bit ADC down to 50MHz (which might not be quite 16 bits, but it gets pretty close). We get 16 bits out by combining two 8 bit pwms with a one bit resistor-ladder dac. The rest of the board was a ton of gain and filtering stages on both input and output and has a lot of other handy features (like output->input feedback in analog, and some high order low pass filters on the output).

Generally, we found it was super hard to calibrate the resistors in the 1 bit dac to be accurate enough (they must have a precise 1:256 ratio, accurate to 1/(2^16)). The next experiment is going to use a codec chip.

FYI, I was able to get a sketch running 25 channels of independent sine waves with some pretty naiive coding @ 50Khz running on that board.

Posted 4 years ago #
Xavier
Moderator

Thanks for the info... Nice to see some research in that direction.

I'm targeting 36Khz audio. I like this number beside 72Mhz...
2000 cycle between each sample. A timer overflow value of 2000 for the PWM timer makes a pseudo ~11bits dac.
I have no idea how such a simple PWM "dac" sounds with a low pass filter. I didn't know this dac method 5 days ago.
I'll see... :-)

Xavier

Posted 4 years ago #
poslathian
LeafLabs

low passing pwms, or even combining two pwms as we did is OK but tricky. If you dont get your cutoffs right or if (in the case of combining two pwm's, if you get the resistor ratio off by some amount) you get high frequency aliasing. This is really annoying and very audible. When you pump higher frequencies into it, they get reflected back down from 20KHz back into the audible range. This is painfully visible when you plot the spectrogram, and if you make a little widget that ramps the frequency up, once it gets pretty high you can hear the reflection at very high volume. Ostensibly the filtering should take care of this, but to be honest, I'm ready to just start using an I2S or SPI codec chip.

Posted 4 years ago #
poslathian
LeafLabs

oh, btw. Once you get your maple, you can run this handy little audio demo. 8 bit PWM comes out of pins 6 and 7 (yea thats right, stereo!), and it runs 8 channels of sawtooth on both left and right outputs. This could easily be bumped up to about 13 channels on each, and theres a lot of room to muck about with making the code nicer etc etc. Its just a little demo I keep on hand for fun.

To hear it youll need some sort of speakers, and probably some resistors because otherwise its a bit on the loud side. Nothing else is needed. You can ground the second terminal of your speakers (headphones whatever) and then wire up the other terminal through a 2k (or so) resistor to one from pin 6 or 7.

Obviously this is not the "real way" to do audio, but shit - its two resistors and < 100 line sketch here:
https://github.com/leaflabs/projects/tree/thx/thx

Posted 4 years ago #
zoofdxp
Member

Hi poslathian, Can you provide a rough estimate regarding the time frame for the updated IDE? The updates for uart etc will be nice, but I'm looking most forward to an equivalent I2C library that uses the dma as well. There are so many sensors that require the I2C, to me it is as important as having a good uart on a micro. I know there is alot of great effort by many talented people and it is appreciated. But I believe that the I2C functionality is a make or break decision for many potential projects and that Maple will really take off if this hurdle is overcome. Thanks!

Posted 4 years ago #
mbolivar
LeafLabs

zoofdxp,

Hardware I2C is high on our list of priorities as well. We're working on it, with an ETA of about 1 month for C-level support (and shortly thereafter, a wirish wrapper).

We agree that it's an important hurdle to overcome. However, we had previously promised to fix some critical bugs before moving on to new features. This work (which occurred on the debug-serialusb and nzmichaelh-master libmaple branches) is now wrapping up, and we'll be moving on to new features as soon as we can.

Thanks to everybody for your patience!

Posted 4 years ago #
poslathian
LeafLabs

dont forget that soft i2c (master mode only) is already in the IDE as a library. It works with some devices (like the xl345) but not with others, mostly due to clock stretching issues. However, you can use this library now...

Posted 4 years ago #
Xavier
Moderator

Thanks poslathian for your answer and for the very usefull thx example.
I have mixer at home connected to amplified speaker so i'm confident i will be able to hear some sounds ;-)

I realized that 400Khz I2C is to slow for 40Khz 12 or 16bits audio.
I just gave a look to i2s and spi protocol... very intersting.
SPI would be better as it seems that the regular "maple" does not support i2s.

Looking forward to see what you come with,

BTW my maple arrived this morning :-))) how tiny ! impressive.

Cheers,

Xavier

Posted 4 years ago #
poslathian
LeafLabs

I2S is supported on maple native, but I am not unconvinced that you couldnt get I2S running on a regular maple by tweaking the USART configuration a little bit and maybe do some bit banging. Ive been meaning to try this. Has anyone?

Posted 4 years ago #
mbolivar
LeafLabs

ok, i've merged the nzmichaelh-master branch into libmaple master. this finally provides DMA support (libmaple/dma.h). other new features:

- independent watchdog (libmaple/iwdg.h)
- backup registers (libmaple/bkp.h)
- basic power management #defines (libmaple/pwr.h)
- a fixed ring_buffer implementation (libmaple/ring_buffer.h)
- various bug fixes and improvements (most notably to libmaple/usart.c, wirish/time.h, wirish/time.c, and libmaple/exti.c)

credit and thanks to Michael Hope (nzmichaelh on github) for the initial implementation.

i'm going to hold off on releasing an IDE snapshot for now, as the APIs are pretty low level and there's no formal documentation (although there are plenty of doxygen comments in the source). if you've got some time and are using the unix toolchain, we'd love to hear any feedback/experience reports!

Posted 4 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.