$10 O-Scope revisited

umm
does it need to be included by RTClock

… but when I try to use the RTC library, it fails saying it is not declared in that scope:

Such a pun!

I’m having the same issue… just ran out of time yesterday to post about it. Wife’s to-do list is interfering with my playing.

Ray

didn’t think on it until you mentioned

Ray any idea on why it happens so far?
I am using version 1.6.0 of the Arduino IDE.
Yesterday I tested installing GCC 4.9.0 15Q1, and still was getting the same errors.

victor_pv wrote:Ray any idea on why it happens so far?
I am using version 1.6.0 of the Arduino IDE.
Yesterday I tested installing GCC 4.9.0 15Q1, and still was getting the same errors.

I’m going to try 1.6.0 in a clean computer that never had it installed, then download Roger’s master repo, and then try again…

Andy, are you able to compile the last push I sent and test it? I had tested separating the ADC setup and the DMA capture before you added RTC to it, so I expect it to work fine, but I can’t test right now due to the RTC errors.

Yes, compiles for me. However with the following caveats.
I may be using a different version of the ILI9341 libraries. I’ll need to check once I get back from the supermarket.
Multiple libraries were found for "Adafruit_ILI9341_STM.h"
Used: /home/ahull/Arduino/libraries/Adafruit_ILI9341_STM
Not used: /home/ahull/PersonalApps/Arduino.cc/beta/arduino-nightly/hardware/Arduino_STM32/STM32F1/libraries/Adafruit_ILI9341_STM
Multiple libraries were found for "Adafruit_GFX_AS.h"
Used: /home/ahull/Arduino/libraries/Adafruit_GFX_AS
Not used: /home/ahull/PersonalApps/Arduino.cc/beta/arduino-nightly/hardware/Arduino_STM32/STM32F1/libraries/Adafruit_GFX_AS


I get the same errors with gmtime and mktime on a clean install of Arduino IDE 1.6.0 and the latest repo.

Andy, what version of the IDE are you using?

Ray, I found the issue.
Paul’s Time library, called Time (with uppercase T) seems to be taken for time.h from the standard library.
I get to compile by renaming Paul’s library to Time1.cpp and Time1.h.

No idea if this is specific to the Arduino IDE, or rather to gcc for Windows, or it depends on what order gcc loads each header file.

… well, that explains it! Thanks for digging into it, I was occupied today with non-fun chores.

Ray

Ah

Is this a case in-sensitivity issue on windows, e.g. Time.h == time.h which is an internal header in the compiler ??

I suspect that its best not to call your own files Time.h or Time.cpp just to be safe

It seems like it.

Ray is using Arduino 1.7.3 from “the others” while I use the 1.6.0, and I also tried gcc 4.9 with same results. So the issue seems to be that windows for whatever reason doesn’t care for the case, although with other libraries I have found that I had to match the case or it would not find the files… go figure…

ahull wrote:Yes, compiles for me…

I’m placed it in ~/Arduino/libraries/Time however I didn’t copy the library .zip folder, I cloned the git repo… url = https://github.com/PaulStoffregen/Time.git

O-Swilloscope!

Image

Idea (c) 2015 Niall Chapman… all rights reserved. Value of bacon may go up as well as down. You sense of humour may be at risk if you do not keep up payments… etc.

With all the basic routines in the design, you could also use one of the I/O lines to switch between “scope” and “Voltmeter” mode… in the latter mode, Mr. swine would be a Pig-O-Meter instead of a Swine-O-Scope… properly known as POM and SOS on the labeling. If you extend the Voltmeter concept to have an internal shunt, then the Ammeter could be called a Bacon-O-meter (Bak’ en Omm mi tor). In electronic slang, checking voltage, current, or waveforms could likely evolve to being, “Porking around the circuit.”

Ray

I like your sty-le..

Little update, I tested the pig-oscope in an RCT6 board, and works fine. I tested it with the latest commits in the repo, that has 2 ILI9341 libraries, one with DMA (_STM) and one without. Works fine with both.

I noticed that if the sketch is waiting for a trigger level to capture the next batch of samples, it seems to be hold in that loop forever until it triggers, and in the meanwhile will not respond to any other serial commands.

As soon as the trigger event happens, it goes and responds to all the commands that were sent in the meanwhile. I haven’t check the code of the trigger section to see why is that, I believe is not board specific but I had not noticed that before.

BTW I have not started turning it to an RTOS yet, if you need to make changes push them to the repo and I’ll download again before starting with RTOS.

The triggering is very crude. I suspect we need to redesign the triggering to take advantage of our dual ADCs and DMA. I’ve got guests staying over this weekend, but I will take a look at any recent changes when if I get some time this evening.

If we can make the triggering more robust we could look at averaging schemes over multiple triggers to get better resolution (although this would require more RAM or fewer samples per event and might not be practical on the STM32F103C8XX boards). There are a couple of tricks that also allow increased bandwidth by averaging too, so we might theoretically be able to pluck a few more megasamples/sec from our short signal with a bit of smoke and mirrors. Consistent triggering is key to these ideas though.

This might make interesting reading.