Matrix user forums

The backpack must use the same read/write format as used in the FC component and the connections between the expander and LCD must match what is in the code. So not every backpack will work without modifications to the FC component. Is data being sent on the SDA line? Do you have a simple test flowc...

Guessing it is the MCP23008 expander.
http://ww1.microchip.com/downloads/en/D ... 21919e.pdf

Looks like all the ones I have now use the NXP chip.
http://www.nxp.com/documents/data_sheet ... F8574A.pdf

Backlights on the ones I have are on as soon as the backpack is powered. I have to turn them off in FC if I don't want them lit. What backpack is it?

I2C address will be from the datasheet for the expander chip on the backpack. And may be fixed or selectable on the backpack board with jumpers.

Looking at the NRF905 datasheet, there are a half dozen more pins that need to be wired to the PIC. A couple may simply need pullups if you want the NRF905 to be always powered up. Ensure that both the PIC and NRF905 are running on 3V. NRF905 needs 3V. You will need a level shifter on all lines betw...

Hi John, As has per the other explanations here, you should relabel your image with both PICs as Masters and both NRF905s as slaves, then it should make more sense. You have no slave PICs. Think of it as working with just 1 PIC and 1 NRF905. The only difference is each PIC is sending different confi...

I built a PCB that utilizes PWM channel 1, but found that channel 1 did not work for the FC PWM component. The PWM CAL file configures channel 1 for enhanced mode, but this would not work without adding supplementary code to complete the configuration. Channel 2 is not affected as only channel 1 off...

The programs work fine if I use code blocks for the EEPROM write/reads rather than the FC EEPROM component. New test program attached. So I reviewed the CAL and FCD files again. It appears that the incorrect eeprom type is specified in the FCD. It should be type 3 not type 2. Seems to be working wit...

This test program randomly worked a few times, but mostly will not. When it doesn't, nothing appears to be written to EEPROM. Code read in and read out are identical on compare.

The other small test program.

I think the changes I made just before the problem started was adding a circular buffer and a macro that reads those 5 top row addresses and sends the values out the UART. That macro is currently deleted.

The simple test flowcharts attached seem to work, mostly. But then I am only writing/reading to 1 or 2 addresses and have only 3-4 variables. My program should write to 28 EEPROM addresses during calibration, including a final write to address dec 52 of the dec value "126". I can see values written ...

What might cause nothing to be written to the EEPROM? The program does not stall at any of the read or writes, but there is no data stored? I can get it to work with a bare bones EEPROM only test program, and it was working fine in my program up until yesterday. I have disabled any new code and most...

Yes SPI 3/4 wire.....MOSI/MISO, CLK and CS/SS.

No wireless. The datasheet link was for my own(and others') reference. I have been using LCDs from China, with or without the I2C adapters. FC has a prebuilt I2C LCD component that works nicely with the 1602 I2C adapters. Free shipping(be prepared to wait 1 month). No taxes or duties if the total va...

No I have not had a chance to play with it yet. Have used SPI though. Just wanted to clarify what the SPI device was and find the datasheet: http://www.nordicsemi.com/eng/content/download/2452/29528/file/Product_Specification_nRF905_v1.5.pdf Haven't looked closely at your FC or the datasheet yet but...

I think I have this resolved...again. It appears that the receiving MCU was attempting to intialize/connect to USB while the other MCU had control of the switched lines. USB would not usually be connected while receiving new CalData, so that explains why there was never an issue receiving that. Too ...

Hi John,

Should your first disabled SPI macro be "Initialize" rather than "Uninitialize"? What SPI device are you sending data to?

Grant in Winnipeg

Hello, What happens if you change the timeout parameter for the WaitForValue component macro from 0 to say 100. This should wait 100ms for the response before timing out but should avoid any blocking type lock ups. This skips the "Wait_for_Ready" and allows the data to be sent, preventing a waitfor...

I think I tried that yesterday, but will give it another try to be sure.

Not familiar with USB. Is it normal that I should see activity on the USB lines when not sending or receiving? It appears that there is a packet every 10usec (packets sent at at 100kHz).

I guess I spoke to soon. The first time I tried the modified test program, it seemed to work, but I cannot get it to work again. Looking at a scope I do not even see the RS232 Send String macro transmitting anything. (this is just before the Wait_for_Ready macro). On many tries, only once did I obse...

Thanks Benj. That is basically what I am doing. Just thought I would give it a try with sending as a single string. It is possible that the values of some of the bytes are 0, as they are derived from 10 bit values that are split into high and low bytes. So a variable with a current value under 256 w...

Not sure if I am doing this correctly. I created a variable such as "data_string[14]" to send 14 bytes of data via UART to another MCU using a circular buffer to receive the data. The data is organized as: data_string[0] = byte1 data_string[1] = byte2 . . . data_string[13] = byte14 If I send the str...

Thanks Benj, that seemed to do the trick. I am actually using the circular buffer approach on the other MCU, which leads to the next question I will post.

Hi Benj,

Here is a pared down version of the program that acts as the bridge. I can transmit data back and forth on the UART fine until the USB is active. It seems to hang once it gets to the RS232 macros at the end of the Update_Current_Limit macro.

I would like to use both the USB serial (PC<>MCU) and UART(MCU<>MCU) but it appears that once the USB is initialized/connected, a RS232 send or receive macro call causes a MCU lockup. Should I be able to use both?

Thanks,
Grant