Author Topic: mcModules goes touch  (Read 990 times)

Nick_W

  • Full Member
  • ***
  • Posts: 214
    • View Profile
Re: mcModules goes touch
« Reply #15 on: September 10, 2016, 02:43:10 pm »
Ok,

SD card upload worked.

The mcThings script is very helpful, the Nextion class will be very useful.

Haven't got it working yet, but my UART wires are connected to pin 1 and 2, not 1 and 3 like you have. I may have some rewiring to do.

Thanks for all the help. I'll let you know when I have some results.

kristofferis

  • Sr. Member
  • ****
  • Posts: 287
  • Location: Sweden
    • View Profile
Re: mcModules goes touch
« Reply #16 on: September 10, 2016, 02:45:07 pm »
You could use any pin you like so no need for you to change, just update the code with your pin.

Nick_W

  • Full Member
  • ***
  • Posts: 214
    • View Profile
Re: mcModules goes touch
« Reply #17 on: September 10, 2016, 02:47:30 pm »
Huh, I'm wired to pins 9 and 10, not 1 and 2. I should be able to reconfigure without rewiring.

I'll give this another go tomorrow (daughters birthday - have to pack in for now).

Nick_W

  • Full Member
  • ***
  • Posts: 214
    • View Profile
Re: mcModules goes touch
« Reply #18 on: September 11, 2016, 03:28:13 pm »
Update.

After a lot of messing around (isn't it always the way) I finally determined that my "known working" FTDI cable is in fact not transmitting correctly.

I did manage to figure out the Nextion Editor. It's actually a simple concept presented in the most confusing way possible (and with "chinenglish" instructions). So I made myself a button that just transmits a "hello" message, and I can see it on a serial monitor! But sending data the other way - nothing...

So, find my backup FTDI connector, and spend a few hours sorting out Windows driver conflicts, and now it works!

I can actually upload from the editor, debug with the display connected, and upload via a python script.

Now back to the mcThings module.

More problems. It seems the "you can define any pin as anything" theory is not quite so much. Only pins 0 to 8 are defined as pins, the other pins are "allocated" to specific other things. The pins I wired (not sure why I wired it this way) 9 and 10 are allocated to the Green and Red LED. So I have to allocate the UART to RedLed and GreenLed - you can't rename them, or allocate them as inputs/outputs, despite what the documentation says.

It is all a bit baffling, and doesn't work. I may have to rewire, as I suspect the LEDs are defined as outputs, and I can't change them.

So progress in that the display is tested and working (and I understand the editor a bit better now).

Stuck in that the pin allocations on the module are confusing.

Will break out the soldering iron tomorrow. I have scored some rare-as-hens-teeth 0.05" headers, plus a difficult-to-find 0.05" to 0.1" adapter board, so I was going to wire one of these anyway.

kristofferis

  • Sr. Member
  • ****
  • Posts: 287
  • Location: Sweden
    • View Profile
Re: mcModules goes touch
« Reply #19 on: September 12, 2016, 07:00:59 am »
Sounds good that you got it to work.

About the pins, when i check the documentation for the mcmodule then it says that Pin 0 - 8 are  General Purpose Input/Output Pins so the documentation seems right?

Nick_W

  • Full Member
  • ***
  • Posts: 214
    • View Profile
Re: mcModules goes touch
« Reply #20 on: September 12, 2016, 07:27:31 am »
I guess it depends where you read the documentation. P70 has a table that shows pins 9 and 10 as I/O pins.

Nick_W

  • Full Member
  • ***
  • Posts: 214
    • View Profile
Re: mcModules goes touch
« Reply #21 on: September 12, 2016, 07:59:29 am »
Ok I have confused myself again.

I was basing the theory that pins 9 and 10 are the LED's, as the IDE shows the pin object as having pin 9 and 10 connected to the LED. The documentation (mcScript) has a table showing pin 9 and 10 as general I/O and p114 has the pin object defined as this:
Quote
Const Pin0 As Pin = 0
Const Pin1 As Pin = 1
Const Pin2 As Pin = 2
Const Pin3 As Pin = 3
Const Pin4 As Pin = 4
Const Pin5 As Pin = 5
Const Pin6 As Pin = 6
Const Pin7 As Pin = 7
Const Pin8 As Pin = 8
Const Pin9 As Pin = 9
Const Pin10 As Pin = 10
Const LedRed As Pin = 11
Const LedGreen As Pin = 12
Const Button As Pin = 13
Const ReedSwitch As Pin = 14

Which does not match what the IDE says (pin9 and pin10 are not valid pin constants).

Looking at the "product specification", It gives yet another scenario, where the physical pins do not correspond to the software pins. P9 has this table:

Quote
Pin Name Type Function
1 PIN6_D6 I/O General Purpose I/O 6
2 PIN5_D5 I/O General Purpose I/O 5
3 PIN4_D4 I/O General Purpose I/O 4
4 GND G Ground
5 PIN3_D3_A3 I/O General Purpose I/O 3 (Analog Input)
6 PIN2_D2_A2 I/O General Purpose I/O 2 (Analog Input)
7 PIN1_D1_A1 I/O General Purpose I/O 1 (Analog Input)
8 PIN0_D0_A0 I/O General Purpose I/O 0 (Analog Input)
9 PIN7_D7_A7 I/O General Purpose I/O 7 (Analog Input through OpAmp)
10 PIN8_D8_A8 I/O General Purpose I/O 8 (Analog Input through OpAmp)

So pins 9 and 10 are actually pins 7 and 8. How hard would it be to have the physical pins match the pin names? especially as you get to define the pin names???

The table from P70 of the mcScript documentation says:
Quote
The PinName is Pin0 to PinN where N is the number of pins minus 1. The Alias is optional and can be used to give the pin a more descriptive name. The PinMode describes what the pin does. Not all pins support all PinModes. See the following table for the mcMod110:

And lists pin 9 and 10 as not having analog input, just general digital I/O. But as pin 4 is ground, the above description cannot be true (unless "number of pins" does not mean "physical pin number"). So I have no idea what all this means.

I'll just have to experiment and see what documentation turns out to be right (maybe they are all wrong...).