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