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 <[email protected]> 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 <[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. > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>> > >> >>> > >> >> > >> > >> > > >
