Just Harmony

                                                                                                                                                                                        Designed by Freepik
 Well after a few weeks of work,   I may be there.  The software component lefty to implement is the script manager.  This is mostly software with a dependency on the Non-Voltaile Memory driver.  Since that is working with the config data, what remains is verifying it works on the larger memory needs of the script manager.

The last problem child was the Bluetooth and the RN487x interface.  First the UART driver did not work anything like the previous model.  As a result the Tx function is blocking, kind of, for now.  Not sure how important that is.  In the RN487x implementation, I wait around for the CMD prompt before executing the next instruction.  I could have the ISR process the flag the main loop when this happens, but this is only important on initialization.  For now I am just going to leave it as an inline process that runs to completion.

The Rx function works like before with an ISR that processed the Rx queue from Harmony.  I did have to use the Ring Buffer  implementation.  The normal implementation required that you submit a read request, instead of just using the call back when a byte came in.

There was another problem, but this had to do with Android software  I had thought I had solved this problem several years ago, but it came back.  It has to do with how many bytes are transmitted when writing a Bluetooth Characteristic.  Once transmit 8 (the maximum I set up), then in that session it will always transmit 8.  If you send 4 bytes, it will just stuff the other 4 bytes with the last 8 byte transmission.  You can read about this issue here.

Time to move on and finish this to the point I can start to assemble the new PCBs.  I have a place for at lest on of these 15 channel LED controllers.

 

Upgrading from RN4020 to RN4871

 

 I am in the process of upgrading the wireless interface for those people who want to install it.   I was hoping that moving from the RN4020 to the RN4871 would be simple and painless.  As is always the case now, it was not.

I use the ASCII interface over a standard serial UART.  While most of the commands are the same, there are changes.

1. They have included a delimiter on all GATT messages (%) plus a few others.  While it makes the parsing a little easier, it changed the way the parser worked.  
2. The RN4871 is very sensitive to power and the reset input (see this post).  When I designed Brick Controller 3, I used the PIC nMCLR input to reset the RN4871.  This in turn is driven by TC54 reset controller.  So that part is good, since it appears the RC type resets don't work.  I do have a spare GPIO now, so I could cut/jump that in if it becomes necessary.
3. There is a transparent UART mode, but I am not sure how much Android work that will entail, if it is even possible.
4. The most important change was the elimination of the real time read mode.  The mode would send a message across the UART that the phone was about to read the characteristic.  This would allows the PIC just enough time to update the characteristic value before the phone read it.  That is not implemented in the RN4871.  So I am looking at other ways to do this.

I mostly have the interface working.  It seems to be stable, though the code needs some work.  The 18F26Q71 running at 64MHz, is just too fast for a 115200 baud rate.  During initialization, I have to make sure that the RN4871 response has come in before moving on to another command.  While this implemented in essentially "wait for it to happen" code, this needs to move into the switch function of the BT_TASKS subroutine of the main loop.

 

 

 

 

How Not To Code

 

This is going to be a detailed technical post on MPLB X, XC8 PIC C compiler and how not to code a project.  Or to put it simply, how not to be stupid.

The above picture is a Curiosity HPC Development Board that I talked about in this post.  This was to help me get most of the code structure working for the Brick Buddy III as shown here.

The processor on the PCB is a PIC18F26Q71.  Fairly new, but with a very nice of features and lots of program FLASH and RAM.  But it was going to be weeks before I received one from assembly.  Thus the HPC was put into use.  Instead of putting a PIC18F26Q71 in the HPC (it does have a 28 pin socket underneath the 40 pin DIP), I chose to use the 40 pin version, a PIC18F46Q71.  The only difference between the two, besides the physical 28 pins vs 40 pins, is the PIC18F46Q71 has an extra PORT (PORT D).  

The Brick Buddy III code is a derivative of Brick Buddy II and Light Buddy II.  I have not started a project completely from scratch in a long time.  Using common libraries as I explained in this post means that only the main control loop and the hardware initialization is unique, unless there is a new peripheral of some kind.  Once I updated the initialization, I started compiling the code with the PIC18F26Q71 as the processor.  This PIC has the new I2C controller and thus there was a few days of just getting the code to compile.  During the compilation, there were multiple error messages having do with available PIC ports.  Brick Buddy II is a 44 pin device and thus has a PORT D.  All of this had to be changed to accommodate the PIC PORTS available on the PIC18F26Q71.

Once that was done I started trying to see if I could get some of the basic structure working.  This include the serial interface to the PC, the I2C EEPROM that stores configuration and scripts (which would also validate the I2C software driver for the LP5569 IC LED driver).  Finally working on the Bluetooth code for the RN4871.  This BT module is similar to the RN4020, but I am sure there will be some minor road bumps.

Once I had my standard LED heartbeat running, I moved on to the serial interface.  The PCB contains a FTDI USB to UART interface IC.  So I used one of my lab ones to connect the PC to the HPC Development Board with three jumper wires (Rx, Tx & GND).  And nothing worked.

Most PICs have a Peripheral Pin Select (PPS) module.  This allows you to move digital peripheral  features to different pins.  It is basically a large switch matrix.   Some PICs can move the peripherals to any pin while others will restrict a peripheral to a subset of the PORTS.  Thus there is code at initialization that has to be executed to move the peripheral output to the desired pin.  This is shown here

        #if defined(USE_PCB)
            INT2PPS = 0x01;         // assign INT1 to RA0
            INT0PPS = 0x08;         // assign INT0 to RB0
            U1RXPPS = 0x0B;         // assign Rx1 to RB3    --RN4871
            U2RXPPS = 0x0C;         // assign Rx2 to RB4    --Console
            I2C1SCLPPS = 0x13;      // assign SCL1 to RC3        
            I2C1SDAPPS = 0x14;      // assign SDA1 to RC4

            RC3PPS = 0x20;          // assign SCL1 to RC3
            RC4PPS = 0x21;          // assign SDA1 to RC4
            RB2PPS = 0x15;          // assign Tx1 to RB2    --RN4871
            RB5PPS = 0x18;          // assign Tx2 to RB5    --Console
            RC2PPS = 0x0D;          // assign CCP1 to RC2
            RC5PPS = 0x0E;          // assign CCP2 to RC5
            RC6PPS = 0x0F;          // assign PWM1 to RC6
            RC7PPS = 0x11;          // assign PWM2 to RC7
        #elif defined(USE_DEV_BRD)
            INT2PPS = 0x15;         // assign INT1 to RC5
            INT0PPS = 0x0C;         // assign INT0 to RB4
            U1RXPPS = 0x10;         // assign Rx1 to RC0    --RN4871     
            U2RXPPS = 0x0D;         // assign Rx2 to RB5    --Console
            //U2RXPPS = 0x19;         // assign Rx2 to RD1    --Console
            I2C1SCLPPS = 0x13;      // assign SCL1 to RC3        
            I2C1SDAPPS = 0x14;      // assign SDA1 to RC4

            RC3PPS = 0x20;          // assign SCL1 to RC3
            RC4PPS = 0x21;          // assign SDA1 to RC4
            RC1PPS = 0x15;          // assign Tx1 to RC1    --RN4871
            RD0PPS = 0x18;          // assign Tx2 to RD0    --Console
            RC2PPS = 0x0D;          // assign CCP1 to RC2
            RC5PPS = 0x0E;          // assign CCP2 to RC5
            RC6PPS = 0x0F;          // assign PWM1 to RC6
            RC7PPS = 0x11;          // assign PWM2 to RC7
            RD1PPS = 0x00;
        #endif

What this also shows is that I have a conditional compile. One version for the PCB and one for the HPC Development Board.  What I found was that UART2 Rx pin would not work on any of the PORT D pins, even though the data sheet clearly indicated that it good be moved to either PORT B or PORT D.  The UART2 Tx pin worked on any of the PORT D pins I placed it on.  I verified that there was a signal present using my Digilent Analog Discover 2 (which I highly recommend).  Thus I moved the UART2 Rx pin to PORT B and all was good.  I needed to make progress, so I moved on.  Though I did post in the Microchip Support Forum what had happened.

Well someone commented on the post.  When I read the comment, I immediately knew that person had the correct answer and I had fallen again for what I discussed a month ago in this post.  Embarrassment does not even begin to describe how I felt.

Here is the initialization code with the issue

    TRISA = 0xFF;
    TRISB = 0xFF;
    TRISC = 0xFF;
    LATA = 0;
    LATC = 0;
    ANSELA = 0x00;                //all digital
    ANSELB = 0x00;                //all digital
    ANSELC = 0x00;                //all digital
    ADCON0 = 0x00;                //A2D off
    ADCON1 = 0x00;                //+ref is Vdd and -ref is Vss
#if defined (USE_PCB)
    mLED_TRIS = OUTPUT_PIN;       // make it an output
#elif defined(USE_DEV_BRD)
    mLED_B_TRIS = OUTPUT_PIN;     // make it an output
    mLED_Y_TRIS = OUTPUT_PIN;     // make it an output
#endif
    

I had the foresight to place a conditional compile for the heartbeat LED (mLED_B & mLED_Y) to control the TRIS control for the pin.  But if you look directly above that, you will notice there is no mention of either TRISD or ANSELD.

Now TRISx controls whether the PORT pin is an input or an output.  The default is INPUT, but I always like to set them all to inputs and then let the code determine which pins are inputs and which are outputs. ANSELx controls whether the PORT is an analog input pin or a digital I/O pin.  The default is analog input pin, but again I choose to make all port pins digital I/O and then let the code set those pins that will have an analog input..  But this code fragment does not set PORT D to digital I/O and thus all the PORT D pins are analog inputs.

Now the quirk in these PICs is that a digital output (TRISx = 0) will override the analog input selection.  But a digital input will not override the analog input selection.  If you think about this, that only makes sense.  When you want an analog input ( e.g. ADC input) you will set the TRIS register to input and the ANSEL register to input.  The only setup for the processor to know that you want a digital input is the ANSEL register has to be set correctly.  So here is what the code fragment looks like now.

    // Make all digital inputs for now and let init routines set the tris bits that  need to be outputs.
    TRISA = 0xFF;
    TRISB = 0xFF;
    TRISC = 0xFF;
    LATA = 0;
    LATC = 0;
    ANSELA = 0x00;                //all digital
    ANSELB = 0x00;                //all digital
    ANSELC = 0x00;                //all digital
    ADCON0 = 0x00;                //A2D off
    ADCON1 = 0x00;                //+ref is Vdd and -ref is Vss
#if defined (USE_PCB)
    mLED_TRIS = OUTPUT_PIN;       // make it an output
#elif defined(USE_DEV_BRD)
    TRISD = 0xFF;
    LATD = 0x00;
    ANSELD = 0x00;                // all digital
    mLED_B_TRIS = OUTPUT_PIN;     // make it an output
    mLED_Y_TRIS = OUTPUT_PIN;     // make it an output
#endif
 

Live and learn, maybe😕

Brick Buddy 3 - A Start

 

This is a scaled down version of Brick Controller 2. This chart shows the major differences.

Why this?  Well I needed something smaller that I can put inside as many modules.  There are at least three module that only need two motor controllers.  This replaces the very small individual LED connectors with a 2mm socket, two of  them.  Thus you can use individual 2mm pins or one of the attachment boards I have.  (More on this later)

The other major difference is the processor.  This board uses the PIC 18F series instead of the PIC32.  While there is a USB connector, the PIC is connected via a standard serial (RS232 port).  Right now I have four processors that will fit this board.  All of them can be bought is some form (mostly differences in FLASH Program memory).  This is as opposed to the PIC32 in BC2, which is almost impossible to buy.

Finally the Bluetooth was changed to a 5.0 version.  The RN4020 was hard to find and was stuck at 4.0.  The RN4871 is also hard to find, but I have enough to at least prove out the design.

The design is done and I am in process to get the PCB made and some assembly done.  More as we progress.

Android 12 & Delphi 11.2

I finally got around to updating my three Android Apps for API 32/ Android 12.  So to start this blog post off, the following Apps are now available:

 

T-DUST  is a small module to monitor the  temperature in your Maker projects.  The app provides all the control  functions for a T-Dust device.  This includes displaying in Fahrenheit  or Centigrade, setting the data rate, recording to internal memory and placing the device in the power down collection mode.  The module has a 32Mbit memory on board for recording temperature data.  The app will  chart the temperature data on the mobile device or convert to a CSV file  for download. The module can record for over 120 hours at a 1 second  rate. 

 

The Power  Monitor is a small monitor module that plugs in between the USB Power Modules and your application.  The USB connection provides a constant  reading of the voltage and current on all of the voltages (12VDC, 5VDC  or VUSB, 3.3VDC, 2.5VDC and 1.8VDC).  The PC program provides all the  control functions and will keep a record of the voltage and current.   The module also has a 32Mbit memory on board for operating in the stand  alone mode.  Power comes from the Port 1 connection.  You can record up  to 65000 records, which is over 18 hours at a 1 second rate.  There is  an optional BT connection for controlling the monitor.  We provide the  API for both USB and BLE so that you can create your own custom  applications.

 

This is a dedicated brick controller for running your platform  designs. This  controller is dedicated to the task at hand.  Using a simple Android  mobile interface over Bluetooth, the sequence of up to 4 motor  controllers can be setup.  Additionally there are 4 LED lighting control  lines for dramatic lighting effects.  Finally it has three inputs for  sensing different types of real world events.  A Windows PC input setup  is in development and future versions will have an audio amplifier to  provide a single source for controlling your MOC.

Getting here did have some issues.  There were major changes to Android BT permissions.   You can see the changes here. Delphi will automatically generate the Manifest for you based on settings in the Project Options menu.  But this is very basic.  What is needed in some cases, especially Bluetooth implementation, are the qualifiers that go with the manifest entry.

Basically in Android 12 they introduced a SCAN, CONNECT, ADVERTISE permissions and eliminated BLUETOOTH and BT ADMIN.   Though what Google does not say is the ACCESS_FINE_LOCATION permission is not needed anymore, though it was never clear in the docs that it was needed prior to Android 13.  What you need for the basic private BT connection is

<uses-permission android:name="android.permission.BLUETOOTH" android:maxSdkVersion="30" />

<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" android:maxSdkVersion="30" />

<uses-permission android:name="android.permission.BLUETOOTH_SCAN"  android:usesPermissionFlags="neverForLocation" />

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" android:maxSdkVersion="30" />

 Unfortunately there is no way inside of Delphi to add these qualifiers, ie android:maxSdkVersion=30.  What I did was modify the AndroidManifest_Template to include these lines.  Then in the Project Options men, I made sure these options were deselected.  This way Delphi will not generate these permissions in the android manifest and all will work as expected.  You can find more information about this at the Delphi forums, here.  You may need a guest login to see the thread.

 
 
 

Light Buddy 2 - The Design

 

Here is what the board looks like.  It is very simple, just a fancy way to control 6 LEDs to produce fixed (kind of) lighting effects.  No remote of any kind.

The voltage regulator, U2, will take up 16VDC and produce either 3.3VDC or 5VDC, haven't decided what voltage to run at.  The intended input is VUSB, so if it is 5VDC, it will just follow the input.  J9 is the power input (GND-VUSB-GND to help prevent incorrect connections).

J8 is a standard TTL/CMOS level RS-232 interface.  My intent is to allow the 6 outputs to be programmed in some fashion, TBD.  The problem is anyone who does this will need a RS232 to USB converter.  For me, this not a big deal, for some LEGO users, this may be a bridge to far.   So when you order it, I would program with the desired effects.  The buyer would pick from a selection of choices.  I have also considered a BT module that plugs onto J8 and J9.  Then you would use the Light Buddy Android App to update it.

The remaining parts are six N-FETs to drive the LEDs and protect the processor outputs from excessive current draw.

On the backside, the two circles is where small 1 x 1 round LEGO plates will attach to the PCB (super glue).  This allows the board to be mounted into the LEGO Model.

The processor is either PIC16F18326, PIC16F18346, PIC18F06Q40 or PIC18F06Q41 families.  They come in different memory sizes, I always start with the largest until I figure out how much I really need.

Finally, the absolute bane of my existence, connectors.  All of these are of the 2mm type.  But as you can see they are large compared to the board.  I have used smaller 1mm 2 pin connectors before, but they are very difficult to un-mate.  Everyone complains about them.  Obviously J8 doesn't need to be populated unless you intend on using the RS232 interface.  J9 could be soldered in.  That just leaves J1 for the LEDs.  They also could be soldered in, but that would make working with the LEGO model more difficult.  You should be able to plug in individual 2 pin 2mm male connectors into J1 for each LED.  I keep looking for a solution to this problem, but have not found anything yet.

Light Buddy 1 - Operation

 

This video was taken with a standard HD Webcam (Logitech C922).  It does not do a very good job at closeups, which is why the device is slightly out of focus.  Additionally the LEDs, when on, tend to overwhelm the auto white balance.  One of these days I will get a better camera for this type of work.

This is a short video the Light Buddy 1 in demo mode.  Attached are the LEDs we sell in 1 x 1 and 1 x 2 plate format.  All of the LEDs have an integrated resistor.  Here is what is happening"

1.  The white LED in the upper left is on STEADY.

2.  The small blue LED left side center is in one of the pulsing modes.

3.  The purple LED in the lower right is in CyCLE mode then pulsing mode.

4.  The small blue LED on the lower left side is in CYCLE mode

5.  The green LED in the upper left is in STEADY then BURST mode.

Sometime later I will put together a series of videos that show the different LED modes that are possible.

 

Light Buddy - The PCB

 

Got my latest PCBs on Tuesday.  I knew before they arrived I had a problem.  I assumed (should be a four letter word) that PPS would allow any function on any PPS pin.  Well PIC18 may come close to that, but PIC32 does it in blocks.  So now I have 10 boards that are really not very useful.  Fortunately the USB and the console port could be used.  This one is very similar to the Brick Controller I cant build for lack of parts.  The Motor interface is missing and the BT (RN4871) is superset of the BT (RN4020) module on that Brick Controller.  The PIC32 is from the same PIC32MX family, just in QFP44 instead of a QFP64.  So this one is a high end LED controller with 15 LED channels.  I had previously mentioned this. 

I started pushing code into it, using the previous BrickController and MPLAB X Harmony Project I started.  Just in case the startup code for this PIC32 was unique.  Amazingly the USB HID came up right away.  I could not move data back and forth, but the PC recognized that a HID device was connected.  On the next day I was moving data and my Win10 App was talking to the device.  There were some USB connection issues.  They may have existed before I just never noticed them, but I decided to make this rock solid.  The PIC32 USB/HID implementation is more flexible than the PIC18 and this is OTG, which I am not using.  There are 3 state machines at the App level, two of them are callbacks from the USB/HID driver implementation.  The third is the real App level state machine.  It took a few days to get this working.  It was a simple matter of getting all three state machines in sync with each other and realizing that the two callbacks were actually running as the result of ISRs and those totally asynchronous to the App it self.

Once the USB/HID was working, merging in the other code for the other peripherals is easy.  Will need some conditional compiles, I dont like maintaining multiple code bases if I dont have to.

More later.

Android Updates

Well once upon a time, it was very easy to develop, test and push into the PlayStore.  I guess Google became jealous of Apple and its layers of requirements.  At som epoint I do understand that they need to have standards, but these updates every year are time consuming for the single person developer.   I spent the last 3 days trying to move one app (TDust) into the play store.  Now part of it is truly my fault for not keeping the apps up to date.  So trying to move from API 24( #7) to the new required API 30 (#11) and 64 bit versions has been fun. I can test on Adroid 7,8,11 and 12 with the devices I have.  I actually went to Best Buy and bought an unlocked phone.  It was $165 if you activate it and $165 if you dont.  Naturally I did not activate.  It is more a less a mini tablet.

I had already done the Permission thing before, but Google keeps changing the permissions required.  When permissions were implemented, to use BLE you need to have location permissions. I suppose it is because there is small possibility that the location of the phone can be determined.  But this changed as the APIs advanced.  First it was coarse location then fine and now coming in API 31 (#12) no location as long as you swear on someone's grave you wont use BLE to find the phone's location.  Actually they are completely revamping the permissions around BLE it looks like.

I am only complying with API 30 and the new App bundle requirement for now.  This is good for new apps until Aug 2022 and Updates until Nov 2022, at which point it is API 31/32.  With the price of gas, I assumed I would not be making many trips this summer, but that did not happen as we were gone much more than planned.  

When I went all the way to API 30, it all failed big time.  The program crashed, the debugger failed, it was a mess.  So I went back two revisions on the Embarcadero Delphi compiler, API 24 and the last set of code that worked from SVN.  That worked on all the devices, though Android complained a lot when installing on the newer devices. So I slowly marched up the API list.  One thing I did was create a separate code module to handle the permissions.  That way once I figured it out, it would hopefully work for all my programs.  When I got to API 29 (#10) I had to switch the compiler version, since the older version did not support API 29(#10).  This is where permissions started changing and I had to research what was happening.  After two days I finally got it all working on API 29.  I am now one step away.  At this point I had to move to the latest version of the compiler.  This caused quite a few library types to change, but I was smart enough to implement conditional compilation so that I could go back and forth on the compiler versions.  This proved useful as API 30 did not come easily.  But after a day of searching and changing, the app finally worked on all the devices with API 30 as the target.

Then uploading to the Play Store became another fun thing.  You cant upload APKs any more they have to be in the new App Bundle format. And now signing/encrypting the App is not good enough, the upload has to have a key also.  They can be the same, but they recommend against it.  Well I converted my existing key to the format they wanted but could not figure out how to generate a separate upload key.  So for now they are the same.  Supposedly I can change the upload key, I just cant change the App key.  I uploaded the app and then the Play Store went nuts about a permission, background location.  I had read the it was now required, but they wanted to know why I was using and to provide a 30 sec video showing how it was used.  Then a week or so they would get back to me.  So I deleted the upload, went back removed the permission and tested again.  It all seemed to work.  Upload this new version, no complaints and it was published.

But it cant end here.  I then tested the install on the devices. The older devices were still installing the older version, don't know why.  Something I have to look into.  But the 64 bit version just crashed on start.  So back to the devices.  The compiler keeps separate configs for debug and release.  I had failed to test the 64 bit release version.  Found a setting in the 64 bit release config that was wrong.  Once that was fixed, the 64 bit devices started working.

I still need to find out why the new 32bit version is not installing.  You would thing this is not a big deal, but............  The Samsung A13 I bought at Best Buy is an ARM8 64 bit, but they installed the 32 bit version of Android.  So even if Google is screaming 64bit to everyone, some of the big guys are still installing 32 bit OS, even on 64 bit ARMs. 

Next is the API 31/32 update due in Feb 2023 now.

Android Fun

Well once upon a time, it was very easy to develop, test and push into the PlayStore.  I guess Google became jealous of Apple and its layers of requirements.  I spent the last 3 days trying to move one app (TDust) into the play store.  I freely admit that part of it is truly my fault for not keeping the apps up to date.  So trying to move from API 24( Android 7) to the current required API 30 (Android 11) and 64 bit versions has been fun. I can test on Adroid 7, 8, 11 and 12 with the devices I have.  I actually went to Best Buy and bought an unlocked phone, Samsung Galaxy A13.  It was $165 if you activate it and $165 if you dont.  Naturally I did not activate.  It is more a less a mini tablet at this point.

I had already done the Permission thing before, but Google keeps changing the permissions required.  When permissions were implemented, to use BLE you need to have location permissions. I suppose it is because there is small possibility that the location of the phone can be determined.  But this changed as the APIs advanced.  First it was coarse location then fine and now coming in API 31 (Android 12) no location as long as you swear on someone's grave you wont use BLE to find the phone's location😎.  Actually they are completely revamping the permissions around BLE with specific BLE permissions, which makes more sense.

I am only complying with API 30 and the new App bundle requirement for now.  This is good for new apps until Aug 2022 and Updates until Nov 2022, at which point it is API 31/32.  With the price of gas, won't be making many trips this summer, so I will have some time on my hands to work on API 31 and 32.

When I went all the way to API 30 and using the very latest Delphi version, 11.1, it all failed big time.  The program crashed, the debugger failed, it was a mess.  I am using the Delphi compiler.  As I have said before, been using this for 30+ years, old dog not going to change now.   So I went back several revisions on the compiler, to version 10.3.3 , used API 24 as the target SDK and the last set of code that worked from my SVN repository.  That worked on all the devices, though the newer Androids complained a lot when installing on the newer devices. 

So I slowly marched up the API list.  One thing I did was create a separate code module to handle the permissions.  That way once I figured it out, it would hopefully work for all my Android Apps.  When I got to API 29 (#10) I had to switch the compiler version to 10.4.2.  This is where permissions started changing and I had to research what was happening.  After two days I finally got it all working on API 29.  I am now one step away.  

At this point I had to change version of the compiler to 11.0.  This caused quite a few library types to change, but I was smart enough to implement conditional compilation so that I could go back and forth between 11 and 10.4.2.  This proved useful as API 30 did not come easily.  When I first tried the 11.1 version of Delphi, it would crash on start.  The debugger finally showed that the issue is in one of the units startup code, but I never tracked it down.  I did see in Embarcadero's Developer JIRA a bug report RSP-35804 and RSP-35919.  ( I realize not everyone has access to this, so I will try and describe it.) The first one concerned using location permissions (FINE and COARSE).  The later concerned BLE Discovery which also uses location permissions (FINE or COARSE depending on Android version.  Because the second on was essentially the same as the first one, most info is in the first one.  Embarcadero said it was fixed in 11.1, but people were still reporting the issue.  Basically there was some error in the JNI implementation of location gathering.

But for me, none of this showed up this time in version 11 or version 11.1.  I dont know what happened from the very first time I tried 11.1 and at the end of my slow march through the API levels.  I had other issues with compiler configurations, choosing the correct permissions (COARSE vs FINE) but it never crashed like it did the first time.  All I can say is that the app finally worked on all the devices with API 30 as the target.

Then uploading to the Play Store became another fun thing.  You cant upload APKs any more they have to be in the new App Bundle format. And now signing/encrypting the App is not good enough, the upload has to have a key also.  They can be the same, but they recommend against it.  Well I converted my existing key to the format they wanted but could not figure out how to generate a separate upload key.  So for now they are the same.  Supposedly I can change the upload key, I just cant change the App key.  I uploaded the app and then the Play Store went nuts about a permission, LOCATION_BACKGROUND.  I had read an item in Stack Overflow that it was now required, but Google wanted to know why I was using it and to provide a 30 sec video showing how it was used.  Then a week or so they would get back to me.  So I deleted the upload, went back removed the permission and tested again.  It all seemed to work.  Upload this new version, no complaints and it was published.   So either the StackOverflow and the approved response misinterpreted the Android spec or Android in not following the spec. 

But it cant end here.  I then tested the install on the devices. The older devices were still installing the older version, dont know why.  Something I have to look into.  But the 64 bit version just crashed on start.  So back to the devices.  The compiler keeps separate configs for debug and release.  I had failed to test the 64 bit release version.  Found a setting in the 64 bit release config that was wrong.  Once that was fixed, the 64 bit devices started working.

I still need to find out why the new 32bit version is not installing.  You would thing this is not a big deal, but............  The Samsung A13 I bought at Best Buy is an ARM8 64 bit, but they installed the 32 bit version of Android.  So even if Google is screaming 64bit to everyone, some of the big guys are still installing 32 bit OS, even on 64 bit ARMs.

Old Idea Redone

Well since parts are impossible to get, i moved on.  Got a quote from one of the robber barons for an LED controller with an MRSP at Digikey of $1.65 in qty 1.  They wanted $55 each for an MOQ of 25.

Below is the result.  I started this on Tuesday and just sent it to FAB.  Not sure I can get everything for it right now, but it will be good enough for demo purposes.  There was no way I was going to build any of my new Brick Controller.  So I switched to an LED controller.  This is a subset of what the Brick Controller was, just no motor control.  This made power much easier since I did not need to make 9VDC.  The LEDs are powered from VUSB, ie directly from the USB bus.  The PCB is 48x64mm and is designed to fit exactly on a 6x8 LEGO plate.

The differences from complete design freedom are:

1.  Had to put in a new BT module(RN4870 vs RN4020), the one I have been using is not available for years if ever.  MIcrochip does not appear to be upgrading it for BT 5.x spec from 4.2.  The BT SIG has deprecated 4.2 already and wont certify any 4.2 after 1/1/2023, according to the Microchip website when you look at the RN4020 module.  The RN4870 module is BT 5.1 but the smaller version cant be found, so I am using the larger version.  I have about 15 of these I bought months ago as a hedge.  They claim firmware compatibility, we shall see.

2.  The processor is a PIC32MX270F256 and of the same family as the new Brick Controller (PIC32MX470F512) and I am hoping the firmware changes will be minimal.  There seems to be lots of these floating around.  Hopefully tomorrow they will still be there.

3.  If you look carefully you will see a small square IC (U1).  That is the LED controller(LP55231).  This a previous version, but is firmware compatible with the one I used on the new Brick Controller (LP5569).  I bought 20 of these months ago from one of the robber barons.  For whatever reason they were only 3x in cost.  The biggest issue for me is that the LP55231 is a source to the LEDs while the LP5569 is a sink.  While this might not seem like a big deal, it actually has large implications in the wiring of a MOC.  At least I try to minimize the number of wires running through a MOC.  Using 36-42 gauge wire, you want to minimize the number of wires that can break.  So in my case, I minimize the number of source wires since this is the common wire.   All my previous designs used an N-FET to sink drive the LEDs, that way I can parallel up multiple LEDs and not worry too much about the current load.  So I added N-FETs to the output of this older controller to make LED connections sink driven.  I give up the current control the LP55231 provides, but I use PWM to control intensity anyway.  With the VUSB supplying the drive voltage, a 120 to 150 ohm resistor provides the necessary current to brightly light the LED.  When the the new LED controller becomes available, those N-FETs and one resistor per channel will go away.

4.  I added 5 more LED channels using the 5 PWM controllers in the PIC32.  These would normally control the motors, but they work nicely with LEDs also.  So this gives me 15 LED channels, which sounds like a lot, but I can get very carried away with lighting effects.

5.  I added 4 inputs, 3 digital and one analog.  Though the analog can be make into a digital.  The 3 pin connector has 3.3VDC, ground and input to either a Schmidt Trigger or a unity gain OP-AMP.  This shroud provide all the input I can use.

The PCBs should arrive in about 7 days ( if Shenzhen doesnt shutdown).  That will give me two weeks to build, debug, test and then implement in one of my LEGO displays.  This should be fun.

More on the reason for the fast approaching deadline in a few days.