Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Better analog input control


  • Please log in to reply
2 replies to this topic

#1 blackt1ger

blackt1ger

    Member

  • Members
  • PipPip
  • 14 posts

Posted 28 November 2013 - 11:48 PM

I was wondering if a cheap oscope could be made from the Netduino+2 that I have. 

 

From my understanding at looking at the code, the AnalogPort read function blocks until it finishes acquisition in the full 12-bit mode.  I've timed this to roughly 70us per read which would only give me a less than 14Khz frequency, if I only used 1 channel.

 

The ST manual indicates that a smaller resolution would reduce the read time and that a continuous read is possible.

 

Would if be feasible to modify the Firmware 4.2.2 to a) reduce the analog precision, B) make the analog precision variable, and/or c) support a continuous read capability?

 

I'm new to ST (and ARM) but I think I could have a go at it.

 

Is there a good way to compile the firmware on a Win7 box?



#2 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 29 November 2013 - 06:47 AM

Is there a good way to compile the firmware on a Win7 box?

 

There's this article in the Wiki:

 

http://wiki.netduino...shx?HL=firmware

 

Hope this helps,

Mark


To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#3 blackt1ger

blackt1ger

    Member

  • Members
  • PipPip
  • 14 posts

Posted 30 November 2013 - 03:22 AM

Thanks Mark. 

Little did I know that amount of stress and stupidity I would apply to the problem.

 

Long story short, my USB cable to the Netduino was flakey and would only work intermittently.  I changed cables and ports and all is well.

 

However stupidity kicked in:

 

I made sure I got the correct Yagarto, being very careful to browse to the "older" version.  However, SourceForge in it's infinite wisdom ensure that the "current" version is listed first and highlighted - so I got the wrong gcc build, which totally occupied several hours of my day trying to figure out why it didn't work.

 

My first flash didn't work and I was sure I bricked the board.  I was soo afraid of doing that.  However, once I knew that the board was not working, it sorta relieved my stress for trying different things.

 

DfuSe Demonostrator constantly crashes (mostly when doing 'reads', and I was using 3.03.  However, when trying to downgrade to the 3.02, it wouldn't work at all.  So, now I'm back to the 3.03.

 

I pulled the 4.2.2.2 DFU and tried to flash that.  It would sometimes work and be seen by MFDeploy, but rarely twice in a row.  After my first successful operation with MFDeploy, it would not reconnect for anything.  I would have to either reflash, reboot, or un-plug/re-plug.

 

Finally, decided to change USB cables, the computer port and also remove all other USB devices ( I had two phones charging as well ).

Then, and only then I started to have success.

 

I've managed to reduce the precision of the analog line from 12 to 6 (or so .NET reports it as such)  But seeing the same time latencies.  I'll have to work at it a bit.  I'm probably going to do a lot of work on the analog channels - and do a bunch of reading.

 

But, it is nice to know I can change the firmware a bit, by actually having done it, as opposed to reading that it can be done.

 

However, here's a question:  Is there any place to commit changes?






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.