Recent Posts

1

Repair / Re: Repairing BT speaker that won’t power or charge

« Last post by KhronX on Today at 05:42:10 am »

I kept it unplugged from usb port and removed battery and hooked up a DC supply with 3.7v and it works just fine.

---

I’ve got 12v li-ion chargers but no idea how t9 charge a 3.7v battery. If I could that would probably be my next step…

Well, if you have a DC supply that can put out 3.7v (hopefully current-limited?), then you should be able to charge the battery itself.

Measure / confirm which terminal is which, on the battery, before continuing!

Hook up the supply to the battery (+ to +, - to -), set it to 4v, current limit it to 0.5-1A, and turn it on. The voltage will jump up a bit, from the 3.2v you initially measured, but should bump against the ceiling set by the current limit. Let it be for a while, keeping an eye on the voltage & current. Once it's up to at least 3.6-3.7v, turn off the "charger", reconnect the battery to the speaker's circuitry and see if it helped any.

2

Microcontrollers / Re: RIP Z80

« Last post by RoGeorge on Today at 05:36:16 am »

Classic Z80 was 40 pins DIL, with full 8 bit data bus and full 16 bit address bus, plus a few more lines for the control bus.


Has only a few registers, some of them doubled as an alternate set.


http://www.zilog.com/docs/z80/um0080.pdf

Less than 10 thousand transistors in total (8500).  No RAM and no EPROM internally, but could generate transparent refresh cycles in case the RAM was DRAM.  Otherwise, the CPU was entirely static.  Clock, at first was 2.5MHz, or 4MHz, sometimes 6MHz, but later it went faster.

The 4MHz ones were heaving some margin for overclocking. 
I've found a few 4MHz that were running stable at 7MHz, simply by binning the fastest one.  No extra cooling, though lowering the 5V for the entire system just a little, at about 4.7V, was helping with stability.

3

Microcontrollers / Re: Memory model for Microcontrollers

« Last post by westfw on Today at 05:34:02 am »

I came across this link https://www.geeksforgeeks.org/memory-layout-of-c-program/amp/ explaining the C memory layout and how variables are stored in memory sections. The example used here involves a PC.

I'm curious to know if this memory model is also applicable to microcontrollers like 8051, PIC, AVR, and ARM. Have you used this c memory model for these microcontrollers?

On the negative side, there is more discussion here on the nature and motivation of the poster than there is on either answering or clarifying the question (on both the OP's side AND the other forum members.)

If either side would just SHUT UP about whether this is some sort of ChatGPT experiment, perhaps there would be enough useful content here for ... OTHER people to learn something (maybe here, maybe through "AIs" - what do you care if your answers get filtered through algorithms before it gets sent to the next person who asks a question?  I doubt whether many of you are using your EEVBlog forum posts in the "publications" section of your resume...

So, with that in mind...

• The "memory model" of having text, data, bss, stack, and heap is a C language thing.  The exact implementation varies.
• As a "C language thing", the memory model is very much applicable to microconrollers.
• Yes, it's used on PIC, AVR, and ARM, and probably 8051.
• Yes, I've used it on both AVR and ARM (and also embedded x86, 68k, PPC, and MIPS.)
• The referenced web page does NOT really "involve a (modern) PC" when it comes to the details of the locations and growth direction of the various memory areas.  With the 64bit address space now commonly available, a PC program probably picks some ridiculously large part of the address space for each piece, and then uses the OS and MMU/Pager to attach pieces of that address space to real memory as needed.  eg Code at 0x1000000000000, Data at 0x2000000000000000, Heap at 0x73adf00000000000, Stack at 0x88deadbee0000000.  (Note the weird addresses for Heap and Stack.  It's a modern feature to randomize those addresses for security reasons.  And the program doesn't need Stack or Heap addresses till runtime.)  Also, it leaves out the now-common "read only data" section, which is important on PC-like systems for security purposes, and on microcontrollers so that constant data can be placed in flash.
• Exact implementations vary.  For example, some compilers use a separate data stack and return stack (I think this is probably required for PIC and 8051, but there are AVR compilers that do it as well.)
• Hardware varies.  On many microcontrollers, flash and RAM are not contiguous, or even in the same address space.  And I've even used systems where the stack grows upward.  A non-readable return stack is pretty common (that's why "two stacks" on a PIC.)
• Optimizations vary.  I believe that implementing the data stack on a PIC is sufficiently expensive that it is a compiler option to allocate function-local data (which would normally be on a stack) globally, which is pretty easy as long as you haven't done any recursion.
• Implementation and management details of the Heap are especially variable.  Systems I've used have kept careful track of free/malloc calls - which task did them, from which PC, a queue of the last N mallocs and frees, etc  (I think it's a law: "in any large system, the complexity of malloc/free will increase until you also need to implement some sort of "lighter weight memory allocator."")
• The usual suspects have posted a bunch of useful information (THANK YOU nctnico, nominalAnimal, brucehoult!) about how a lot of the memory layout is actually under developer control.  (but I'd claim that the "model" remains the same.)

If Kittu20 needs additional explanation or details, they need to be more explicit about telling us exactly what parts they don't understand, or what additional information they need, or how they are confused.  (that this hasn't been forthcoming is ... one of the problems in this thread.)

Meanwhile, there are signs that OTHER people (including myself) are learning stuff from the technical-content posts in this thread, which is a good thing.

[/list]

4

Power/Renewable Energy/EV's / Re: Where to obtain ExcellentIT Transformer Calculator Tool ?

« Last post by jonpaul on Today at 05:32:46 am »

Bonjour cher Monseiur:

Je vous advise consulter les engines serach eg duckduckgo.

https://www.diysmps.com/forums/index.php?threads/calculation-programs-for-transformers-and-inductors.522/page-7

We use the old MicroCap Magnetics for decades.

But your post is unclear if you need magnetics design or SMPS design tool.

Bon chance!

Amicalment

Jon 

PS: The best word for the GUI "canvas" in English is "Screenshot"

5

Mechanical & Automation Engineering / Re: low temperature coolants?

« Last post by Berni on Today at 05:31:32 am »

Butane has a boiling point of -1°C and has very low viscosity in liquid form.

In fact it is so low viscosity that some pumps have difficulty pumping it (It gets out of the way when you try pushing on it). But a positive displacement pump should have no issue. The other problem is that at room temperature butane is a rather flammable gas, however it only takes 2.5 bar to keep it liquid at room temperature, so it is a pretty sensible pressure that any tubing can hold.

If you want to enhance your cooling performance with phase change you can also go for Propane, it has a boiling point at -41°C so anything submerged in that stuff at atmospheric pressure will be kept rock solid at -41°C

6

Projects, Designs, and Technical Stuff / Onsemi AR1335 CMOS image sensor pinout

« Last post by mister_jay on Today at 05:28:36 am »

I am currently working on a CCTV project which utilizes the Onsemi (Former ON Semiconductor) AR1335 (AR1335CSSC11SMKA0-CP2) for its high image quality, available drivers and configs + BGA package (no wire bonding rubbish).

I spent 3 days looking for an available pinout on the BGA package without success. I also contacted Onsemi for support but did not even get a message received mail back…

I mean i get that manufacturers may want to keep sensitive information behind a paywall or NDA, but why the hell a PINOUT???
You can purchase the part through Mouser, Digikey, Farnell and even LCSC in quantities of > 1000pcs, but cannot do anything with them without the pinout. WTF?

So, to get to my question(s):
Can somebody explain, why an IC manufacturer might keep the IC-Pinout secret? Any secret sauce in it? I mean the footprint is available but no references from Ball name to pin name…

Does anyone have a source for the pinout of the part? I do NOT need the entire datasheet since all the heavy lifting of sensor integration for my platform (NXP i.MX8MP) is already dealt with by NXP. I only need the pinout.

I apologise for possible bad writing, as i am really writing in anger right now. Still, i hope you guys might be able to help.

7

Projects, Designs, and Technical Stuff / Re: Thermocouple probe temperature range

« Last post by jonpaul on Today at 05:28:14 am »

check the Omega and other temp measurement probe sites.

All TC soecs, wells, etc avail for all apps and environments.

Excellet handbook as well.

https://www.omega.com/en-us/temperature-measurement/c/temperature-probes

Bon chance

Jon

8

Test Equipment / Re: Siglent SDS800X HD Review & Demonstration Thread

« Last post by Martin72 on Today at 05:21:17 am »

Hi Dave,

Start with this please:
https://www.eevblog.com/forum/testgear/sds800x-hd-review-demonstration-thread/msg5483791/#msg5483791

9

Repair / Re: I have a TV question

« Last post by Kim Christensen on Today at 05:17:15 am »

Well, the LED isn't on... Is the wall adapter plugged in?
You could also try connecting your TV to the antenna directly without this device and see how it performs. Sometimes these amplifiers actually make things worse or do very little to improve reception.

I assume it's one of these HDTV amplifiers:
https://www.newegg.com/p/05U-0160-00001

10

Microcontrollers / Re: RIP Z80

« Last post by gnuarm on Today at 04:47:44 am »

A couple of rhetorical questions:

Can you fit the Z80 into a $5 (100+) FPGA?

Probably so yes. The T80 core is one of the most used for retro computing stuff, I have toyed with it a bit a few years ago, but it was on a Lattice ECP5 (which, while not expensive, isn't the cheapest FPGA around.) I don't remember how many LUTs it was taking up. But I can look it back up.

The Lattice ICE stuff is much cheaper, but without some of the bells and whistles.  The BRAM is only x8 rather than x9 bits wide.  That ninth bit can be useful.  Heck, some of the Xilinx parts are pretty affordable too. 

I stopped using standard MCU cores some time back.  I roll my own, stack based CPUs.  They can be optimized to run pretty quickly, since the logic path is rather streamlined.  They are called MISC for Minimal Instruction Set Computers.  They can have opcodes as small as 4 bits.  This also helps to facilitate fast clock cycles, and use very low LUT counts.