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 <[email protected]> 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 <[email protected]> wrote: > 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/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 <[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_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. >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>> >> >>> >> >> >> >> >
