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