Thanks marko! we got it up and running!

Cheers,

- Andrew -

On Wed, Feb 1, 2017 at 3:13 PM, marko kiiskila <[email protected]> wrote:

> Hi Andrew,
>
> > On Feb 1, 2017, at 12:01 PM, Andrew Tam <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
> >>> 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 <[email protected]>
> >>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> On Jan 10, 2017, at 12:02 PM, marko kiiskila <[email protected]>
> >>> 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.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

Reply via email to