Glad you see it too Frank. I just rebooted my machine so it is as clean as it can get.
Based on my fight to get T4 to run from Compile.cmd the way it worked for other ARM Teensy - it seems perhaps something is making the build process run oddly? I was getting ENV vars not expanded properly. The boards.txt isn't specifying the F_CPU Speed from .menu section - is anything else different in the T4 Boards.txt section?
I don't know... the details of the build-process are still a mystery to me.
Did you see my solution for PROGMEM? It would be great if someone could try that. It works great for me so far but, you know, problems are usually found by others...
Good night.
@KurtE
Ok. Incorporated your changes but..... it does call the SendL2CapCommand but I can't just call setRumble. JoystickType is identified as a gamepad not a ps4 so that never gets called so I just created a setRumblePS4 which calls the send command (1) no rumble and (2) hangs after a couple of calls:
Code:LX: 132, LY: 126, RX: 128, RY: 126 L-Trig: 173, R-Trig: 0, Trig-Button: 4 Buttons: 8, PS: 0 Joystick update Rumble/LEDsSending L2CAP COMMAND! LX: 132, LY: 126, RX: 128, RY: 126 L-Trig: 174, R-Trig: 0, Trig-Button: 4 Buttons: 8, PS: 0 Joystick update Rumble/LEDsSending L2CAP COMMAND!
@mjs513 - always fun debuggingHopefully late this week will have new shiny (RED) PS4 controller to try it out...
Note: I do look at different places for information, like the usb host 2 code as well as Linux drivers, like: Source: https://github.com/chrippa/ds4drv
And it looks like the format of data is different for the feedback between the USB and BT interfaces...
Also may end up needing to setup virtual call back functions like I had to do for HID (in particular RawHid), to process any responses...
This is the fun part because I can understand a little of what I am doing. I just tried the rumble config from UHS2 but nothing with that config and was just beginning to look at the repository you linked to - guess we are working on the same pageOriginally Posted by KurtE
@mjs513 - always fun debugging
Note: I do look at different places for information, like the usb host 2 code as well as Linux drivers, like: Source: https://github.com/chrippa/ds4drv
And it looks like the format of data is different for the feedback between the USB and BT interfaces...
Also may end up needing to setup virtual call back functions like I had to do for HID (in particular RawHid), to process any responses...
EDIT: The rumble packets are the same as from the link per the reference. One thing that I noticed is that the report id appears to be different based on whether it is usb or Bluetooth. Interesting.
EDIT2: Ok I tried to implement the rumble/led packet per our references and if I use 0x11 for the report id it hangs, if I use 0x05 (USB) it doesn't hang the sketch but no rumble. I will post my changes on wip in case you want to play. Now its movie time with the wife
Last edited by mjs513; 02-10-2019 at 11:57 PM.
Somehow skipped the PROGMEM_COUNTER post.I don't know... the details of the build-process are still a mystery to me.
Did you see my solution for PROGMEM? It would be great if someone could try that. It works great for me so far but, you know, problems are usually found by others...
Good night.
Question: Wouldn't the _counter_ reset across compile modules? Suppose that would resolve out okay in the linker getting this from 3 files?:: ".progmem_0", ".progmem_0", ".progmem_1", ".progmem_0"
Indeed the builds.txt feeding platform.txt is a bit mysterious when it seems to work and then doesn't.
My working T4 edits to use Compile.cmd were Post #1543 after #1539 and #1535
Paul may have edits coming to that to allow starting at a given speed or other changes that will normalize it after Beta 1?
I believe the counter would reset between each compilation unit. Which means in one object file, you would have duplicate sections. The linker would combine the contents in each of the sections into one large section. And as I said earlier, if you want the linker to delete unused functions or global data (like it normally does now), you might find these compound sections are not getting deleted if there is a reference to one of the functions in the lumped together section, but not to the other functions. It depends on whether that deletion is important to you.
I personally would use a macro that glues together a string with the .progmem. prefix, and just pass it a string or a name (using a STRINGIFY macro). That way you get unique sections, and the linker will combine all of the .progmem* sections together. Or just abandon a macro all together, and just use the __attribute__((...)).
Rather than abusing the AVR .progmem semantics, it might be better to have a TEENSY unique macro, that expands to nothing on non-Teensy platforms.
Interesting - Michael - is that different than everything just going into .progmem? I just saw you noted that in post #1612 - is that where the /LTO option breaks and removes on finer granularity?
As far as a TEENSY unique macro would that be something like post #1634 suggestion for code to FLASH of :: #define FLASHPROG __attribute__((section(".startup")))
Looking at Boards.txt [ and post #1656 ref to #1543] I did a diff of the T4 and T_3.6 section - then this top section stood out when I did the cut/paste:
I'm assuming that defines an order specific passed set of params somewhere. And the T4 not having the speed menu in any form - there was no value passed and that is why the Keyboard Layout was showing as a non-expanded/unpassed element?menu.usb=USB Type
menu.speed=CPU Speed
menu.opt=Optimize
menu.keys=Keyboard Layout
So adding in a rudimentary menu.speed is what made my edits work with Compile.cmd:
It seems in the end the build would want to pass in a speedteensy4b.menu.speed.600=600 MHz
teensy4b.menu.speed.600.build.fcpu=600000000
I tried something else and then the T4 build breaks when F_CPU is not defined.
Ok, in this case we just need to add a file-unique define.
Should be doable with a define --D on the command line. Edit: The filename without path for example.
Last edited by Frank B; 02-11-2019 at 05:32 AM.
Paul: Your shipped beta1 T4's had an assortment of caps for the crystals … have you determined the best values - or is there some test we could run on our Beta #'d boards that would tell you which is the best match for desired clock stability?
PROGMEM ?
I am getting sort of lost? I know I should probably re-read the last 10 or 20 pages in this thread, but what is it that we are trying to do defining PROGMEM to do something?
To me in the past using PROGMEM and F() implies goes into program space, that it was read only and that access to it, is probably slower. So putting PROGMEM on code made no sense as it will always be in the code section...
So if you needed it in a place to modify or maybe faster access, you ended up copying the data out of progmem into RAM...
Just wondering as there are lots of apps (for example example sketches that do this...) like ones from Adafruit_... libraries were setup for smaller memory and have PROGMEM for their logos, or bmps and most of the strings in prints have the F() setup in them...
So hoping we are not redefining things like this to go counter to expectations, that is maybe make things marked in this way go to faster memory?
Just wondering.
Filenames should'nt have spaces.. For windows, %RANDOM% would work, too. No 1000% sure, but the chance for double %randoms% is very very small - worst case something would not be deleted... .I don't know if %random% exists for other systems.
@KurtE.
Tried a couple a couple of other report formats for Bluetooth control of the rumble function. Think I have to read a little more carefully now, there is a difference - REFS:
root/drivers/hid/hid-sony.c
http://eleccelerator.com/wiki/index....le=DualShock_4 - probably the original source.
DCP update:
I've updated DCP post #1600 with tests of DCP-accelerated CRC32 and AES CBC.
PROGMEM means the variable or function is only placed in the external QSPI flash chip. F() and PSTR() are supposed to do this for string constants (or "string literals" in compiler jargon), but I'm not sure if we have those working yet.
FASTRUN is meant to be used only on functions, meaning the function is placed in fast ITCM. Today, we're all non-PROGMEM functions go into ITCM by default, but that may not always be the default in the future. So FASTRUN is good to use on interrupt handlers, even though right now it has no effect. In the future we may have an option to make functions default to PROGMEM, which trades a slight performance hit to gain more fast RAM for variables. It'll probably be needed when/if people write very large programs, for programs needing nearly 500K for variables.
DMAMEM is meant only for variables, and really only for variables without initialization. By default variables are placed into fast DTCM which is not optimized for sharing with DMA. Using DMAMEM puts the variable into OCRAM (on the AXI bus) which is slightly slower, but more optimal for sharing with the DMA controller and peripherals like USB which have their own DMA built in. Memory obtained by malloc() and C++ new is also from OCRAM.
No matter where anything is placed, it's always accessible with ordinary C/C++ semantics. Macros like pgm_read_byte() are never needed, but they are provided as do-nothing macros so legacy code for AVR still compiles and works.
PROGMEM and DMAMEM are cached, which makes them very fast if you're accessing anything within the same 32 byte range as a prior access that's still in the cache. If you care quite a lot about performance, best to align data to 32 bytes. Code uses a completely separate instruction cache, so there's no worry about simply running other code evicting your data from the data cache. But cache misses are quite slow.
Me too. I believe this use of PROGMEM is pretty close to what people expect from AVR.So hoping we are not redefining things like this to go counter to expectations
Then again, nobody else (as far as I know) had really tried to map M7's memory architecture onto the Arduino world's conventions. I believe some of Adafruit's SAMD51 boards (which are M4) may have the ability to put variables and maybe even code into a QSPI flash chip. Would be interesting to look at what they're doing, if anyone knows or has time to investigate. Maybe the STM32 folks have looked at this? I don't follow STM32 closely.
But my gut feeling is we're probably the first to really tackle how to use M7 with Arduino's conventions and legacy of AVR code.
As you mentioned looks like there may be differences. My DS4 won't be here until end of the week, so can not test anything yet. But also wondering with the experiments with:
void sendL2CapCommand(uint8_t* data, uint8_t nbytes, uint8_t channelLow = 0x01, uint8_t channelHigh = 0x00) {
If maybe the channel number may need to be not the defaults? May have to look through some of the BT documents for some of this stuff... Been awhile!
I can understand. I just connected up the DS4 as a wired device but now it doesn't work as a wired device. Just keep getting debug prints showing usuage. So we may have broken something. Give it a try when you get it. Will keep looking but have a few other things to do today.
I have an Adafruit M4 Express, and it has two sets of flash memory:
- The bootloader memory that contains the program to be executed. If you hit the reset button twice, it goes into the UF2 bootloader that presents this area as a small USB removable memory. You can copy the program to be run into the file CURRENT.UF2, and when the OS finishes copying the file, the board reboots. You can also copy other files into the memory. If you have circuitpython installed, and you don't have an express board, it will look for a file code.py to contain the source code to be executed. My M4 express has 512K of flash memory and 192K of SRAM memory.
- The second memory in the express boards is a QSPI flash memory that CircuitPython can use for the input file instead of the program memory. As I understand it, it is just SPI flash memory, it is not integrated into the normal program memory. It is formatted as a FAT file system, and there are Arduino libraries to access files on the file. On my M4 express, it has a 2MB flash memory chip. When I boot into circuitpython, and don't do the double press of the reset button, this flash memory is available as a USB drive, and I can copy files there.
Lets see, some links:
- https://www.youtube.com/watch?v=h6V7yjsmIxU
- https://learn.adafruit.com/adafruit-...loader-details
- https://makecode.com/blog/one-chip-to-flash-them-all
- https://www.adafruit.com/product/3857
- https://learn.adafruit.com/adafruit-...press-atsamd51
I have several of the Adafruit boards that have the UF2 bootloader (Playground Express M0, Hallowing M0, M4 Feather Express). Unfortunately, I do have a loathing for Python in general, so I haven't really done anything except run scripts other people wrote with it. I have done standard Arduino programming with the Hallowing and M4 express boards, but I'm still having teething problems getting the Circuit Playground Express to work with my normal Arduino programs.
I hooked up my USB Mini shield with UHS2.0. The channel ids used for rumble were 0x45 and 0x00. But when I tried that - no luck unless something overrode them.
The question might be, is the 0x45 a hard coded something or is it from some other message returned from the controller or the like...
Also not sure if you need to handle a response... Hopefully when I have one to play along we can map that out...
Not hardcoded pulled determined from L2CAP connection commands. Figured I would just give it a shot.
Didn't see anything associated with handling a response but a lot in the library.
Oh, if you want the avrpins.h file to get your usb host shield working I will post it on my WIP repository.
@Paul and all,
Looks like the folks developing STM32duino have incorporated the H7 board now, https://github.com/stm32duino/Arduin.../cores/arduino
They did implement a EEPROM emulation on the H7 if you are interested in poking around
@Paul ... - Arduino with M7. I know that the Robotis has at least one board now with M7, the OpenCR1.0 http://emanual.robotis.com/docs/en/p...ller/opencr10/
That uses an STM32F746ZGT6 / 32-bit ARM Cortex®-M7 with FPU (216MHz, 462DMIPS) https://www.st.com/content/ccc/resou...DM00124865.pdf
My guess they have not done anything special yet to get the memory to work in special ways. Unless STM had already done it for them as part of the HAL stuff... As I already updated their stuff to have some reasonable SPI and SerialX support... Before that if you did Serial1.print(...) it would hold up everything as each byte was output...
They have a few other new boards, which one of which may have an M7 as well but, I have not spent time on it yet... Been busy with T4
EDIT: Their newer system, that they are doing mostly for ROS2 is the XEL network of boards: http://xelnetwork.robotis.com/en/latest/ where the CommXEL has a STM32F746ZGT6
Last edited by KurtE; 02-11-2019 at 05:47 PM.
@Paul - @KurtE@Paul ... - Arduino with M7.
They have a few other new boards, which one of which may have an M7 as well but, I have not spent time on it yet... Been busy with T4
Yep there is a NUCLEO DEV BOARD STM32H743ZI that uses the M7. I was poking around a bit in their core and other files but like Kurt said, didn't see anything that they do to get the memory to work like everyone is doing with the T4. But still poking.
EDIT: The one I did notice was they set their core clock at 640MHZ not 600.
OK,
I have a trivial question:
I just got a breaoutboard for T4. (thank you at PJRC)
I note a new usb connector.
I see that the data lines are connected with pogo pins with the USB connector that we use to download programs.
I assume the new USB connector is for testing USB host.
How does it work?
Can I keep both usb cables connected, or must I disconnect the one I'm not using?
Posting Permissions
Reply With Quote
