You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Andrew Tam <ta...@proxy.co> on 2017/02/01 20:01:21 UTC
Re: 2nd UART on NRF52DK
Hi Marko,
I've followed what you did in the Arduino Primo bsp file to setup the UART1
pins. Looks like my project will compile without errors, But I was unable
to see anything coming over the UART1 TX. Is there a sequence that needs
to be followed when sending the data?
for example to send a blocking tx byte (with vaule "1" every second) we're
using something like this:
uart_timer_cb(struct os_event *ev) {
uart_start_tx(uart1);
uart_blocking_tx(uart1,'1');
os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
hal_gpio_toggle(LED_BLINK_PIN);
}
The gpio toggles ~ ever second so we know the timer is working. but maybe
we've forgotten something?
Thanks for the help!
- Andrew -
On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
> Thanks Marko,
>
> I think I got some of it sorted, I found the header file for the
> bitbanger uart and I think I should be good.
>
> Cheers,
>
> - Andrew -
>
> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io> wrote:
>
>> Hi Andrew,
>>
>> the example is the arduino primo BSP.
>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c, specifically
>> the setup of UART0 and UART1.
>>
>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
>>
>> > On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
>> >
>> > I'm currently looking into using the 2nd UART as well, I was doing some
>> > reading on the nrf52dk pins and looks like pins P0.22 / P0.23 / P0.24 /
>> > P0.25 could also be good options.
>> >
>> > I'm curious to know if there was some example code as to how you set
>> this
>> > up on the nrf52?
>> >
>> > Thanks,
>> >
>> > - Andrew -
>> >
>> >
>> >
>> > On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <ma...@runtime.io>
>> wrote:
>> >
>> >> I did operate it only Arduino Primo, where the 2nd UART was my console
>> >> (or maybe it was the connection to ESP8266?).
>> >>
>> >> Looks like the pins used on that BSP are 11 and 12.
>> >> I would pick whichever is most easily accessible from the connector :)
>> >>
>> >>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <sa...@mac.com>
>> wrote:
>> >>>
>> >>>
>> >>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <ma...@runtime.io>
>> wrote:
>> >>>>
>> >>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my console.
>> >>>> If I remember correctly, the hal timer used by the bitbanger was
>> running
>> >>>> at 1MHz.
>> >>>
>> >>>
>> >>> What pins on the NRF52dk are you using? The syscfg.yml has only
>> >>> UART_1:
>> >>> description: 'Bitbanger UART'
>> >>> value: 0
>> >>>
>> >>> defined for UART_1 so I'll need to configure pins for UART_0_PIN_TX
>> and
>> >> UART_0_PIN_RX:
>> >>>
>> >>> Suggestions?
>> >>>
>> >>> dg
>> >>> --
>> >>> David G. Simmons
>> >>> (919) 534-5099
>> >>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog>
>> •
>> >> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
>> >> http://twitter.com/TechEvangelist1> • GitHub <
>> http://github.com/davidgs>
>> >>> /** Message digitally signed for security and authenticity.
>> >>> * If you cannot read the PGP.sig attachment, please go to
>> >>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
>> >>> * Public key available at keyserver.pgp.com <
>> http://keyserver.pgp.com/>
>> >>> **/
>> >>> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>> >>>
>> >>> There are only 2 hard things in computer science: Cache invalidation,
>> >> naming things, and off-by-one errors.
>> >>>
>> >>>
>> >>
>> >>
>>
>>
>
Re: 2nd UART on NRF52DK
Posted by Andrew Tam <ta...@proxy.co>.
Hi Marko,
Thanks for all the help, That's interesting, I'm running the bitbanger at
9600 on the nrf51, and the TX I can read from console, but the RX does
nothing... I will try at 4800 and see what happens!
Thanks,
- Andrew -
On Wed, Feb 15, 2017 at 4:01 PM, marko kiiskila <ma...@runtime.io> wrote:
> Hi Andrew,
>
> I just tried the UART bitbanger on nrf51, as I had not done this before.
> I was only able to run it at 4800 bps; I was getting junk at 9600.
> I did this trial by changing my console port to use the bitbanger.
>
> > On Feb 15, 2017, at 3:27 PM, Andrew Tam <ta...@proxy.co> wrote:
> >
> > HI Marko,
> >
> >
> > Thanks for the info, unfortunately I don't have a debugger running on
> this
> > machine I have put print statements into different areas of code and I
> have
> > good feeling that uart_bitbang_isr() isn't getting called, I'm assuming
> > there's a hardware interrupt that has to trigger. That said I'm running
> > this on an NRF51, not a NRF52, could there be a problem with that? I
> know
> > that your examples were made from the PRIMO which is NRF52 based, so
> > perhaps it's not possible to use the NRF51?
> >
> > Thanks again,
> >
> > - Andrew -
> >
> >
> >
> > On Mon, Feb 13, 2017 at 6:51 PM, marko kiiskila <ma...@runtime.io>
> wrote:
> >
> >> Hi Andrew,
> >>
> >> I would check if uart_bitbang_isr() is getting called. This is
> registered
> >> to get GPIO interrupt when RX line toggles to signal transmission.
> Easiest
> >> is to check this within debugger using a breakpoint.
> >>
> >> From that point on, the driver samples the line with a timer, using the
> >> same timer as the TX side.
> >>
> >> So if TX is working, then I'm guessing the RX interrupt is not happening
> >> for some reason.
> >>
> >>
> >> On Mon, Feb 13, 2017 at 14:09 Andrew Tam <ta...@proxy.co> wrote:
> >>
> >> Hi Marko,
> >>
> >> Sorry to bother you again, the TX side is working and we're able to see
> >> data on the TX pin, but is there something that I need to do to get the
> RX
> >> side working? I've started the RX in the main loop and I can see '1's
> >> being passed to the RX pin, but the rx_char function doesn't seem to be
> >> working?
> >>
> >> we have something like this:
> >>
> >> =======
> >> uart1_rx_char(void *arg, uint8_t byte){
> >>
> >> BLEPRPH_LOG(INFO, "cmd: byte value = %d \n", byte);
> >> if (byte == '1') {
> >> hal_gpio_write(CMD_IO_PIN, 1);
> >> } else if (byte == '0') {
> >> hal_gpio_write(CMD_IO_PIN, 0);
> >> }
> >> return 0;
> >> }
> >> ======
> >>
> >> Any idea?
> >>
> >> Thanks,
> >>
> >> - Andrew -
> >>
> >> On Wed, Feb 1, 2017 at 6:44 PM, Andrew Tam <ta...@proxy.co> wrote:
> >>
> >>> Thanks marko! we got it up and running!
> >>>
> >>> Cheers,
> >>>
> >>> - Andrew -
> >>>
> >>> On Wed, Feb 1, 2017 at 3:13 PM, marko kiiskila <ma...@runtime.io>
> wrote:
> >>>
> >>>> Hi Andrew,
> >>>>
> >>>>> On Feb 1, 2017, at 12:01 PM, Andrew Tam <ta...@proxy.co> wrote:
> >>>>>
> >>>>> Hi Marko,
> >>>>>
> >>>>> I've followed what you did in the Arduino Primo bsp file to setup the
> >>>> UART1
> >>>>> pins. Looks like my project will compile without errors, But I was
> >>>> unable
> >>>>> to see anything coming over the UART1 TX. Is there a sequence that
> >>>> needs
> >>>>> to be followed when sending the data?
> >>>>
> >>>> Take a look at following as an example:
> >>>> https://github.com/runtimeinc/mynewt_arduino_zero/blob/devel
> >>>> op/libs/espduino/src/espduino.c <https://github.com/runtimeinc
> >>>> /mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c>
> >>>>
> >>>> That might easier to read than the sys/console/full package.
> >>>>
> >>>>>
> >>>>> for example to send a blocking tx byte (with vaule "1" every second)
> >>>> we're
> >>>>> using something like this:
> >>>>>
> >>>>> uart_timer_cb(struct os_event *ev) {
> >>>>> uart_start_tx(uart1);
> >>>>> uart_blocking_tx(uart1,'1');
> >>>>> os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
> >>>>> hal_gpio_toggle(LED_BLINK_PIN);
> >>>>> }
> >>>>>
> >>>>> The gpio toggles ~ ever second so we know the timer is working. but
> >>>> maybe
> >>>>> we've forgotten something?
> >>>>
> >>>> Well, the blocking TX was only meant to be used when running without
> >>>> interrupts enabled. And once the device enters blocking TX mode,
> there’s
> >>>> no going back. It only exists so that we can print out data when
> system
> >>>> crashes, to print out assert() line and MCU register dump.
> >>>>
> >>>> So you should implement the functions which implement the asynchronous
> >>>> interface.
> >>>>
> >>>> So the code you’re after could look something like this:
> >>>>
> >>>> static int sent_one = 0;
> >>>>
> >>>> static int
> >>>> uart1_tx(void *arg)
> >>>> {
> >>>> /* send one ‘1’ character, then stop */
> >>>> if (!sent_one) {
> >>>> sent_one = 1;
> >>>> return ‘1’;
> >>>> } else {
> >>>> return -1;
> >>>> }
> >>>> }
> >>>>
> >>>> and then in your task (or main()) say:
> >>>>
> >>>> while (1) {
> >>>> os_time_delay(OS_TICKS_PER_SEC);
> >>>> sent_one = 0;
> >>>> uart_start_tx(uart1);
> >>>> }
> >>>>
> >>>> I.e. you start transmitting data by calling uart_start_tx().
> >>>> UART driver keeps asking for more data to send by calling
> >>>> the .uc_tx_char function. The driver calls this according
> >>>> to speed that these bytes are being sent out.
> >>>> When there is no more data to send, you should return < 0
> >>>> from the uc_tx_char function.
> >>>>
> >>>> Here’s another link:
> >>>> https://github.com/apache/incubator-mynewt-site/blob/develop
> >>>> /docs/os/tutorials/air_quality_sensor.md
> >>>> This uses the HAL directly, but the tx/rx character functions
> >>>> behave the same when going through UART driver.
> >>>>
> >>>> Hope this helps,
> >>>> M
> >>>>
> >>>>>
> >>>>> Thanks for the help!
> >>>>>
> >>>>> - Andrew -
> >>>>>
> >>>>>
> >>>>> On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
> >>>>>
> >>>>>> Thanks Marko,
> >>>>>>
> >>>>>> I think I got some of it sorted, I found the header file for the
> >>>>>> bitbanger uart and I think I should be good.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> - Andrew -
> >>>>>>
> >>>>>> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io>
> >>>> wrote:
> >>>>>>
> >>>>>>> Hi Andrew,
> >>>>>>>
> >>>>>>> the example is the arduino primo BSP.
> >>>>>>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c,
> >> specifically
> >>>>>>> the setup of UART0 and UART1.
> >>>>>>>
> >>>>>>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
> >>>>>>>
> >>>>>>>> On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
> >>>>>>>>
> >>>>>>>> I'm currently looking into using the 2nd UART as well, I was
> doing
> >>>> some
> >>>>>>>> reading on the nrf52dk pins and looks like pins P0.22 / P0.23 /
> >>>> P0.24 /
> >>>>>>>> P0.25 could also be good options.
> >>>>>>>>
> >>>>>>>> I'm curious to know if there was some example code as to how you
> >> set
> >>>>>>> this
> >>>>>>>> up on the nrf52?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> - Andrew -
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <
> marko@runtime.io
> >>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I did operate it only Arduino Primo, where the 2nd UART was my
> >>>> console
> >>>>>>>>> (or maybe it was the connection to ESP8266?).
> >>>>>>>>>
> >>>>>>>>> Looks like the pins used on that BSP are 11 and 12.
> >>>>>>>>> I would pick whichever is most easily accessible from the
> >> connector
> >>>> :)
> >>>>>>>>>
> >>>>>>>>>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <santafen@mac.com
> >
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <marko@runtime.io
> >
> >>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my
> >> console.
> >>>>>>>>>>> If I remember correctly, the hal timer used by the bitbanger
> was
> >>>>>>> running
> >>>>>>>>>>> at 1MHz.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> What pins on the NRF52dk are you using? The syscfg.yml has only
> >>>>>>>>>> UART_1:
> >>>>>>>>>> description: 'Bitbanger UART'
> >>>>>>>>>> value: 0
> >>>>>>>>>>
> >>>>>>>>>> defined for UART_1 so I'll need to configure pins for
> >> UART_0_PIN_TX
> >>>>>>> and
> >>>>>>>>> UART_0_PIN_RX:
> >>>>>>>>>>
> >>>>>>>>>> Suggestions?
> >>>>>>>>>>
> >>>>>>>>>> dg
> >>>>>>>>>> --
> >>>>>>>>>> David G. Simmons
> >>>>>>>>>> (919) 534-5099
> >>>>>>>>>> Web <https://davidgs.com/> • Blog <
> https://davidgs.com/davidgs_b
> >>>> log>
> >>>>>>> •
> >>>>>>>>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
> >>>>>>>>> http://twitter.com/TechEvangelist1> • GitHub <
> >>>>>>> http://github.com/davidgs>
> >>>>>>>>>> /** Message digitally signed for security and authenticity.
> >>>>>>>>>> * If you cannot read the PGP.sig attachment, please go to
> >>>>>>>>>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your
> >>>> email!!!
> >>>>>>>>>> * Public key available at keyserver.pgp.com <
> >>>>>>> http://keyserver.pgp.com/>
> >>>>>>>>>> **/
> >>>>>>>>>> ♺ This email uses 100% recycled electrons. Don't blow it by
> >>>> printing!
> >>>>>>>>>>
> >>>>>>>>>> There are only 2 hard things in computer science: Cache
> >>>> invalidation,
> >>>>>>>>> naming things, and off-by-one errors.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: 2nd UART on NRF52DK
Posted by marko kiiskila <ma...@runtime.io>.
Hi Andrew,
I just tried the UART bitbanger on nrf51, as I had not done this before.
I was only able to run it at 4800 bps; I was getting junk at 9600.
I did this trial by changing my console port to use the bitbanger.
> On Feb 15, 2017, at 3:27 PM, Andrew Tam <ta...@proxy.co> wrote:
>
> HI Marko,
>
>
> Thanks for the info, unfortunately I don't have a debugger running on this
> machine I have put print statements into different areas of code and I have
> good feeling that uart_bitbang_isr() isn't getting called, I'm assuming
> there's a hardware interrupt that has to trigger. That said I'm running
> this on an NRF51, not a NRF52, could there be a problem with that? I know
> that your examples were made from the PRIMO which is NRF52 based, so
> perhaps it's not possible to use the NRF51?
>
> Thanks again,
>
> - Andrew -
>
>
>
> On Mon, Feb 13, 2017 at 6:51 PM, marko kiiskila <ma...@runtime.io> wrote:
>
>> Hi Andrew,
>>
>> I would check if uart_bitbang_isr() is getting called. This is registered
>> to get GPIO interrupt when RX line toggles to signal transmission. Easiest
>> is to check this within debugger using a breakpoint.
>>
>> From that point on, the driver samples the line with a timer, using the
>> same timer as the TX side.
>>
>> So if TX is working, then I'm guessing the RX interrupt is not happening
>> for some reason.
>>
>>
>> On Mon, Feb 13, 2017 at 14:09 Andrew Tam <ta...@proxy.co> wrote:
>>
>> Hi Marko,
>>
>> Sorry to bother you again, the TX side is working and we're able to see
>> data on the TX pin, but is there something that I need to do to get the RX
>> side working? I've started the RX in the main loop and I can see '1's
>> being passed to the RX pin, but the rx_char function doesn't seem to be
>> working?
>>
>> we have something like this:
>>
>> =======
>> uart1_rx_char(void *arg, uint8_t byte){
>>
>> BLEPRPH_LOG(INFO, "cmd: byte value = %d \n", byte);
>> if (byte == '1') {
>> hal_gpio_write(CMD_IO_PIN, 1);
>> } else if (byte == '0') {
>> hal_gpio_write(CMD_IO_PIN, 0);
>> }
>> return 0;
>> }
>> ======
>>
>> Any idea?
>>
>> Thanks,
>>
>> - Andrew -
>>
>> On Wed, Feb 1, 2017 at 6:44 PM, Andrew Tam <ta...@proxy.co> wrote:
>>
>>> Thanks marko! we got it up and running!
>>>
>>> Cheers,
>>>
>>> - Andrew -
>>>
>>> On Wed, Feb 1, 2017 at 3:13 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>>> On Feb 1, 2017, at 12:01 PM, Andrew Tam <ta...@proxy.co> wrote:
>>>>>
>>>>> Hi Marko,
>>>>>
>>>>> I've followed what you did in the Arduino Primo bsp file to setup the
>>>> UART1
>>>>> pins. Looks like my project will compile without errors, But I was
>>>> unable
>>>>> to see anything coming over the UART1 TX. Is there a sequence that
>>>> needs
>>>>> to be followed when sending the data?
>>>>
>>>> Take a look at following as an example:
>>>> https://github.com/runtimeinc/mynewt_arduino_zero/blob/devel
>>>> op/libs/espduino/src/espduino.c <https://github.com/runtimeinc
>>>> /mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c>
>>>>
>>>> That might easier to read than the sys/console/full package.
>>>>
>>>>>
>>>>> for example to send a blocking tx byte (with vaule "1" every second)
>>>> we're
>>>>> using something like this:
>>>>>
>>>>> uart_timer_cb(struct os_event *ev) {
>>>>> uart_start_tx(uart1);
>>>>> uart_blocking_tx(uart1,'1');
>>>>> os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
>>>>> hal_gpio_toggle(LED_BLINK_PIN);
>>>>> }
>>>>>
>>>>> The gpio toggles ~ ever second so we know the timer is working. but
>>>> maybe
>>>>> we've forgotten something?
>>>>
>>>> Well, the blocking TX was only meant to be used when running without
>>>> interrupts enabled. And once the device enters blocking TX mode, there’s
>>>> no going back. It only exists so that we can print out data when system
>>>> crashes, to print out assert() line and MCU register dump.
>>>>
>>>> So you should implement the functions which implement the asynchronous
>>>> interface.
>>>>
>>>> So the code you’re after could look something like this:
>>>>
>>>> static int sent_one = 0;
>>>>
>>>> static int
>>>> uart1_tx(void *arg)
>>>> {
>>>> /* send one ‘1’ character, then stop */
>>>> if (!sent_one) {
>>>> sent_one = 1;
>>>> return ‘1’;
>>>> } else {
>>>> return -1;
>>>> }
>>>> }
>>>>
>>>> and then in your task (or main()) say:
>>>>
>>>> while (1) {
>>>> os_time_delay(OS_TICKS_PER_SEC);
>>>> sent_one = 0;
>>>> uart_start_tx(uart1);
>>>> }
>>>>
>>>> I.e. you start transmitting data by calling uart_start_tx().
>>>> UART driver keeps asking for more data to send by calling
>>>> the .uc_tx_char function. The driver calls this according
>>>> to speed that these bytes are being sent out.
>>>> When there is no more data to send, you should return < 0
>>>> from the uc_tx_char function.
>>>>
>>>> Here’s another link:
>>>> https://github.com/apache/incubator-mynewt-site/blob/develop
>>>> /docs/os/tutorials/air_quality_sensor.md
>>>> This uses the HAL directly, but the tx/rx character functions
>>>> behave the same when going through UART driver.
>>>>
>>>> Hope this helps,
>>>> M
>>>>
>>>>>
>>>>> Thanks for the help!
>>>>>
>>>>> - Andrew -
>>>>>
>>>>>
>>>>> On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
>>>>>
>>>>>> Thanks Marko,
>>>>>>
>>>>>> I think I got some of it sorted, I found the header file for the
>>>>>> bitbanger uart and I think I should be good.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> - Andrew -
>>>>>>
>>>>>> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io>
>>>> wrote:
>>>>>>
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> the example is the arduino primo BSP.
>>>>>>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c,
>> specifically
>>>>>>> the setup of UART0 and UART1.
>>>>>>>
>>>>>>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
>>>>>>>
>>>>>>>> On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
>>>>>>>>
>>>>>>>> I'm currently looking into using the 2nd UART as well, I was doing
>>>> some
>>>>>>>> reading on the nrf52dk pins and looks like pins P0.22 / P0.23 /
>>>> P0.24 /
>>>>>>>> P0.25 could also be good options.
>>>>>>>>
>>>>>>>> I'm curious to know if there was some example code as to how you
>> set
>>>>>>> this
>>>>>>>> up on the nrf52?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> - Andrew -
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <marko@runtime.io
>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I did operate it only Arduino Primo, where the 2nd UART was my
>>>> console
>>>>>>>>> (or maybe it was the connection to ESP8266?).
>>>>>>>>>
>>>>>>>>> Looks like the pins used on that BSP are 11 and 12.
>>>>>>>>> I would pick whichever is most easily accessible from the
>> connector
>>>> :)
>>>>>>>>>
>>>>>>>>>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <sa...@mac.com>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <ma...@runtime.io>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my
>> console.
>>>>>>>>>>> If I remember correctly, the hal timer used by the bitbanger was
>>>>>>> running
>>>>>>>>>>> at 1MHz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What pins on the NRF52dk are you using? The syscfg.yml has only
>>>>>>>>>> UART_1:
>>>>>>>>>> description: 'Bitbanger UART'
>>>>>>>>>> value: 0
>>>>>>>>>>
>>>>>>>>>> defined for UART_1 so I'll need to configure pins for
>> UART_0_PIN_TX
>>>>>>> and
>>>>>>>>> UART_0_PIN_RX:
>>>>>>>>>>
>>>>>>>>>> Suggestions?
>>>>>>>>>>
>>>>>>>>>> dg
>>>>>>>>>> --
>>>>>>>>>> David G. Simmons
>>>>>>>>>> (919) 534-5099
>>>>>>>>>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_b
>>>> log>
>>>>>>> •
>>>>>>>>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
>>>>>>>>> http://twitter.com/TechEvangelist1> • GitHub <
>>>>>>> http://github.com/davidgs>
>>>>>>>>>> /** Message digitally signed for security and authenticity.
>>>>>>>>>> * If you cannot read the PGP.sig attachment, please go to
>>>>>>>>>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your
>>>> email!!!
>>>>>>>>>> * Public key available at keyserver.pgp.com <
>>>>>>> http://keyserver.pgp.com/>
>>>>>>>>>> **/
>>>>>>>>>> ♺ This email uses 100% recycled electrons. Don't blow it by
>>>> printing!
>>>>>>>>>>
>>>>>>>>>> There are only 2 hard things in computer science: Cache
>>>> invalidation,
>>>>>>>>> naming things, and off-by-one errors.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
Re: 2nd UART on NRF52DK
Posted by Andrew Tam <ta...@proxy.co>.
HI Marko,
Thanks for the info, unfortunately I don't have a debugger running on this
machine I have put print statements into different areas of code and I have
good feeling that uart_bitbang_isr() isn't getting called, I'm assuming
there's a hardware interrupt that has to trigger. That said I'm running
this on an NRF51, not a NRF52, could there be a problem with that? I know
that your examples were made from the PRIMO which is NRF52 based, so
perhaps it's not possible to use the NRF51?
Thanks again,
- Andrew -
On Mon, Feb 13, 2017 at 6:51 PM, marko kiiskila <ma...@runtime.io> wrote:
> Hi Andrew,
>
> I would check if uart_bitbang_isr() is getting called. This is registered
> to get GPIO interrupt when RX line toggles to signal transmission. Easiest
> is to check this within debugger using a breakpoint.
>
> From that point on, the driver samples the line with a timer, using the
> same timer as the TX side.
>
> So if TX is working, then I'm guessing the RX interrupt is not happening
> for some reason.
>
>
> On Mon, Feb 13, 2017 at 14:09 Andrew Tam <ta...@proxy.co> wrote:
>
> Hi Marko,
>
> Sorry to bother you again, the TX side is working and we're able to see
> data on the TX pin, but is there something that I need to do to get the RX
> side working? I've started the RX in the main loop and I can see '1's
> being passed to the RX pin, but the rx_char function doesn't seem to be
> working?
>
> we have something like this:
>
> =======
> uart1_rx_char(void *arg, uint8_t byte){
>
> BLEPRPH_LOG(INFO, "cmd: byte value = %d \n", byte);
> if (byte == '1') {
> hal_gpio_write(CMD_IO_PIN, 1);
> } else if (byte == '0') {
> hal_gpio_write(CMD_IO_PIN, 0);
> }
> return 0;
> }
> ======
>
> Any idea?
>
> Thanks,
>
> - Andrew -
>
> On Wed, Feb 1, 2017 at 6:44 PM, Andrew Tam <ta...@proxy.co> wrote:
>
> > Thanks marko! we got it up and running!
> >
> > Cheers,
> >
> > - Andrew -
> >
> > On Wed, Feb 1, 2017 at 3:13 PM, marko kiiskila <ma...@runtime.io> wrote:
> >
> >> Hi Andrew,
> >>
> >> > On Feb 1, 2017, at 12:01 PM, Andrew Tam <ta...@proxy.co> wrote:
> >> >
> >> > Hi Marko,
> >> >
> >> > I've followed what you did in the Arduino Primo bsp file to setup the
> >> UART1
> >> > pins. Looks like my project will compile without errors, But I was
> >> unable
> >> > to see anything coming over the UART1 TX. Is there a sequence that
> >> needs
> >> > to be followed when sending the data?
> >>
> >> Take a look at following as an example:
> >> https://github.com/runtimeinc/mynewt_arduino_zero/blob/devel
> >> op/libs/espduino/src/espduino.c <https://github.com/runtimeinc
> >> /mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c>
> >>
> >> That might easier to read than the sys/console/full package.
> >>
> >> >
> >> > for example to send a blocking tx byte (with vaule "1" every second)
> >> we're
> >> > using something like this:
> >> >
> >> > uart_timer_cb(struct os_event *ev) {
> >> > uart_start_tx(uart1);
> >> > uart_blocking_tx(uart1,'1');
> >> > os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
> >> > hal_gpio_toggle(LED_BLINK_PIN);
> >> > }
> >> >
> >> > The gpio toggles ~ ever second so we know the timer is working. but
> >> maybe
> >> > we've forgotten something?
> >>
> >> Well, the blocking TX was only meant to be used when running without
> >> interrupts enabled. And once the device enters blocking TX mode, there’s
> >> no going back. It only exists so that we can print out data when system
> >> crashes, to print out assert() line and MCU register dump.
> >>
> >> So you should implement the functions which implement the asynchronous
> >> interface.
> >>
> >> So the code you’re after could look something like this:
> >>
> >> static int sent_one = 0;
> >>
> >> static int
> >> uart1_tx(void *arg)
> >> {
> >> /* send one ‘1’ character, then stop */
> >> if (!sent_one) {
> >> sent_one = 1;
> >> return ‘1’;
> >> } else {
> >> return -1;
> >> }
> >> }
> >>
> >> and then in your task (or main()) say:
> >>
> >> while (1) {
> >> os_time_delay(OS_TICKS_PER_SEC);
> >> sent_one = 0;
> >> uart_start_tx(uart1);
> >> }
> >>
> >> I.e. you start transmitting data by calling uart_start_tx().
> >> UART driver keeps asking for more data to send by calling
> >> the .uc_tx_char function. The driver calls this according
> >> to speed that these bytes are being sent out.
> >> When there is no more data to send, you should return < 0
> >> from the uc_tx_char function.
> >>
> >> Here’s another link:
> >> https://github.com/apache/incubator-mynewt-site/blob/develop
> >> /docs/os/tutorials/air_quality_sensor.md
> >> This uses the HAL directly, but the tx/rx character functions
> >> behave the same when going through UART driver.
> >>
> >> Hope this helps,
> >> M
> >>
> >> >
> >> > Thanks for the help!
> >> >
> >> > - Andrew -
> >> >
> >> >
> >> > On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
> >> >
> >> >> Thanks Marko,
> >> >>
> >> >> I think I got some of it sorted, I found the header file for the
> >> >> bitbanger uart and I think I should be good.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> - Andrew -
> >> >>
> >> >> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io>
> >> wrote:
> >> >>
> >> >>> Hi Andrew,
> >> >>>
> >> >>> the example is the arduino primo BSP.
> >> >>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c,
> specifically
> >> >>> the setup of UART0 and UART1.
> >> >>>
> >> >>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
> >> >>>
> >> >>>> On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
> >> >>>>
> >> >>>> I'm currently looking into using the 2nd UART as well, I was doing
> >> some
> >> >>>> reading on the nrf52dk pins and looks like pins P0.22 / P0.23 /
> >> P0.24 /
> >> >>>> P0.25 could also be good options.
> >> >>>>
> >> >>>> I'm curious to know if there was some example code as to how you
> set
> >> >>> this
> >> >>>> up on the nrf52?
> >> >>>>
> >> >>>> Thanks,
> >> >>>>
> >> >>>> - Andrew -
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <marko@runtime.io
> >
> >> >>> wrote:
> >> >>>>
> >> >>>>> I did operate it only Arduino Primo, where the 2nd UART was my
> >> console
> >> >>>>> (or maybe it was the connection to ESP8266?).
> >> >>>>>
> >> >>>>> Looks like the pins used on that BSP are 11 and 12.
> >> >>>>> I would pick whichever is most easily accessible from the
> connector
> >> :)
> >> >>>>>
> >> >>>>>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <sa...@mac.com>
> >> >>> wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <ma...@runtime.io>
> >> >>> wrote:
> >> >>>>>>>
> >> >>>>>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my
> console.
> >> >>>>>>> If I remember correctly, the hal timer used by the bitbanger was
> >> >>> running
> >> >>>>>>> at 1MHz.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> What pins on the NRF52dk are you using? The syscfg.yml has only
> >> >>>>>> UART_1:
> >> >>>>>> description: 'Bitbanger UART'
> >> >>>>>> value: 0
> >> >>>>>>
> >> >>>>>> defined for UART_1 so I'll need to configure pins for
> UART_0_PIN_TX
> >> >>> and
> >> >>>>> UART_0_PIN_RX:
> >> >>>>>>
> >> >>>>>> Suggestions?
> >> >>>>>>
> >> >>>>>> dg
> >> >>>>>> --
> >> >>>>>> David G. Simmons
> >> >>>>>> (919) 534-5099
> >> >>>>>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_b
> >> log>
> >> >>> •
> >> >>>>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
> >> >>>>> http://twitter.com/TechEvangelist1> • GitHub <
> >> >>> http://github.com/davidgs>
> >> >>>>>> /** Message digitally signed for security and authenticity.
> >> >>>>>> * If you cannot read the PGP.sig attachment, please go to
> >> >>>>>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your
> >> email!!!
> >> >>>>>> * Public key available at keyserver.pgp.com <
> >> >>> http://keyserver.pgp.com/>
> >> >>>>>> **/
> >> >>>>>> ♺ This email uses 100% recycled electrons. Don't blow it by
> >> printing!
> >> >>>>>>
> >> >>>>>> There are only 2 hard things in computer science: Cache
> >> invalidation,
> >> >>>>> naming things, and off-by-one errors.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>>
> >> >>
> >>
> >>
> >
>
Re: 2nd UART on NRF52DK
Posted by marko kiiskila <ma...@runtime.io>.
Hi Andrew,
I would check if uart_bitbang_isr() is getting called. This is registered
to get GPIO interrupt when RX line toggles to signal transmission. Easiest
is to check this within debugger using a breakpoint.
From that point on, the driver samples the line with a timer, using the
same timer as the TX side.
So if TX is working, then I'm guessing the RX interrupt is not happening
for some reason.
On Mon, Feb 13, 2017 at 14:09 Andrew Tam <ta...@proxy.co> wrote:
Hi Marko,
Sorry to bother you again, the TX side is working and we're able to see
data on the TX pin, but is there something that I need to do to get the RX
side working? I've started the RX in the main loop and I can see '1's
being passed to the RX pin, but the rx_char function doesn't seem to be
working?
we have something like this:
=======
uart1_rx_char(void *arg, uint8_t byte){
BLEPRPH_LOG(INFO, "cmd: byte value = %d \n", byte);
if (byte == '1') {
hal_gpio_write(CMD_IO_PIN, 1);
} else if (byte == '0') {
hal_gpio_write(CMD_IO_PIN, 0);
}
return 0;
}
======
Any idea?
Thanks,
- Andrew -
On Wed, Feb 1, 2017 at 6:44 PM, Andrew Tam <ta...@proxy.co> wrote:
> Thanks marko! we got it up and running!
>
> Cheers,
>
> - Andrew -
>
> On Wed, Feb 1, 2017 at 3:13 PM, marko kiiskila <ma...@runtime.io> wrote:
>
>> Hi Andrew,
>>
>> > On Feb 1, 2017, at 12:01 PM, Andrew Tam <ta...@proxy.co> wrote:
>> >
>> > Hi Marko,
>> >
>> > I've followed what you did in the Arduino Primo bsp file to setup the
>> UART1
>> > pins. Looks like my project will compile without errors, But I was
>> unable
>> > to see anything coming over the UART1 TX. Is there a sequence that
>> needs
>> > to be followed when sending the data?
>>
>> Take a look at following as an example:
>> https://github.com/runtimeinc/mynewt_arduino_zero/blob/devel
>> op/libs/espduino/src/espduino.c <https://github.com/runtimeinc
>> /mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c>
>>
>> That might easier to read than the sys/console/full package.
>>
>> >
>> > for example to send a blocking tx byte (with vaule "1" every second)
>> we're
>> > using something like this:
>> >
>> > uart_timer_cb(struct os_event *ev) {
>> > uart_start_tx(uart1);
>> > uart_blocking_tx(uart1,'1');
>> > os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
>> > hal_gpio_toggle(LED_BLINK_PIN);
>> > }
>> >
>> > The gpio toggles ~ ever second so we know the timer is working. but
>> maybe
>> > we've forgotten something?
>>
>> Well, the blocking TX was only meant to be used when running without
>> interrupts enabled. And once the device enters blocking TX mode, there’s
>> no going back. It only exists so that we can print out data when system
>> crashes, to print out assert() line and MCU register dump.
>>
>> So you should implement the functions which implement the asynchronous
>> interface.
>>
>> So the code you’re after could look something like this:
>>
>> static int sent_one = 0;
>>
>> static int
>> uart1_tx(void *arg)
>> {
>> /* send one ‘1’ character, then stop */
>> if (!sent_one) {
>> sent_one = 1;
>> return ‘1’;
>> } else {
>> return -1;
>> }
>> }
>>
>> and then in your task (or main()) say:
>>
>> while (1) {
>> os_time_delay(OS_TICKS_PER_SEC);
>> sent_one = 0;
>> uart_start_tx(uart1);
>> }
>>
>> I.e. you start transmitting data by calling uart_start_tx().
>> UART driver keeps asking for more data to send by calling
>> the .uc_tx_char function. The driver calls this according
>> to speed that these bytes are being sent out.
>> When there is no more data to send, you should return < 0
>> from the uc_tx_char function.
>>
>> Here’s another link:
>> https://github.com/apache/incubator-mynewt-site/blob/develop
>> /docs/os/tutorials/air_quality_sensor.md
>> This uses the HAL directly, but the tx/rx character functions
>> behave the same when going through UART driver.
>>
>> Hope this helps,
>> M
>>
>> >
>> > Thanks for the help!
>> >
>> > - Andrew -
>> >
>> >
>> > On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
>> >
>> >> Thanks Marko,
>> >>
>> >> I think I got some of it sorted, I found the header file for the
>> >> bitbanger uart and I think I should be good.
>> >>
>> >> Cheers,
>> >>
>> >> - Andrew -
>> >>
>> >> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io>
>> wrote:
>> >>
>> >>> Hi Andrew,
>> >>>
>> >>> the example is the arduino primo BSP.
>> >>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c, specifically
>> >>> the setup of UART0 and UART1.
>> >>>
>> >>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
>> >>>
>> >>>> On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
>> >>>>
>> >>>> I'm currently looking into using the 2nd UART as well, I was doing
>> some
>> >>>> reading on the nrf52dk pins and looks like pins P0.22 / P0.23 /
>> P0.24 /
>> >>>> P0.25 could also be good options.
>> >>>>
>> >>>> I'm curious to know if there was some example code as to how you set
>> >>> this
>> >>>> up on the nrf52?
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> - Andrew -
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <ma...@runtime.io>
>> >>> wrote:
>> >>>>
>> >>>>> I did operate it only Arduino Primo, where the 2nd UART was my
>> console
>> >>>>> (or maybe it was the connection to ESP8266?).
>> >>>>>
>> >>>>> Looks like the pins used on that BSP are 11 and 12.
>> >>>>> I would pick whichever is most easily accessible from the connector
>> :)
>> >>>>>
>> >>>>>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <sa...@mac.com>
>> >>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <ma...@runtime.io>
>> >>> wrote:
>> >>>>>>>
>> >>>>>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my
console.
>> >>>>>>> If I remember correctly, the hal timer used by the bitbanger was
>> >>> running
>> >>>>>>> at 1MHz.
>> >>>>>>
>> >>>>>>
>> >>>>>> What pins on the NRF52dk are you using? The syscfg.yml has only
>> >>>>>> UART_1:
>> >>>>>> description: 'Bitbanger UART'
>> >>>>>> value: 0
>> >>>>>>
>> >>>>>> defined for UART_1 so I'll need to configure pins for
UART_0_PIN_TX
>> >>> and
>> >>>>> UART_0_PIN_RX:
>> >>>>>>
>> >>>>>> Suggestions?
>> >>>>>>
>> >>>>>> dg
>> >>>>>> --
>> >>>>>> David G. Simmons
>> >>>>>> (919) 534-5099
>> >>>>>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_b
>> log>
>> >>> •
>> >>>>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
>> >>>>> http://twitter.com/TechEvangelist1> • GitHub <
>> >>> http://github.com/davidgs>
>> >>>>>> /** Message digitally signed for security and authenticity.
>> >>>>>> * If you cannot read the PGP.sig attachment, please go to
>> >>>>>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your
>> email!!!
>> >>>>>> * Public key available at keyserver.pgp.com <
>> >>> http://keyserver.pgp.com/>
>> >>>>>> **/
>> >>>>>> ♺ This email uses 100% recycled electrons. Don't blow it by
>> printing!
>> >>>>>>
>> >>>>>> There are only 2 hard things in computer science: Cache
>> invalidation,
>> >>>>> naming things, and off-by-one errors.
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>>
>> >>
>>
>>
>
Re: 2nd UART on NRF52DK
Posted by Andrew Tam <ta...@proxy.co>.
Hi Marko,
Sorry to bother you again, the TX side is working and we're able to see
data on the TX pin, but is there something that I need to do to get the RX
side working? I've started the RX in the main loop and I can see '1's
being passed to the RX pin, but the rx_char function doesn't seem to be
working?
we have something like this:
=======
uart1_rx_char(void *arg, uint8_t byte){
BLEPRPH_LOG(INFO, "cmd: byte value = %d \n", byte);
if (byte == '1') {
hal_gpio_write(CMD_IO_PIN, 1);
} else if (byte == '0') {
hal_gpio_write(CMD_IO_PIN, 0);
}
return 0;
}
======
Any idea?
Thanks,
- Andrew -
On Wed, Feb 1, 2017 at 6:44 PM, Andrew Tam <ta...@proxy.co> wrote:
> Thanks marko! we got it up and running!
>
> Cheers,
>
> - Andrew -
>
> On Wed, Feb 1, 2017 at 3:13 PM, marko kiiskila <ma...@runtime.io> wrote:
>
>> Hi Andrew,
>>
>> > On Feb 1, 2017, at 12:01 PM, Andrew Tam <ta...@proxy.co> wrote:
>> >
>> > Hi Marko,
>> >
>> > I've followed what you did in the Arduino Primo bsp file to setup the
>> UART1
>> > pins. Looks like my project will compile without errors, But I was
>> unable
>> > to see anything coming over the UART1 TX. Is there a sequence that
>> needs
>> > to be followed when sending the data?
>>
>> Take a look at following as an example:
>> https://github.com/runtimeinc/mynewt_arduino_zero/blob/devel
>> op/libs/espduino/src/espduino.c <https://github.com/runtimeinc
>> /mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c>
>>
>> That might easier to read than the sys/console/full package.
>>
>> >
>> > for example to send a blocking tx byte (with vaule "1" every second)
>> we're
>> > using something like this:
>> >
>> > uart_timer_cb(struct os_event *ev) {
>> > uart_start_tx(uart1);
>> > uart_blocking_tx(uart1,'1');
>> > os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
>> > hal_gpio_toggle(LED_BLINK_PIN);
>> > }
>> >
>> > The gpio toggles ~ ever second so we know the timer is working. but
>> maybe
>> > we've forgotten something?
>>
>> Well, the blocking TX was only meant to be used when running without
>> interrupts enabled. And once the device enters blocking TX mode, there’s
>> no going back. It only exists so that we can print out data when system
>> crashes, to print out assert() line and MCU register dump.
>>
>> So you should implement the functions which implement the asynchronous
>> interface.
>>
>> So the code you’re after could look something like this:
>>
>> static int sent_one = 0;
>>
>> static int
>> uart1_tx(void *arg)
>> {
>> /* send one ‘1’ character, then stop */
>> if (!sent_one) {
>> sent_one = 1;
>> return ‘1’;
>> } else {
>> return -1;
>> }
>> }
>>
>> and then in your task (or main()) say:
>>
>> while (1) {
>> os_time_delay(OS_TICKS_PER_SEC);
>> sent_one = 0;
>> uart_start_tx(uart1);
>> }
>>
>> I.e. you start transmitting data by calling uart_start_tx().
>> UART driver keeps asking for more data to send by calling
>> the .uc_tx_char function. The driver calls this according
>> to speed that these bytes are being sent out.
>> When there is no more data to send, you should return < 0
>> from the uc_tx_char function.
>>
>> Here’s another link:
>> https://github.com/apache/incubator-mynewt-site/blob/develop
>> /docs/os/tutorials/air_quality_sensor.md
>> This uses the HAL directly, but the tx/rx character functions
>> behave the same when going through UART driver.
>>
>> Hope this helps,
>> M
>>
>> >
>> > Thanks for the help!
>> >
>> > - Andrew -
>> >
>> >
>> > On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
>> >
>> >> Thanks Marko,
>> >>
>> >> I think I got some of it sorted, I found the header file for the
>> >> bitbanger uart and I think I should be good.
>> >>
>> >> Cheers,
>> >>
>> >> - Andrew -
>> >>
>> >> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io>
>> wrote:
>> >>
>> >>> Hi Andrew,
>> >>>
>> >>> the example is the arduino primo BSP.
>> >>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c, specifically
>> >>> the setup of UART0 and UART1.
>> >>>
>> >>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
>> >>>
>> >>>> On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
>> >>>>
>> >>>> I'm currently looking into using the 2nd UART as well, I was doing
>> some
>> >>>> reading on the nrf52dk pins and looks like pins P0.22 / P0.23 /
>> P0.24 /
>> >>>> P0.25 could also be good options.
>> >>>>
>> >>>> I'm curious to know if there was some example code as to how you set
>> >>> this
>> >>>> up on the nrf52?
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> - Andrew -
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <ma...@runtime.io>
>> >>> wrote:
>> >>>>
>> >>>>> I did operate it only Arduino Primo, where the 2nd UART was my
>> console
>> >>>>> (or maybe it was the connection to ESP8266?).
>> >>>>>
>> >>>>> Looks like the pins used on that BSP are 11 and 12.
>> >>>>> I would pick whichever is most easily accessible from the connector
>> :)
>> >>>>>
>> >>>>>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <sa...@mac.com>
>> >>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <ma...@runtime.io>
>> >>> wrote:
>> >>>>>>>
>> >>>>>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my console.
>> >>>>>>> If I remember correctly, the hal timer used by the bitbanger was
>> >>> running
>> >>>>>>> at 1MHz.
>> >>>>>>
>> >>>>>>
>> >>>>>> What pins on the NRF52dk are you using? The syscfg.yml has only
>> >>>>>> UART_1:
>> >>>>>> description: 'Bitbanger UART'
>> >>>>>> value: 0
>> >>>>>>
>> >>>>>> defined for UART_1 so I'll need to configure pins for UART_0_PIN_TX
>> >>> and
>> >>>>> UART_0_PIN_RX:
>> >>>>>>
>> >>>>>> Suggestions?
>> >>>>>>
>> >>>>>> dg
>> >>>>>> --
>> >>>>>> David G. Simmons
>> >>>>>> (919) 534-5099
>> >>>>>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_b
>> log>
>> >>> •
>> >>>>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
>> >>>>> http://twitter.com/TechEvangelist1> • GitHub <
>> >>> http://github.com/davidgs>
>> >>>>>> /** Message digitally signed for security and authenticity.
>> >>>>>> * If you cannot read the PGP.sig attachment, please go to
>> >>>>>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your
>> email!!!
>> >>>>>> * Public key available at keyserver.pgp.com <
>> >>> http://keyserver.pgp.com/>
>> >>>>>> **/
>> >>>>>> ♺ This email uses 100% recycled electrons. Don't blow it by
>> printing!
>> >>>>>>
>> >>>>>> There are only 2 hard things in computer science: Cache
>> invalidation,
>> >>>>> naming things, and off-by-one errors.
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>>
>> >>
>>
>>
>
Re: 2nd UART on NRF52DK
Posted by Andrew Tam <ta...@proxy.co>.
Thanks marko! we got it up and running!
Cheers,
- Andrew -
On Wed, Feb 1, 2017 at 3:13 PM, marko kiiskila <ma...@runtime.io> wrote:
> Hi Andrew,
>
> > On Feb 1, 2017, at 12:01 PM, Andrew Tam <ta...@proxy.co> wrote:
> >
> > Hi Marko,
> >
> > I've followed what you did in the Arduino Primo bsp file to setup the
> UART1
> > pins. Looks like my project will compile without errors, But I was
> unable
> > to see anything coming over the UART1 TX. Is there a sequence that needs
> > to be followed when sending the data?
>
> Take a look at following as an example:
> https://github.com/runtimeinc/mynewt_arduino_zero/blob/
> develop/libs/espduino/src/espduino.c <https://github.com/
> runtimeinc/mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c>
>
> That might easier to read than the sys/console/full package.
>
> >
> > for example to send a blocking tx byte (with vaule "1" every second)
> we're
> > using something like this:
> >
> > uart_timer_cb(struct os_event *ev) {
> > uart_start_tx(uart1);
> > uart_blocking_tx(uart1,'1');
> > os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
> > hal_gpio_toggle(LED_BLINK_PIN);
> > }
> >
> > The gpio toggles ~ ever second so we know the timer is working. but
> maybe
> > we've forgotten something?
>
> Well, the blocking TX was only meant to be used when running without
> interrupts enabled. And once the device enters blocking TX mode, there’s
> no going back. It only exists so that we can print out data when system
> crashes, to print out assert() line and MCU register dump.
>
> So you should implement the functions which implement the asynchronous
> interface.
>
> So the code you’re after could look something like this:
>
> static int sent_one = 0;
>
> static int
> uart1_tx(void *arg)
> {
> /* send one ‘1’ character, then stop */
> if (!sent_one) {
> sent_one = 1;
> return ‘1’;
> } else {
> return -1;
> }
> }
>
> and then in your task (or main()) say:
>
> while (1) {
> os_time_delay(OS_TICKS_PER_SEC);
> sent_one = 0;
> uart_start_tx(uart1);
> }
>
> I.e. you start transmitting data by calling uart_start_tx().
> UART driver keeps asking for more data to send by calling
> the .uc_tx_char function. The driver calls this according
> to speed that these bytes are being sent out.
> When there is no more data to send, you should return < 0
> from the uc_tx_char function.
>
> Here’s another link:
> https://github.com/apache/incubator-mynewt-site/blob/
> develop/docs/os/tutorials/air_quality_sensor.md
> This uses the HAL directly, but the tx/rx character functions
> behave the same when going through UART driver.
>
> Hope this helps,
> M
>
> >
> > Thanks for the help!
> >
> > - Andrew -
> >
> >
> > On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
> >
> >> Thanks Marko,
> >>
> >> I think I got some of it sorted, I found the header file for the
> >> bitbanger uart and I think I should be good.
> >>
> >> Cheers,
> >>
> >> - Andrew -
> >>
> >> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io>
> wrote:
> >>
> >>> Hi Andrew,
> >>>
> >>> the example is the arduino primo BSP.
> >>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c, specifically
> >>> the setup of UART0 and UART1.
> >>>
> >>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
> >>>
> >>>> On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
> >>>>
> >>>> I'm currently looking into using the 2nd UART as well, I was doing
> some
> >>>> reading on the nrf52dk pins and looks like pins P0.22 / P0.23 / P0.24
> /
> >>>> P0.25 could also be good options.
> >>>>
> >>>> I'm curious to know if there was some example code as to how you set
> >>> this
> >>>> up on the nrf52?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> - Andrew -
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <ma...@runtime.io>
> >>> wrote:
> >>>>
> >>>>> I did operate it only Arduino Primo, where the 2nd UART was my
> console
> >>>>> (or maybe it was the connection to ESP8266?).
> >>>>>
> >>>>> Looks like the pins used on that BSP are 11 and 12.
> >>>>> I would pick whichever is most easily accessible from the connector
> :)
> >>>>>
> >>>>>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <sa...@mac.com>
> >>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <ma...@runtime.io>
> >>> wrote:
> >>>>>>>
> >>>>>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my console.
> >>>>>>> If I remember correctly, the hal timer used by the bitbanger was
> >>> running
> >>>>>>> at 1MHz.
> >>>>>>
> >>>>>>
> >>>>>> What pins on the NRF52dk are you using? The syscfg.yml has only
> >>>>>> UART_1:
> >>>>>> description: 'Bitbanger UART'
> >>>>>> value: 0
> >>>>>>
> >>>>>> defined for UART_1 so I'll need to configure pins for UART_0_PIN_TX
> >>> and
> >>>>> UART_0_PIN_RX:
> >>>>>>
> >>>>>> Suggestions?
> >>>>>>
> >>>>>> dg
> >>>>>> --
> >>>>>> David G. Simmons
> >>>>>> (919) 534-5099
> >>>>>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog
> >
> >>> •
> >>>>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
> >>>>> http://twitter.com/TechEvangelist1> • GitHub <
> >>> http://github.com/davidgs>
> >>>>>> /** Message digitally signed for security and authenticity.
> >>>>>> * If you cannot read the PGP.sig attachment, please go to
> >>>>>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your
> email!!!
> >>>>>> * Public key available at keyserver.pgp.com <
> >>> http://keyserver.pgp.com/>
> >>>>>> **/
> >>>>>> ♺ This email uses 100% recycled electrons. Don't blow it by
> printing!
> >>>>>>
> >>>>>> There are only 2 hard things in computer science: Cache
> invalidation,
> >>>>> naming things, and off-by-one errors.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: 2nd UART on NRF52DK
Posted by marko kiiskila <ma...@runtime.io>.
Hi Andrew,
> On Feb 1, 2017, at 12:01 PM, Andrew Tam <ta...@proxy.co> wrote:
>
> Hi Marko,
>
> I've followed what you did in the Arduino Primo bsp file to setup the UART1
> pins. Looks like my project will compile without errors, But I was unable
> to see anything coming over the UART1 TX. Is there a sequence that needs
> to be followed when sending the data?
Take a look at following as an example:
https://github.com/runtimeinc/mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c <https://github.com/runtimeinc/mynewt_arduino_zero/blob/develop/libs/espduino/src/espduino.c>
That might easier to read than the sys/console/full package.
>
> for example to send a blocking tx byte (with vaule "1" every second) we're
> using something like this:
>
> uart_timer_cb(struct os_event *ev) {
> uart_start_tx(uart1);
> uart_blocking_tx(uart1,'1');
> os_callout_reset(&uart_timer, OS_TICKS_PER_SEC);
> hal_gpio_toggle(LED_BLINK_PIN);
> }
>
> The gpio toggles ~ ever second so we know the timer is working. but maybe
> we've forgotten something?
Well, the blocking TX was only meant to be used when running without
interrupts enabled. And once the device enters blocking TX mode, there’s
no going back. It only exists so that we can print out data when system
crashes, to print out assert() line and MCU register dump.
So you should implement the functions which implement the asynchronous interface.
So the code you’re after could look something like this:
static int sent_one = 0;
static int
uart1_tx(void *arg)
{
/* send one ‘1’ character, then stop */
if (!sent_one) {
sent_one = 1;
return ‘1’;
} else {
return -1;
}
}
and then in your task (or main()) say:
while (1) {
os_time_delay(OS_TICKS_PER_SEC);
sent_one = 0;
uart_start_tx(uart1);
}
I.e. you start transmitting data by calling uart_start_tx().
UART driver keeps asking for more data to send by calling
the .uc_tx_char function. The driver calls this according
to speed that these bytes are being sent out.
When there is no more data to send, you should return < 0
from the uc_tx_char function.
Here’s another link:
https://github.com/apache/incubator-mynewt-site/blob/develop/docs/os/tutorials/air_quality_sensor.md
This uses the HAL directly, but the tx/rx character functions
behave the same when going through UART driver.
Hope this helps,
M
>
> Thanks for the help!
>
> - Andrew -
>
>
> On Mon, Jan 30, 2017 at 4:51 PM, Andrew Tam <ta...@proxy.co> wrote:
>
>> Thanks Marko,
>>
>> I think I got some of it sorted, I found the header file for the
>> bitbanger uart and I think I should be good.
>>
>> Cheers,
>>
>> - Andrew -
>>
>> On Mon, Jan 30, 2017 at 4:43 PM, marko kiiskila <ma...@runtime.io> wrote:
>>
>>> Hi Andrew,
>>>
>>> the example is the arduino primo BSP.
>>> Take a look at hw/bsp/arduino_primo_nrf52/src/hal_bsp.c, specifically
>>> the setup of UART0 and UART1.
>>>
>>> UART0 uses HAL uart driver, while UART1 sets up bitbanger.
>>>
>>>> On Jan 30, 2017, at 3:21 PM, Andrew Tam <ta...@proxy.co> wrote:
>>>>
>>>> I'm currently looking into using the 2nd UART as well, I was doing some
>>>> reading on the nrf52dk pins and looks like pins P0.22 / P0.23 / P0.24 /
>>>> P0.25 could also be good options.
>>>>
>>>> I'm curious to know if there was some example code as to how you set
>>> this
>>>> up on the nrf52?
>>>>
>>>> Thanks,
>>>>
>>>> - Andrew -
>>>>
>>>>
>>>>
>>>> On Wed, Jan 11, 2017 at 10:17 AM, marko kiiskila <ma...@runtime.io>
>>> wrote:
>>>>
>>>>> I did operate it only Arduino Primo, where the 2nd UART was my console
>>>>> (or maybe it was the connection to ESP8266?).
>>>>>
>>>>> Looks like the pins used on that BSP are 11 and 12.
>>>>> I would pick whichever is most easily accessible from the connector :)
>>>>>
>>>>>> On Jan 11, 2017, at 6:57 AM, David G. Simmons <sa...@mac.com>
>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <ma...@runtime.io>
>>> wrote:
>>>>>>>
>>>>>>> I’ve tested the bitbanger on nrf52 with up to 19200 as my console.
>>>>>>> If I remember correctly, the hal timer used by the bitbanger was
>>> running
>>>>>>> at 1MHz.
>>>>>>
>>>>>>
>>>>>> What pins on the NRF52dk are you using? The syscfg.yml has only
>>>>>> UART_1:
>>>>>> description: 'Bitbanger UART'
>>>>>> value: 0
>>>>>>
>>>>>> defined for UART_1 so I'll need to configure pins for UART_0_PIN_TX
>>> and
>>>>> UART_0_PIN_RX:
>>>>>>
>>>>>> Suggestions?
>>>>>>
>>>>>> dg
>>>>>> --
>>>>>> David G. Simmons
>>>>>> (919) 534-5099
>>>>>> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog>
>>> •
>>>>> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <
>>>>> http://twitter.com/TechEvangelist1> • GitHub <
>>> http://github.com/davidgs>
>>>>>> /** Message digitally signed for security and authenticity.
>>>>>> * If you cannot read the PGP.sig attachment, please go to
>>>>>> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
>>>>>> * Public key available at keyserver.pgp.com <
>>> http://keyserver.pgp.com/>
>>>>>> **/
>>>>>> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>>>>>>
>>>>>> There are only 2 hard things in computer science: Cache invalidation,
>>>>> naming things, and off-by-one errors.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>