Author |
Message |
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Mon Jul 31, 2017 10:12 am Post subject:
|
|
|
Seems there are quite some mysteries in this stuff.
I'm noticing a warning from gcc claiming "Clock skew detected". Need to track that down. Also noticing that using HAL_Delay(1000), I'm getting much faster than on for 1 sec and off for 1 sec, so something is barfed with my clock config.
EDIT ADD:
The clock skew warning is just gcc telling me that my file times are funky. This happens because I'm using a file server and I think the clocks may be a bit out of sync. No big deal, that can be ignored.
However, the HAL_Delay() is a bit more than twice as fast as it should be and I'm not seeing why. The docs say that the HSI clock is used for SysTick and that's supposed to be 16 MHz, but the way HAL gets that information is a bit obfuscated, so that will take more work to find out why it's wrong. It may be that the project was started on a Nucleo - with different xtal clocks than the Discovery board, but I've not been able to find any settings or values that would indicate that yet. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24079 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Mon Jul 31, 2017 11:06 am Post subject:
|
|
|
elf files have symbolic info ... a (largish) pic 24 example :
Source size about 1.8 MB
elf size 1176 kB
hex size 637 kB
binary image size 117 kB (but that one has 48 kB stripped off .. as the hex has a boot loader / debugger / SD card driver & some small stuff in it - which is sort of easy for debugging)
You could probably strip the elf by not including debug info, but for the final image it would be stripped off anyway. The basic pin and register definitions probably take up a large bit of the elf.
Ok .. these numbers are off a bit .. as it would be about 60% of the ROM (192 kB) .. but for a general idea it will work .. hmm 117/192 is about 0.6 .. should look into that _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24079 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Mon Jul 31, 2017 11:12 am Post subject:
|
|
|
Ah .. its a 256 k device, not 192. _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Mon Jul 31, 2017 11:16 am Post subject:
|
|
|
I'm hoping that by source code trimming (I see a lot of stuff I'm not using) and editing the makefile for CPU optimizations will help with file/code size. I'm not so worried about file size if there's just header garbage, I'm concerned about the actual Flash RAM usage.
I had been reading about OpenOCD and that it can allow data to be passed from the dev board back to the host via the USB st-link connection. Not finding any good info on how that's done - I would assume that I must configure and use USART1 such that when I write data to USART1 it shows up in the openocd application on the host. Reading the openocd.pdf now, but it's rather scrambled... I'd really like to read out some of the clock value stuff and see what's actually being used because it isn't correct the way it is. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24079 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Mon Jul 31, 2017 11:27 am Post subject:
|
|
|
You could generate a map file to get an idea what resources are actually being used. _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Mon Jul 31, 2017 11:28 am Post subject:
|
|
|
I see that my main.bin file is only 5448 bytes, which is not as bad as I had thought. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Mon Jul 31, 2017 11:29 am Post subject:
|
|
|
Blue Hell wrote: | You could generate a map file to get an idea what resources are actually being used. |
Ah yes, and it's already there, created because of stuff in the makefile. Good to know about that, now I just have to figure out what it all means. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Mon Jul 31, 2017 4:16 pm Post subject:
|
|
|
My understanding (which may be flawed) is that USART1 is the way to talk via the st-link connection and a host over USB. It seems that USART1 is available only as an alternate function (AF7). There appear to be two TX and two RX pins each pair is in a different port, but I find that confusing. I find it useful to send data sometimes, about specific things happening in the program. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24079 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Mon Jul 31, 2017 4:49 pm Post subject:
|
|
|
re. the map, in the ones I've seen there often is a summary at the top, showing the rom and ram sections bundled - maybe that is because I request a detailed map file usually. This should be a linker command line option.
Then later on there will be details, like which function or variable caused how many bytes to be added to what section - there should be source file refs as well in a detailed map (and lots of sources are sort of 'hidden' trough IDE paths, some sources even are binary .. as in lib files being used).
Anyways, it being C the section names will be more or less standard enough for google to be helpful. _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Mon Jul 31, 2017 5:06 pm Post subject:
|
|
|
yeah, well, I'm sure that will all make sense when I actually understand what I'm doing
I think there's some example code that uses USART1 that is meant to talk over the st-link connection, so I'll have a look at that. (in STM32Cube_FW_F7_V1.7.0) _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Sat Aug 05, 2017 9:19 pm Post subject:
|
|
|
Argh... Been playing with the Virtual COM Port trying to send a simple message and it just won't work.
I started in Fedora 25 with a makefile project, and I could connect to the OpenOCD server with telnet, but I never got any messages from the board.
I then tried Eclipse (sw4stm32) and it did the same thing.
Then I installed sw4stm32 under Windows because I read that there's a problem running it under Windows.
I'm really confused about this because I don't have a simple ready-to-compile project using the Virtual COM Port that is known to work, so I can't even prove out my toolchain.
This has been just one pain in the rear after another.
I'm tired now, I'll get some sleep and hit it again tomorrow...
BTW, I'm not liking Eclipse any more than I did before. It's a huge cluster f*ck to learn, but I'm at a point where I can get things to compile without errors, but the stupid application just won't work - and I don't know if it's because USART1 is not sending anything or if st-util / gdb isn't working properly.
It's highly likely that there's a problem with my code, but I just can't see it (yet). I need this to work so I can start on getting MIDI data into the board. I would use the Virtual COM Port to echo back to the screen the hex data I'm sending to the MIDI port. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Sun Aug 06, 2017 7:48 am Post subject:
|
|
|
I had started this virtual COM port project by looking at one completed for a Nucleo F4 board. I found that the whole Eclipse project is in a git repository, so I've downloaded that. I've made a copy of the project and I will attempt to modify it to conform to the stm32f746g Discovery board. I've had trouble with non-working projects from git repositories before, so I've really no idea if this works on the intended Nucleo board or not, but I shall put my head down and charge in the hope that it does.
The project is supposed to send a simple message via the VCP and then stop (hits an infinite while(1) loop).
In my view, the virtual COM port will be an excellent debugging tool when I need to get numbers or other data out of it. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Sun Aug 06, 2017 11:15 am Post subject:
|
|
|
No luck with Eclipse. In fact, I'm sure that I'm doing something(s) wrong, but I've no idea what they are.
I downloaded (git clone) a nucleo f4 project and have tried to compile it (unmodified project), but it fails with *** No rule to make target. This is a makefile problem (I think), but the makefile has a note at the top indicating it is a generated file and not to edit it (it's a horrible mess of a makefile too, so rather impossible to edit intelligently anyway).
Under Windows 7, I also installed SW4SMT32 and the toolchain. For whatever reason, the installer doesn't added proper PATH information, so it dies saying the PATH statement doesn't reference the directory where make.exe lives. I can correct this, and then it dies with *** No rule to make target.
My inexperience with Eclipse keeps me in a fog here, I google and google, but there appears to be no solutions for me - as I said, I'm sure I'm doing things wrong somewhere, but I've no idea what or where.
I really wanted to try this under Windows 7, but getting nowhere. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Sun Aug 06, 2017 2:46 pm Post subject:
|
|
|
AH! IT WORKS! FINALLY!
While I could not get it to work via the GDB server to a telnet session (as described several places on the internets), I found by accident a few things. It is possible that I misunderstood what I read, another friend told me it doesn't work like that and that I should be doing pretty much what I'm doing (except that I should have to run st-util and then kill it).
First, on the Fedora session, I could see a device as /dev/stlinkv2_console which appears when the stlink USB cable is plugged in.
I tried cat /dev/stlinkv2_console and out come the messages I am sending.
BUT it won't work until I first execute st-util and then control-C it.
So the sequence is:
1) power up the board
2) run st-util
3) control C st-util to stop it
4) cat /dev/stlinkv2_console
Apparently, st-util does something necessary because while the device is there, the cat does nothing unless I run st-util and then control-C it.
I am doing this with a simple structure makefile project.
EDIT ADD: I believe this may be due to the fact that I have Fedora 25 running in a VirtualBox VM under Win7. USB requires a "filter" which can select a specific USB device to present to the guest OS. When it does so, it "steals" it from the host system, but there may be something not quite right about the virtualization. I have a working pentium 4 HT machine that I've installed Fedora 25 on and once I have it fully set up, I'll try this on that system to see if it works without the st-util ritual. At least I can make it work in the VM, but this was quite frustrating to find - by accident... _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Tue Aug 08, 2017 5:41 pm Post subject:
|
|
|
This has been an interesting day...
I finished the install of Fedora 25 on my standalone Pent 4 HT system. stlink is intalled there, but I cannot get the VCP to work on it. I connect the Discovery board to it, I can compile the project successfully, and Flash it. The application runs (blinks the LEDs as it should), but no matter what I've done, I cannot get the VCP to work. I can see it as /dev/stlinkv2_console (which links to the real console). Even if I run st-util as I do with the virtual box VM version of Fedora 25, it just prints nothing. I also tried this with a Raspberry Pi3 (Raspbian) and it does the same thing. This is not a horribly big deal, it works on the VM, but I've had problems with just stopping randomly. I thought it was some goofiness with virtualizing a virtualized device. Apparently there is something else wrong. Odd that so far, I've been able to make it work only on the VirtualBox VM.
I'm not going to sweat this because it does work, and probably well enough to actually use it. I just would like it to not stop randomly. I thought that a standalone linux would be better, but maybe it's the distro? dunno... _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
BobTheDog
Joined: Feb 28, 2005 Posts: 4044 Location: England
Audio files: 32
G2 patch files: 15
|
Posted: Thu Aug 10, 2017 4:33 am Post subject:
|
|
|
Looks like you are still having fun!
I'm not an expert on this but just cating the device file will not usually work, you have to set it up already.
Have you tried the setserial command on the device file to set the baud rate etc?
Also instead of cat and setserial you can try the screen command, for example :
screen /dev/stlinkv2_console 115200 |
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Fri Aug 18, 2017 1:09 pm Post subject:
|
|
|
The VCP problem is now solved.
There was apparently something wrong with the USART initialization code I wrote. Today I decided to create a new project from scratch. I started with STM32CubeMX to set up the clocking mux as well as the USART init and some other stuff. CubeMX generates a whole project structure that is functional except that it lacks any user code. I filled in the user code (copied from the broken project) and now the program works correctly and no longer needs st-util to see the VCP output.
Lesson learned for me is to use the STM32CubeMX utility. It's a hell of a lot easier to do that than to figure out all of that clock mux crap by hand. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Thu Aug 24, 2017 12:38 pm Post subject:
|
|
|
Currently, I have hello-world demonstration programs working for:
- GPIO for LED
- GPIO for button
- Virtual COM Port
- RNG (hardware random number generation)
- Timer interrupt _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Thu Aug 24, 2017 5:27 pm Post subject:
|
|
|
One thing I learned from this process is that things like HAL can change. If you have code that is written for a current version of HAL, it may not compile with future versions of the HAL library code. I discovered that while looking for example code. In some cases, I had full project data and could not compile with the libraries installed. Someone on one of the STM fora mentioned "the new HAL version". At that point I realized my search for the missing .h file was really that the code I downloaded won't work with the lib setup I have.
Large lesson learned to be sure.
Anyway, the learning curve has leveled off now, so MIDI, SAI, LCD/touch are next. maybe ethernet. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Tue Sep 26, 2017 4:25 pm Post subject:
|
|
|
yay! I got hardware MIDI input working.
I had read that 6N138 wasn't good at 3.3v, but it worked for dsPIC, so I first tried to use a 6N138, but the waveform was sloppy. I replaced the 6N138 with an appropriately connect H11L1 and got a nice crisp serial data waveform - and the data is correct.
I built the hardware on a "protoshield" board I got through adafruit. a small, blank prototyping board with pins set up in an arduino uno shield way. USART6 connects to 2 of those pins, if you set the alternate stuff correctly. I also put a "MIDI" LED on the board, it's just connected to another "digtal" pin through a 1K resistor and the LED.
Lots more to go with this, it's all HAL driven so far.
Description: |
MIDI 3.3 volt interface. Connect Vdd to 3.3v, connect Vss to ground. |
|
Filesize: |
4 KB |
Viewed: |
25352 Time(s) |
|
_________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Sat Sep 30, 2017 6:46 pm Post subject:
|
|
|
Today I finished converting one of the STM32Cube_FW_F7_V1.8.0 projects to a simple Makefile project. The compiled code works on the board. I used the LTDC_PicturesFromSDCard project and it's source code. I have a simple makefile, so this approach worked fine. It needs to be cleaned up, but it works. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Sun Oct 08, 2017 5:38 pm Post subject:
|
|
|
I found this:
https://github.com/thi-ng/ws-ldn-12
It is a bundle of 8 sub-projects starting with a blinky to a 4 voice MIDI synth.
You may need to download STM32Cube_FW_F7_V1.4.0. V1.8.0 will not work.
I've tried 3 of the 8 sub-projects and they all compiled and worked. It comes as a makefile project. The README file shows how to compile the different sub-projects.[/url]
EDIT ADD:
I've tried using V1.5.0 since I have it. Some of the sub-projects compile (the simpler ones), but not all. I didn't dig into it, so I don't know what it would take to fix those errors. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Wed Oct 18, 2017 5:26 am Post subject:
|
|
|
In the above package, I found ex04 to be particularly interesting. It is a simple computed waveform (sine) "oscillator" which can be frequency (phase really) modulated.
I will use ex04 to learn how the internals work - which except for the size of it all isn't really very hard because all of the code is visible.
Once I got it working as-is, I extracted the ex04 sub-project and moved it into a much simpler makefile structure. The original code accesses "firmware" functions from their installed locations which makes finding and looking at them difficult. So I copied all of the project files into the simple structure I created. It took some doing, but the simplified version compiles and the project makes sound and the project files including drivers are all local to the project. I've reduced the DMA buffer size to that of 2 stereo samples and the project still works flawlessly. I don't, however, plan to use DMA in my final revision, rather, I want to use the audio system interrupt (per sample) to cause the project to stuff the CODEC with new data each interrupt. This approach ensures that any external modulation is applied to the system immediately.
My overall objective is to move this project from a HAL and BSP based project to a bare metal project, eliminating calls to HAL and BSP drivers and replacing them with direct register manipulation. This process will streamline the code removing much of the overhead and reducing the size of the binary code. Once I've achieved a statisfactory level of bare metal, this code will become the basis for a MIDI synthesizer. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Fri Oct 20, 2017 2:47 pm Post subject:
|
|
|
I got "first sound" today from a MIDI synth running on the STM32F746G-Discovery board. It is just a rudimentary monosynth, but it works.
MIDI data is provided by a ARM USART (USART6).
bin file is 34608 bytes. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|
Back to top
|
|
|
|